Falling into the How Trap
Yesterday I talked a little about how companies focus too much on process… how they are doing their work… rather than the actual business outcomes they are trying to deliver. This is a really big problem that impacts all levels of the organization. I bet if you took a good look at your company you’d find great examples in your corner offices… and in your team rooms.
I’d like to take a moment to go over a simple example that I see over and over in the agile community. I hate to pick on Scrum again (the price of success?)… but Scrum is basically a HOW solution… a process… that solves a particular organizational dysfunction. We need things like business alignment and servant leadership… we need the ability to inspect and adapt and respond to changing business conditions. What Scrum gives us is Product Owners, ScrumMasters, Iterations, and Retrospectives.
If Scrum works though… why does this matter?
When we start thinking that the goal is to have a Product Owner… even a trained CPO… the focus shifts from WHAT we are trying to accomplish to HOW we are going to accomplish it. I need the business to be able to make prioritization decisions… I need clear direction on what to build next… I need clear requirements definition… I need user acceptance. The Product Owner is merely a HOW that satisfies the WHAT… in some contexts. What if my context changes?
What if I can’t have a dedicated Product Owner for every team? What if in my company… the Product Owner role is too big for one person? What if I need to guide and coordinate multiple teams across multiple timezones? If I focus on implementing a HOW… the Product Owner role… I lose the opportunity to create new strategies that deliver the right business outcomes. If I focus on the WHAT… I am now free to craft a strategy that delivers value… AND operates within the constraints of my business environment.
Re-thinking the Agile Enterprise takes a systematic look at what we are actually trying to deliver… the core capabilities of our business… and lays out a strategy… a framework… for creating situationally specific strategies to scale agile in the enterprise.
Comments (13)
Roger L. Cauvin
I think you hit the nail on the hit by characterizing "product owner" as a role. As a role, it can be filled in many different ways. Often, I think a combination of people is needed to fulfill all responsibilities of the role.
Mike Cottmeyer
Totally agree. The problem is that folks want to assign it to a person because Scrum prescribes a very specific HOW to address the PO role. When you start thinking about the WHATs behind the PO role… it leads you sometimes to different solutions.
annaforss
I agree on that too many are too focused on the process. It can almost feel like the interpretation of a religious text. I've many times discussed the handling of bugs. Guru X says include on product backlog, so that's the way to go. Oh no, guru Y says the opposite, don't do that. And the bugs are still popping up and are not fixed.
For me, the product owner means the last outpost, that lighthouse you turn to if you don't know where to go. When a developer searches for answers, people can avoid that, point somewhere else and eventually the developer makes a guess. Sometimes a good guess, often not the best choice.
The product owner role means that when a developer don't know where to turn, he goes to the product owner and he's responsible for getting that answer. I cannot as a product owner duck for those questions.
This is why I see this as a single person responsibility. When you are two, you can refer to each other. But this does not mean that you must have a dedicated product owner for a scrum team. What is important is that developers feel that they know who can get those answers and get them in time.
Interesting post, as always
Daryl Kulak
Distinguishing WHAT from HOW at this level is helpful.
But I have to ask, when does "Why?" come into it. This is a piece of Agile that is often missing, where we are asking why the Product Owner is doing something, understanding it in the current context and making sure it is still something that makes sense.
Too often, we get into a "mechanical mindset" where we're following Agile practices just for the sake of following them, not asking "Why?"
What do you think, Mike?
Mike Cottmeyer
Anna,
If I am reading your comment correctly… you are uncomfortable with the dogmatism of Scrum… but still feel like the team has to have one person to go to get questions answered?
To me… the fundamental WHAT then is business alignment. Scrum says that the team needs to be clear about what they are going to build and where to go for additional information. If two people can perform that role… okay. If a team of people can perform that role… that's cool too.
If two or more people can't do it… then again… we have an alignment problem. Solving alignment by putting in a PO only pushes the alignment problem outside the team and forces the PO to deal with it.
Make sense?
Mike Cottmeyer
Daryl,
I think that the WHY is in between the WHAT and the HOW. Your observation is really the key concern behind all of this. If we put in a PO without understanding WHY we are doing it… without understanding the WHAT behind the HOW… we are following blindly.
If we understand the WHAT… the HOW and the WHY should support each other. I guess my point is that I think it is all related.
Someone might make the case that Scrum is a beginner level practice… do it the ONE way first… and once you learn it… adapt it. The problem is that many organizations are too complex right out of the gate for entry level Scrum.
Daryl Kulak
Mike,
Yes, I agree mostly. Organizations using the "follow blindly" model as a way to get started with Agile/Scrum is a problem that I've seen. I feel there is too much blind followership, either organizations doing it or consultants convincing them to do it (makes the consulting easier).
Since I am an Agile consultant, I try not to fall into that, but it's hard not to.
Mike Cottmeyer
The problem is that everyone says 'scrum scales, scrum scales'. The question you have to ask is… does it scale without radically changing how your organization is structured. Do you have the authority to make the changes necessary to really scale Scrum?
Some clients I talk to like the simplicity of Scrum and want to use that metaphor all the way up. Having a conversation about UP, DSDM, or Lean can be challenging.
Mike
Troy Tuttle
Nice post. I've observed this for a few years, and is why I think lean software fills this void. Lean starts with the "what" instead of the "how".
annaforss
Yes, the dogma can be annoying, but hey; which community does not debate this type of issues. I don't think the agile community is worse than others. But we could be better.
Yes, I don't think that it should be an absolute rule to have one product owner. We're today having two parallel projects with different formal product owners but we both act as POs to the teams. They can turn to one of us and I hope they can feel sure that the question gets answered independent of who is available at that moment.
When I think more about it, it's as always a question of accountability. No one should feel comfortable avoiding a question and leaving someone who needs an answer. And this is the core of the concept of the product owner being a part of the team. As Ken Schwaber puts it; the only title is Doing The Best One Can, and in the case of the product owner people, that is probably getting answers to all those questions.
This shouldn't be a problem, but is. People like having something to say about software development but don't like making hard decisions. Being responsible for selecting what to cut and what to do. And this is why we in reality need the concept of the Product Owner, The Single Wringable Neck.
In the best of worlds, we don't need that.
Mike Cottmeyer
Anna… I don't disagree… but in most organizations… especially at scale… the single-wringable-neck doesn't exist.
How are we going to handle it when it doesn't?
Are we going to give up and say agile won't work here? I hope not… I think if we think about the problem properly we can craft a situationally specific strategy to overcome that obstacle.
Paul Boos
Actually, I would say if you are looking for a single wringable neck, then you are looking for accountability because no one is stepping up to take responsibility for getting ti done; either singly or collectively.
At any rate, we always recommend to our customers to provide a single person with a back-up and then for that single person to bring in others that will provide advice. It's not that it truly is necessary, but as a convenience for scheduling time and such it is easier for our customer organizations to provide that one person as opposed to many people.
So I guess we do it out of convenience.
but then after reading another post today, I think we are doing agile; we aren't yet agile – we're still consciously learning (at least we know we don't know stuff).
Roger L. Cauvin
Anna, let me give you a concrete example of how it makes sense to spread the product owner role across two people. Let's say the team has two questions:
1. How much time should it take for a user with a given profile to use the product to complete a particular user story?
2. Should the user story be implemented in terms of a wizard-based interface or some other interface?
Though both of these questions relate to user experience, they are very different and require different expertise.
The first question requires a thorough understanding of users and what level of usability is necessary for the product to be successful in the marketplace. This kind of expertise and responsibility typically lies with a product manager.
The second question requires interaction design expertise. A person can have all of the market and user knowledge in the world and not have the interaction design skills to answer the question competently. Typically, this expertise lies with an interaction design or user experience professional.
If the team needs single points of accountability (which, as Mike states, may be a cop-out), you just funnel the questions to the appropriate person. If it's a true requirements question, you ask the product manager. If it's an interaction design question, you ask the interaction designer. If one person happens to play both of those roles, so be it. But it's rare that one person is truly an expert at both product management and interaction design.