Release planning with only one SCRUM team servicing multiple Product Owners

In real life, SCRUM usually requires some adjustments to fit into the organization in which you are working. One of the issues I have come across in my daily work as a ScrumMaster is having to work for multiple ProductOwners but the only ressource available is a single team. SCRUM applied with the green band around your arm says that a ProductOwner has a dedicated team throughout the entire project. In real life – that’s hardly ever so. I tried both ways – working on a dedicated team with a single PO and at my current job we are serving no less than seven ProductOwners with a single team of 4 developers – and everybody is generally happy about it. How is that possible?

We have decided on a model in which we do SCRUM by the book. Whenever we break away from the beaten path we do it because it enhances transparency and maintains visibility in contradition to following the “rules” of SCRUM. We try to do things because they make sense to us – individuals and interactions over processes and tools, we say. Having seven ProductOwners aren’t exactly SCRUM by the book but nevertheless it is the world we live in and things aren’t going to change on that particular issue. How to apply SCRUM under these conditions?

What we’ve tried to accomplish now is a more thorough plannning process – we’ve introduced release planning in our process. We have introduced what we call Pre-sprint planning. It is a meeting held about the 10. in every month. Participants are ScrumMaster (me), our IT Manager and a role we’ve invented called ProductOwner Coordinator. The IT manager is in charge and decides which backlogs gets a time slot in the forthcoming sprints. Every ProductOwner writes the IT manager an Email prior to our Pre-Sprint plannings and argue his or her case for having time in the forthcoming sprints. Some backlogs get time and some don’t. The very important thing here is that there is only one single person who decides – call it dictatorship but it’s the easiest for all parties involved.

At the meeting we collect the necessary data needed to prioritize. These data inclue all requests from ProductOwner, the content of our Team Backlog (the team’s list of technical debt issues prioritized by business value and estimated just like a normal backlog) and the contents of all Must-Haves on every backlog aggregated into a single Excel spreadsheet. We base our discussion on the data before us and the IT manager decides on a release plan for the next 3-4 months.

An example: Backlog A gets perhaps 50% of the next sprint. Backlog B and C gets 25% each in the next sprint. Backlog D gets 100% in the sprint after the next one. This release plan of course isn’t carved in stone – nothing is until Sprint Planning 1 where the team commits to a list of stories for the upcoming sprint. The release plan is being published on a blog which every ProductOwner subscribes to – and if a ProductOwner disagrees with our IT managers decisions after reading the updated releaseplan because he thinks there is more business value in getting his backlog stories implemented - he is required to go to our IT manager and argue his case and make a new request. A month later we meet again to another round of Pre-sprint planning and the current release plan is discussed, requests are taken into consideration and an updated releaseplan is published on our blog.

The advantages by having a long-term goal are numerous:

• Visibilty is evident. The entire business knows what’s going on and who get’s precious timeslots next.
• The team knows in advance which backlogs to estimate stories from. No more estimation meetings on backlogs which never make it to Sprint Planning.
• Our many ProductOwners have a single person to go to in order to get stories implemented by the team.

The main advantage is that it is clear to everybody who’s in charge. This person must be empowered to prioritize between multiple requests and wishes. This person must not be an active participant in the process of implementing stories – no ProductOwner, ScrumMaster or Team member should attend this role. Our IT manager is the right choice in our organization. It depends heavily on the culture and organization structure which person is the right for this job.

We’ve tried this approach for the first time at our last Pre-sprint planning because we needed to get a clear picture of which backlogs we could focus on during the summer because our vacations are very wide spread this year. If nobody disagrees with it - well – we call in for estimation meetings on the backlogs we know are in the pipeline and will be much better prepared for Sprint Planning 1 than we’ve ever been even with the limited ressources available to us during vacation season    :o)

Process change only works top-down

Recently I have researched a bit on how to make a SOA project succeed - and much importantly: Why SOA projects fail. Given that the best way to make speed is to avoid making errors uncovered by others a Google search for "SOA Antipattern" reveals all kinds of goodies.

There are a lot of repeated do's and don'ts around many of which are quite obvious. For one: "Don't dive into a SOA project with a Big Bang refactoring of all your infrastructure". Agile chapter 1, page 1 (perhaps page 2): Don't do big refactorings at all. There is no such thing as a big refactoring if you have committed to the agile way of doing software development.

But: There is one argument which isn't quite so obvious and can be counter-argued with theoretically. The argument goes that the owner of a SOA business case should be a business executive in the area that the SOA service should be serving. Why is that? Well: For one: It commits the business to take responsibility for the IT they want, a.k.a: Having the business own it's own IT business cases stops having IT delivering good, stable and reliable products which doesn't solve any problems.

Having experienced a bit of problems lately in our Scrum process I came to think that there are a few similarities between the two. You need the business present on a daily basis taking responsibility of the development of the product you are about to deliver. The key elements which are critical for the Product Owners to be mentally involved in a Scrum team are (in my opinion):

• Force the Product Owner to come to your Daily Scrum. No excuses - they must show up and listen to what you have to say. They might not understand everything but the team needs the Product Owner present to ask questions and for guidance.
• Speak their language. Never say "This feature sucks because it requires me to make serious changes to moduly Y and X" but "That sounds like a neat feature- and it will unfortunately take X days and hours to implement". They don't understand technical complexity but the PO has a deep respect for "Return on Investment" which means the time spent on a single feature by the development team.
• Make them test every time you commit something to the mainline /staging environment. No excuses. If the PO haven't tested an implementation the PO can't say it is Done and your team haven't improven the velocity of the sprint.

By following these steps you know that the Product Owner knows what's going on and can be held responsible for - well - IT projects that doesn't solve any problems in the business domain ;o)

The best way to ensure that the PO does in fact adopt to these few guidelines is to not let the IT departement drive the Scrum process. It can't be stressed enough. Any kind of process change and mindset change must ideally come from the Dark Knight of Evil, a.k.a the president of your organization. If i.e. SCRUM is only implemented within the IT departement you never get the Product Owners to adopt your philosophy because the live in a different world with a different mindset than yours. That mindset might not leave room for i.e. half an hour of testing when the Scrum Team says something needs to be tested. It is probably not because the Product Owner doesn't know or can't see the value of testing - but if the Product Owner is being overruled and assigned other priorities by his/her boss the SCRUM process fails because the team is unable to show progress to the rest of the business.

It's all a matter of prioritizing time - the SCRUM team and the Product owner needs to have the same priorities and only the Dark Knight of Evil mentioned above can reassure that the priorities are the same for various Product Owners and the various development teams within an organization. That's why the biggest antipattern in my opinion when implementing SCRUM in an organization is to let a single departement drive the mindset change through. It'll never be a good experience for all parts and inevitably the SCRUM process will be questioned again and again.