Second of a three part series...
In this second part of our article you'll find the next three challenges we identified. The experiences shared in this series of articles come from working in large waterfall oriented enterprises and governmental departments. In our function as hired Scrum coaches from Xebia we gathered data from projects having between thirty and sixty people. The systems all comprised multiple platforms and technologies and often had a service oriented architecture.
#4 Defective Product Owners
We see that it's hard to find capable product owners. When a product owner is eventually found, we frequently see that this person doesn't have the mandate or knowledge to do the job properly.
A product owner's main responsibility is getting the most valued functionality at a certain date within a certain budget. The product owner therefore must be able to prioritize work and decide what functionality to put into a release, maybe removing obsolete functionality and adding new functionality. The product owner also has to answer questions about functionality that arise during the course of the project, signing off sprint results, and reporting to upper management. In order to do his job properly the product owner needs the right authority and knowledge about the business, the problem domain, and the envisioned product and Scrum process.
A defective product owner can heavily decrease the delivered value at each release and the team performance. We often see that the product owner is not the budget holder and cannot decide what functionality to put in a release. As a result decisions cannot be made quickly enough and throughput stalls as teams must wait for a decision to be made. Another thing we see is that product owners do not have the right understanding about the product requirements to be able to make the "right" decisions on requirements prioritization. The question "what is the business value of the product backlog items?" often can not be answered in any meaningful way.
To cope with this make we found that having a customer or product owner team consisting of people with the right knowledge and authority is fundamental. From the business you'll need to have marketing and business analyses to clarify requirements and provide input of market research activities so that the right prioritization can be made. If you do not have the right authority on budgeting then you have to get the budget holder in the customer team so that decisions can be made quickly.
From IT you'll probably need Architects and requirement engineers to help prioritize and prepare the product backlog. And of course actually having a user representative is not a bad idea. Note that even for small projects a (small) customer or product owner team can be very useful.
Starting product owner teams are faced with lots of new things and often need to change their view and way of working. A different way of planning and handling requirements is needed, new ways of measuring progress and a different way of managing. Because of this and because the product owner is such a critical role in the Scrum process, the adoption process will greatly benefit from extensive coaching the product owner team and development teams.
#5 Doing agile strictly and only by thebook
Now here's a strange one. When adopting Scrum one of the things we teach is : Scrum is a simple process with not all that much obligated steps in it: don't cherry-pick and stick to the rules. How is it then that we indicated "Doing Agile strictly and only by the book" as a