After being an observer at the San Jose balancing the budget game event (which was guided by Luke Hohmann of the Innovation Games Company), I realized that most of the software products that are not successful probably have something in common — the enormous gap between the customers and implementation process.
In Scrum, the customers are represented by one single role: Product Owner. An effective product owner can help bring the customers closer to the product through the iterative Scrum process, and can create a natural synergy between the implementation team and the customers. In many half-hearted Scrum implementations, the project teams and end products suffer greatly from an ineffective product owner role, and many of these projects fail. Unfortunately many of these pitfalls are manifested as common hindering and counter-productive practices known as anti-patterns. They are:
- The Absent Product Owner
- Copy The Last One
- The Churning Backlog
- The Waffling Definition of Done
- No Single Product Owner
- Not Enough Stakeholders
I will share these in a series of blog posts, beginning here with The Absent Product Owner.
Anti-Pattern 1: The Absent Product Owner
When the product owner is not available to provide rapid feedback to the agile team, the team does not receive inspection feedback and adapt their work. Nor will the product owner be able to adjust the product design or specification based on the feedback gathered from the actual customer community, as a part of the demonstrated result of each sprint. Instead, the team “self-inspects” and makes decision on their own, falling back to the waterfall process and delivering incorrect features at the end of the project.
- The product owner communicates the backlog electronically and does not show up to sprint planning or sprint review meetings.
- The team has to maintain the backlog.
- The team has to determine the stories’ acceptance criteria on their own.
The only remedy is to work with the product owner and his/her organization to:
- Create a dedicated role and support group for the product owner, so that the product owner is a full-time role on the project; or
- Designate a product owner proxy, which could be one of the team members (although this takes that team member away from implementation). Alternatively, someone outside the team can do a “mind meld” with the product owner and do their best to fill in when the she/he is absent.
If none of these options are satisfied, this impediment should be raised to the higher organizational level for resolution or it should be suggested that the project be aborted.
Effective Scrum depends on a high degree of trust between all team members, including the Product Owner and the ScrumMaster.
- Since the scope for a release is not fixed (only time and money are), Scrum asks the Product Owner to trust that with their help, the team is going to deliver the most value possible by the release date.
- In order to make this happen, the team needs a very strong focus on results, which ultimately depends on trust among team members.
- Scrum asks the ScrumMaster to trust the team to self-organize and deliver. In order for the team to take responsibility for results, the ScrumMaster must allow the team to fail safely when needed.
There are of course more instances of mutual trust, but the above should give you an idea.
No matter what role you play on a Scrum team, ask yourself at the end of each sprint: did we increase trust among each other?