During my attendance at Agile2007 I learned about several anti-patterns for Agile adoption. I heard consistent stories of insufficient planning, poorly assembled backlogs, and ambiguous definitions of done.
For many Agile teams, these smells are all too real. To help discuss them I have come up with a name around which we may build a vocabulary.
The Pattern Name
The Absent Product Owner anti-Pattern, or APOP for short.
Common APOP Smells
- Unclear requirements.
- The team doesn’t know what it will mean to complete a story.
- Development teams try to build a backlog because the backlog owner has other priorities.
- Sparse to no attendance at sprint reviews and retrospectives.
- Constant change of focus.
Why APOP Happens
According to Jim Coplien, “An anti-pattern is something that looks like a good idea, but which backfires badly when applied.” Such is the case with APOP, which arises most often in bottom-up Agile implementations.
Grass roots development teams often adopt Agile techniques and move into process change before getting the cooperation of product owners, project managers, product managers, QA, or others on whom success lies. Getting support for the development team to “go be Agile” is not enough to be successful. There are real process boundaries that must change, such as finding the one person who will accept accountability for a product backlog.
Just because the development team wants to do Agile doesn’t mean the other teams are sold. Even if the other teams are sold they may see Agile as a “techie thing” applicable to the engineers, but not to them or their team. Finding the real product owner in this situation (not a team, a person) and genuinely receiving a commitment to provide a backlog is crucial.
Not having a single wring-able neck for the backlog when sprint planning day arrives will produce APOP quicker than I can get naked.
This happens far less in organizations that implement Agile in a top down manner, because product owners are identified early and clearly. In this situation, product owners are given the accountability of a clear product backlog, they are not asked for it by the teams. Being asked by a COO to see a product backlog is a very different situation than being asked by the development team. Unless your COO or CTO cares that a backlog exists and is clear and complete, you probably smell APOP right now.
How to Avoid APOP
In Top Down Enterprise
One way to avoid APOP would be for your CEO to waltz in one morning and announce that Ken Schwaber is showing up tomorrow to restructure the organization and, hence, your job. You will therefore be Agile and all of product management will be designated product owners, project managers will now be Scrum Masters, and so on.
Is this reasonable? Sure. In fact, it happened very much like this at Yahoo, by all reports.
“You can’t make me be Agile,” is a common statement when people hear this scenario. They are, of course, dead right. But the organization can be directed to re-structure its processes with Agile techniques. Doing so is called leadership, not oppression. Leaders can prescribe Agile, and teams can use it to achieve hyper-performance.
Don’t care for that? Your feet aren’t nailed to the floor.
The best news for APOP sufferers in a top down Agile enterprise is that whoever is causing the product owner or the backlog to be absent may be held accountable. If Agile deliverables are defined as part of the job, failure to deliver can be dealt with as a performance issue. When a job description actually cites responsibilities of creating a backlog, or providing customers with adequate representation, or providing product development teams with whatever is needed to be successful, you won’t have APOP.
In Bottom Up Enterprise
What about avoiding APOP in a bottom up implementation? After all, this is where we are most likely to find the pattern in full effect.
The thing to do here is to evangelize, evangelize, evangelize. Teach, coach, lead, persuade, cajole, influence, and make yourself available. Demonstrate the power of your newfound techniques in order to convert people outside your team before you ask them to engage. Help create the first backlog if necessary. In short, be a servant leader and bring other teams online as you spread the good word. This stuff really does work and there are countless papers and metrics at your disposal to prove it. Use them.
Another technique that serves me well is to pretend it is already true. Define your team interfaces as though they really exist and people will actually respect them. For instance, if you say, “I’m sorry, but we can only accept work in the form of a user story,” often people will simply ask how to create one. This is the perfect time to show them.
How to Stop the APOP
Here we have to play our cards a bit differently. Is there a company leader you can identify to be a Agile sponsor? Can you supply the data necessary to bring your potential sponsor on board as a real sponsor? Turn it around so that the backlog and customer role become directed. Although this sounds harsh, it is often a hard sell to get people to change what they do with their day if the expectations by their superiors don’t change. This boils down to making it their job to do business via the methodology you are using.
If you cannot identify your product owner or product owner representative, it is reasonable to ask your manager to point to him or her. Presumably your direct supervisor is on board with this whole Agile thing, otherwise you likely wouldn’t have gotten this far. So, ask your manager for help. That’s what they are there for. To help you. Seriously.
So, your product owner is present and accounted for, but the backlog is still absent. This qualifies as APOP. There must be a backlog for a product owner to be real, or the customer may as well not exist. How do we get the negligent product owner to engage the job of creating a backlog?
- Provide all of the support you can from the team. Make time to help these people. That isn’t to say that the team makes the backlog for them, but do give them your time to estimate the work and go through the process of breaking things down into manageable pieces. As my wife says, “You just need to be more available.”
- Buy the book Agile Estimating and Planning by Mike Cohn and give it to them.
- Evangelize the whole methodology movement to this person. Turn them into a true believer. Converting a product owner is easy. Have you seen the customer aspect value proposition of Agile? If not, check out the 2nd Schwaber Scrum book.
- Look back to the top of this section. You know, the part about finding a high ranking sponsor?
- Leave. Seriously. If you truly grok the power of the philosophy and are consistently and repeatedly met with refusal to play, leave. Do you really want to spend the your days in this environment? Life is too short and good work is being done elsewhere.
Conclusion
A fairly common situation in Agile implementations is that of an unidentifiable, absent, or unwilling client. An absent backlog is essentially the same thing as the net result is the same; development teams don’t know what to make. We can lump all of these situations into the Absent Product Owner Pattern and apply specific measures to avoid or correct the situation.
Technorati Tags: Agile, APOP, Scrum, Backlog, Methodology
2 thoughts on “The Absent Product Owner anti-Pattern”
Comments are closed.