I have found that organizations pursue agile initiatives from two directions. Organizations want to be agile because they have software engineering problems to solve (e.g. staff turnover, buggy software, brittle software) or they want to be agile because they have business problems to solve (e.g. customer dissatisfaction, loss of revenue, loss of market share).
I have also found that no matter what direction you start, once you have one set of problems fixed, the other raises its ugly head begging for attention – even if you didn’t have recognizable issues before. An inescapable side effect of becoming agile in one area is that it creates and/or magnifies problems in the other.
I was recently talking to a friend who is helping to lead the agile adoption in their organization. They said that their organization is consistently executing 3 week sprints that include enough testing to produce potentially deployable increments. YEAH! They said that their organization is ‘priming the pump’, i.e. grooming the product backlog during sprints to prepare for the next sprint (or two). YEAH!
But, they also said that their organization is now struggling with a bloated backlog of requests and issues. BOO! Business problems have raised their head – What should we work on next? What features are important and which ones aren’t? Can you reject requests? How?
I rarely start an organization out with hierarchical requirements. A flat product backlog that supports feature grouping is usually sufficient to start an agile adoption. Yet, within most innovative organizations, there will come a time when a top-down requirements management strategy will become necessary. Frameworks like the one proposed by the Scaled Agile Framework (SAFe) were developed for just this purpose.
I am the agile coach who drives the team to win. I will never let you rest on your laurels. Certain of my faith in you, I’ll keep pushing you to do better. “Do you really think this is the best you can do?!” But I’m not simply cheering or scolding you from the sidelines. Instead I draw on my own expertise to help you. I am thrilled to be the one who offers you the secret trick, the new technique or the mind-flipping insight that allows the penny to drop. You know I want you to learn, and you know I want you to act, and this combination is compelling. I really, really want you to win, and I’ll never let you off the hook.
People First presents “Ask the Agile Coach”
This new feature gives you direct access to the Agile Coach who personally (and privately) empowers you to put your strengths to work in the SDLC. The Agile Coach will drive you to win. Certain of their faith in you, they’ll keep pushing you to do better. “Do you really think this is the best you can do?!” But they are not simply cheering or scolding you from the sidelines. Instead they are drawing on their own experience and expertise to help you. They are thrilled to be the one who offers you the secret trick, the new technique or the mind-flipping insight that allows the penny to drop. When you interact with the Agile Coach, you will know they want you to learn, and you will know they want you to act.
The Agile Coach really, really wants you to win, and will never let you off the hook.
Look no further than the ‘T’ optimization score.
The product owner that has what it takes is strong in Business Value of course. But if you really need your product owner to be a super hero they should also be strong in System Value too. When it comes to getting requested business value into your system, your product owner should care just as much as the Development Team. How valuable is a product owner who can actually write good user stories and acceptance tests? Very valuable! Your product owner super hero also needs to be strong in Process Performance. Caring about cost and schedule is vital to managing the product backlog. I tell you what … you give me a product owner who cares about Process Performace and I give you projects that don’t wrestle with gluttony or lust – two of the 7 sins of project managment. And any scrum master will tell you that a product owner strong in Development Process is one that is a pleasure to work with. No one has to keep reminding them of the rules and they are an avid coach and teacher in their own right. Last, but certainly not least, is the icing on the cake – User Experience. A product owner strong in User Experience cares that the system expresses business value in a way that makes the customers they represent very, very happy.
A noble Product Owner, who can find? This one actually exists and I hope their manager recognizes this gift and does what they need to do to help them get even stronger.
If a decision is simply a choice between 2 or more alternatives then software is simply the culmination of multiple decisions made by individuals and /or teams of individuals who may or may not be qualified and/ or motivated to make those decisions.
Some software development choices: Do we put this work item in the product backlog or not? Do we structure a user story like this or that? Do we use this programming language or that? Do we rely on this framework or that one or none? Do we implement this process or that one? Do we track progess this way or that way? Do we deploy with bugs or without? Do we test first then code or code first then test?
I love making decisions but there are only certain decisions that I am qualified to make and there is only a subset of those decisions that I enjoy.
As a project leader, you want the strongest team possible for the project at hand. Now the Optimization Report gives you the ability to create the Optimal team. The composite score is the key. Select a Product Owner, a Scrum Master and developers until all the strengths required for your project are visible in the composite score. Now you, and your team, know they have everything they need to get the job done – on day one!
As a manager, you want to develop your team for the long-term. Now the Manager Optimization Report lets you to drill into the Strengths Report of each individual in your department so you can SEE the goals they set for themselves and you can SEE how they are rating their successes. Now you can help them do more of what they do best (their strengths) and you can help them avoid their weaknesses. You can help them get Strong(ER)!
See Salt Productions/Products for more information
I want to tell you a story…
Once upon a time there was a Product Owner who thought they knew what feature was needed for the current release. In so, they wrote precise user acceptance tests to let the development team know exactly what was expected. In this story was also a very smart developer. This developer created individual tasks to implement each aspect of the requested feature (each test) and implemented them one at a time. After implementing the first task, something just didn’t feel right. “Hey, Product Owner! Take a look at this. Is this what you wanted this to do?” The Product Owner looked and scratched their head. “Well no. That’s not what I want at all.” But … the very smart developer already had an alternate plan in mind and put the troubled Product Owner at ease by showing them how the same feature could be implemented another way. Now this meant that the Product Owner had to rewrite the acceptance test and the developer had to scrap the code they spent 3 hours to write … but that’s OK because everyone knows that user stories are negotiable.
I know some of you are bulking at the 3 hour time loss but since this is a true story I can tell you what really happened. The very smart developer did not want to throw away the code so they showed the Product Owner how it could be used to enhance the feature (add value) in a way that was not expected.
And they lived happily ever after. The End (of the Sprint)
The moral of the story: Scrum works!