When we describe a technique, an approach, a method, we have in mind that it will be applied thoughtfully and mindfully. We’re quite often surprised to find what a horrible mess people can make of something that can work quite well. Let’s look at something that can go well.
Scrum has the role of Product Owner, corresponding to XP’s Customer. Scrum puts it nicely: the Product Owner is accountable for delivering the product, with the best possible return on investment, by the delivery date. There are many ways to screw that up. Maybe we’ll talk about some of them later. Right now, here’s what can happen when you “do it right”.
In The Nature of Software Development, I used the term Product Champion. As far as I know, that role name originated at 3M. I’ve also heard it used at Disney. I suggest here that it’s a Very Good Idea, and describe how Scrum can go that way.
An idealized product effort
We might imagine an ideal product situation, where a group of equals band together. They have a product idea and they collaborate actively to create it. They have all the skills they need, they work together as smoothly as the Flying Karamazov Brothers, passing ideas and product bits back and forth, weaving a beautiful product as they go.
That would be great. If you can find that deal, take it. But there are some issues that make this situation unlikely, even if it would be ideal.
A more nearly real product effort
In most product efforts, we are likely to have issues like these:
- Some person or organization is funding us.
- We have a finite budget in time and money.
- There are key stakeholders who demand control, or the illusion of it.
- We do not all know the market equally well.
- We do not all know the technology equally well.
- We are not all equally good designers.
- Some of us just want a clear picture of what to do.
- Some of us want to figure out a better thing to do.
- … it goes on and on.
What comes out of issues like these, whether we like it or not, is an “organization”. Organizations like to have someone who’s accountable. Yes, I know that often means someone to blame. Nonetheless that’s the situation we’re likely to see most often. How can we get from there to where we need to be?
Enter the Product Champion
Henceforth, I’ll use the term “Product Champion” to mean the person in the Scrum:Product Owner / XP:Customer role. Champion for short.
If the Champion is to be accountable for maximizing success, they need to know the product market. Make it so. If they know the market, they must have access to customers, prospective customers, and so on.
The Champion is probably not expert in all the details of building a successful product. If it’s an animated movie, she doesn’t know all there is to know about story-boarding, tweening, character development, story-telling, dialog, and all the other things that make up a movie. If it’s a software product, she doesn’t know all the UX, the database, the coding, the testing, and all the creative work that goes into making a delightful product.
What she has is a team, and access to the world of people who may want the product.
Perhaps in early days, the Champion serves to outline the product, describe who wants it, describe what they need. She works actively with the team to figure out what needs to be done. She brings in real customers, or real prospects, to talk with the team.
Does scrum even allow that?
It surely does. Scrum even has that activity, “Backlog Refinement”. Some organizations think that means that the PO sits in an office somewhere writing story cards, but that’s certainly not what Scrum’s experts say. Refinement is an activity, not a meeting. It takes place during the current Sprint, readying backlog items for upcoming Sprints, particularly the next one, but not limited to that. Backlog Refinement is supposed to include some or all of the Dev Team members.
It’s perfectly good Scrum – in fact it’s great Scrum – if the Champion brings in problems and the Dev Team solves the problems. The more flexibility the Champion has in her question, the more power the Team can bring to bear. A conversation takes place, some stories get created, the testing Dev Team members propose a few Executable Acceptance Checks, and the Sprint Goal becomes “Solve this problem.”
It might go like this: The Champion brings in some prospects and lets them talk: “We tried your last product increment. One issue we had was that as we work, we hand Things back and forth. The product seems to think one Person is going to push the whole Thing through, and that’s not how we work.” A conversation ensues. At first, the team talks about letting different people log in on a Thing. As the conversation goes on, they realize that the product is focused on the Person and should be focused on the Thing. They figure out how to re-orient the product that way and invite the prospects back in a few weeks to take another look.
But but but …Scrum doesn’t say that!!
Scrum never specified that that was how we should work!?! We didn’t know we should do that. If we did know, we couldn’t do it anyway, because reasons!!
Yeah, well, I’m not interested. Stop complaining. It’s on you.
The Success or Failure of Scrum is On You
Scrum is a framework. It rests on a few simple notions. In this case, a Product Owner who understands that she should be Product Champion, the Backlog Refinement practice, the Sprint Goal, and Inspect and Adapt.
Your product, your team, your success? They rest on you. It’s your responsibility to make it work, and the power to do that is in your hands.
If a situation like the one I just described appeals to your team – and I hope to hell it does – then Inspect and Adapt and get closer and closer to that ideal. That’s your job when you’re doing Scrum, XP, “Agile”: improve continuously and move your process where you want. Use the framework to do that. Change the framework, if you must, to make it better.
Note that to get to a full on Product Champion, you don’t have to change your process at all: Plain Vanilla Scrum supports it just fine.
OK, but how could we get there?
I’m tempted to say “Inspect and Adapt” but let me give a slightly bigger clue. What if we did something like this:
- Learn to build a product increment every two weeks. Use our Scrum Sprint Review to show the product to our Produce Owner (Champion-in-training), and to all the stakeholders we can find.
- Join actively into Backlog Refinement sessions. Ask questions about the problems behind the stories if stories are too specific. Whenever possible – and it always is – offer better ideas for how to solve the problems.
- Ask questions about what prospects and users said. Ask to talk with them. If necessary, find some of our own and talk to them. Use what we learn to help the Champion.
- Make our Product Champion a hero in the organization. Don’t worry that we won’t get credit: if we make them a hero, they’ll keep supporting us and helping us get happier.
- Use our ScrumMaster to influence the Product Champion, and the organization. That’s what they’re for. Do the same with other team members. Learn to make an elevator pitch. Use your contacts.
If we do things like these well, our situation will probably improve. If the organization is toxic enough and the situation does not improve, we’ll nonetheless have built up our skills as individuals and as a team, so that we can find a better niche if we choose to.
But the odds are, we can improve the situation we’re in.
And that, boys and girls, is the bloody job. “Agile” is a lens. We use the lens to see how to improve our work. “Agile” doesn’t improve our work: we do.
Do you want a Product Champion? Use your Scrum, your “Agile”, your own work to get one.