24 March 2013

Does a Scrum team need a Product Owner?

This is the sort of question that can't be easily answered in a public discussion because there are so many interpretations and assumptions embedded in the question. Let's unpack.

What is Scrum?
Scrum has been around since the early 1990s. It arose from software development teams.
It's a framework for doing things better, with a strong orientation to building software. Scrum's authors are Ken Schwaber and Jeff Sutherland, and there are two organisations, Scrum.org and Scrum Alliance that provide some sort of governance over the Scrum community, providing tracing, certification and publishing rules and guidelines.

What is a Product Owner?
Your product owner readies and orders the backlog for the team. To do this they reach forward in the value stream, out to markets, customers and other stakeholders to make sure the team is building the right thing.

You can read more on this from some of the official sources above.  To start, there is the Scrum guide from Scrum.org, and  the Scrum Alliance has it's Core Scrum summary.  I find this extract from the Scrum Guide particularly useful.

  • The Product Owner may do the above (typical list of P.O. activities) work, or have the Development Team do it. However, the Product Owner remains accountable.
  • The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner.
  • For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No-one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

Ken Schwaber elaborates on his blog in a number of posts on Product Owners.  Schwaber is quite elegant and simple in his description. Some points I take away from his writing are;

  • Product Owners are a great tool to help organisations understand the value Scrum teams adaptability and flexibility can bring.
  • Product Owners come with the power to make decisions; it's not about story writing. It's about finding where value lies.
  • General and Product management and Software-Scrum teams still don't typically understand each other and the Product Onwer, with the Scrum master helps bridge the two tribes.
Jeff Sutherland can be found commenting in this 2007 article

Schwaber, Sutherland and their team have also updated Scrum canon and added new descriptions and courses around the PO role in the last year or two. 

Beyond the description
You see Schwaber's blog posts (and books) always give a situation and then respond with aspects of Scrum, explaining why they are useful. Understanding the situation and the "why" of the response is illuminating.

Schwaber also highlights the roots and the trajectory Scrum is travelling to further help understand how it all comes together in these case studies to work out.

Given the state of most organisations, there is a definite opportunity for organisations to learn to use their software development capability. Scrum provides a framework that is often comprehensively prepared for the challenges the organisation has. 

Even better it has a really simple meme.  Scrum is an idea that is simply packaged, and so it is able to be quickly transferred from person to person and from team to team.  Unified visions of what the future might look like go a long way to aiding change.

But Scrum isn't the destination
And that's where the discussions get messy.  
  • Is it still Scrum if you don't do daily scrums?
  • Is it still Scrum if you don't have retrospectives each sprint?
  • Is it still Scrum if you are pulling a PBI from your backlog directly after finishing the previous one, rather than in iterations?
What about a team that has been scrumming away for six years? They have over 300 retrospectives and associated variations in the way the do work. This week they decide to abandon sprint reviews in favour of a bunch of continuous delivery techniques?  

Do they stop doing Scrum at that instant?

Apparently, they do. But that's okay.

Ron Jeffries has a nicely formed answer at Agile Atlas.
"In short, you should be asking "Will I be more likely to succeed if I don't have a Product Owner?" or "Will design iterations improve my chances of success?", not whether you'll still be doing Scrum or XP or YourBrandHere if you do those things."
Ron's article expands on the idea of learning from the experience of others. Take the time to not just master, but to understand the practices and reasons why the work.

You'll hear me talking about dropping Scrum practices in one context or another. Sometimes it is because the organisation doesn't want to deal with Scrum. Sometimes it is because I am working at a different level to team delivery. Sometimes it is because the team is using XP or some other variation. Rarely, but sometimes, it's because a team is able to be more effective by moving past the fundamental practices.

I have had my best agile experiences working in and with Scrum teams that do it by the book (often also pulling a lot of XP along as well.)  I have to say I'd trust these guys.  It's not two crazy people with an idea that just might work. It's a community of thousands with decades of experimentation and observation under their belt.

So, here we are at the end of the blog post.
Do you have the answer yet?

No, there is no Scrum without a Product Owner.
Yes, you can be effective without Scrum.
Learn the basics by being successful with them before you challenge them.
Product Owners are powerful and important roles in Agile frameworks.
We should explore this, but if we do, we won't be doing Scrum.

1 comment:

  1. Another thing worth mentioning, but it's a side issue so I am dropping it into a comment.

    The Corporate Scrum Mandate.

    What to do? You have to call it Scrum, but you also want to jazz it up? Perhaps this is purely theoretical anyway, as if you live in an organisation with corporate mandates about development practices you've got a lot of other things you should be worrying about.