In July 2011, the Scrum Alliance website featured an article by Alan E. Cyment entitled "Compasses, Trees and Pains." It posed the question, "Am I doing Scrum or not?" Interestingly, one reader responded, '"Yeah, we're doing Scrum, but we have three product owners!"
I face a similar challenge. I transitioned a team from traditional Waterfall delivery practices to Scrum. The team was responsible for strategic growth, product upgrades, maintenance, and configuration on an enterprise-wide project management product. Our organization has more than 50,000 employees worldwide and, like many large organizations, it's divided into numerous divisions that focus on different products or services. The product we support has been adopted by seven divisions, each of which has limited interest in how other divisions use the product. My team brings the various divisions together frequently to share experiences and showcase enhancements and upgrades.
Although we have seven product owners, I believe we are practicing Scrum. I see the tangible benefits of the framework every day, especially in the cohesion within the development team and the collaboration and willingness of team members to volunteer for tasks outside their comfort zones. But the challenge we face is how to prioritize our backlog across seven independent product owners. The bigger question of whether or not we are doing Scrum is certainly worth consideration.
One way we addressed this challenge was through education. We ensured that our seven product owners understood the Scrum process. Specifically, we made multiple presentations to key stakeholders, informing them of how our delivery process works and highlighting its benefits to users. Although we service many groups entrenched in traditional Waterfall practices, we found little resistance to our new methodology as we began to deliver value-add enhancements in regular cycles and as our business partners starting seeing Scrum's added value.
Second to education was implementation. We aligned a business analyst (BA) to one or two divisions that use the product we supported. The BA assisted in writing user stories and sourcing the priorities of the user stories within each division. You could say we had seven backlogs, although in reality we only kept one. The ScrumMaster would conduct a one-hour prioritization session with the BAs the day prior to sprint planning. During this session, the ScrumMaster and BAs reviewed user stories, which were entered into a spreadsheet to determine how quickly they should be implemented.
Priority #1 user stories were added first, followed by priority #2 stories, and so on until the spreadsheet indicated that the team was potentially at capacity. The following day, the team would go through a standard sprint planning session and ultimately commit to a sprint backlog. The BAs would report back to the various product owners (divisions) about which user stories were considered top priorities and which were targeted for a future sprint. If a user story wasn't designated a top priority, it would move up and would more likely to make it into the next sprint. As a result, each product owner's user stories were reprioritized prior to each sprint planning session.
Did this approach comprehensively address our challenge? The important word here is "comprehensively," and the simple answer is "No." The approach outlined above certainly worked when demand was equal to or not excessively above the teams' velocity. It will unravel, however, if and when a business partner is unhappy with a user story being pushed out to a future sprint. In these cases, it's often true that he who shouts loudest and escalates highest wins out.
In the spirit of continuous improvement, the team created a generic definition of priority across all user stories, using criteria and weighting to determine priority ratings. We piloted the process against a sprint, initially in isolation from our business partners, to see how it worked. The pilot indicated that our criteria and weighting were somewhat off the mark, and ordinarily we would then have revised the process. But we didn't need to, because the product life cycle in our organization had peaked and demand has remained at a level close to team velocity. That work was not lost, however. We still have the benefit of our initial efforts to define generic priority across our multiple product owners if the need arises in the future.
So, are we doing Scrum? Absolutely! We still aspire to a position where we would identify a single product owner, but our organizational structure makes that difficult. What allows me to confidently state that we are practicing Scrum is not just what I see every day in terms of staff engagement, quality delivery, and the adoption of Scrum vehicles to support that delivery — it's the enthusiasm of the team members, and their drive to look at what they do today and establish whether they can do it better tomorrow.