Jim Highsmith said, “At the core, I believe Agile Methodologists are really about ‘mushy’ stuff… about delivering good products to customers by operating in an environment that does more than talk about people as our most important asset but actually ‘acts’ as if people were the most important, and lose the word asset.”
This simple but profound idea is the motivation behind Process Second. Process Second is a software development process that focuses on UP essentials, manages development using Scrum, and gives teams the ability to achieve organizational goals by using their strengths. I started developing the process in January and most of the high-value stories are done!
The project has a weekly release schedule so if you have a People First account – Now you can do the mushy stuff too.
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.
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.