A Product Owner Crisis?
The Agile Zone is brought to you in partnership with JetBrains. Learn how Agile Boards in YouTrack are designed to help teams plan, visualize and manage their work in an efficient manner, with support for both Scrum and Kanban processes.
With scrum practices getting the development team’s work under control and out of an ad hoc process, the problem is often just moved to the product owner. From a developer’s perspective that’s good, because it makes it clear to everybody what the product owner’s responsibilities are.
Introducing scrum practices to a development team is always valuable and improves the development process, even if the project as a whole isn’t agile. For a project to be truly agile it needs to be agile all the way. It needs to be agile before it’s even a project, when it’s first planned. The project governance and project management must be agile. The development team of course needs to be agile. Last but not least, the requirements handling and interactions with stake holders and users must be agile. Unless everybody involved are following the agile principles, the project is not agile.
Nevertheless, a development team will benefit from adopting scrum practices and making an offer to the rest of the project to become agile. In non-agile projects, the developers are run (over) by management rather than being allowed to self organize. When (and I mean when, not if) bad requirements or impossible deadlines are presented to the team, they are pushed onto the team. With bad requirements and impossible deadlines, it doesn’t matter if the team are doing wonders – they will still fail. When they fail it will be their fault. Do you recognize the situation? As a developer, I certainly do.
Benefits of Scrum Practices
Even though the entire project is not run agile, scrum practices are of great benefit to the development team. The daily stand up coordinates work and make team members aware of what others are doing – information that in a traditional project is the project manager’s secrets. Planning in sprints gives the team the possibility to make reasonable commitments. A sprint planning meeting can be used to force the product owner to reason about what is important to include and what can be skipped, instead of just trying to push more things onto the team.
Having realistic goals and meet them – or even deliver over the expectations is great for the team spirit. When being stuck in a project that is mismanaged, over managed or lacks proper management at all, scrum practices help to improve the situation.
Pushing the Problem to the PO
Scrum practices requires the product owner to plan, they require the product owner to have a clear priority. In my experience (building custom line of business applications) the stake holders are always unsure of what they want or how they want to proceed. Demanding a fixed plan for a short iteration (2 weeks) at a time force the stake holders and the product owner to get at least a basic planning horizon.
Using the sprint planning as a check point keep requirement problems from becoming a development problems. The problem is now pushed back to where it belongs, to the product owner. The development team gets out of the blame zone.
A Product Owner Crisis?
With the coding effort getting under control through scrum practices, the problems of requirements handling at the product owner level become clear. Looking at the projects I’ve participated in and other projects that people I know are working on, this is not an uncommon problem. I’d even say that good product owners are the exception.
With the development team crisis being solved through scrum practices, did we get a new crisis?
Do we have a product owner crisis?
I think that we indeed have. As an industry, we need to improve the business analyst position and transform it into a full fledged product owner role.