Many organizations aim to be agile. However, only few succeed in becoming truly agile and gaining the benefits out of it.
Let’s take a look at what are the common mistakes in the journey on becoming agile and how to avoid them.
Common mistakes to avoid:
- Doing agile (just) because agile is trendy
- Putting no time and effort to implement changes especially when people are involved
- Not forming tribes around the value
- Thinking doing scrum ceremonies is being agile
- Filling calendars with meetings = no time for real work
- Making only teams agile but not concentrating on the mindset and prioritization on company level
- Having product owners as team output owners
- Having product owners doing everything else but what they are actually supposed to do
In this blog post, I will cover challenges with product owner’s role.
Other parts of the series:
Making agile work: Avoiding change related mistakes
Making agile work: Avoiding scrum related mistakes
7. Having product owners as team output owners
Product owner (PO) is a very important role who does prioritization in agile. However, you need to have the PO role correctly in place and the PO to really have the power to do the business related decisions before the PO is helping with prioritization issues.
This video describes perfectly the dilemma with PO role and how PO’s end up being something else than PO’s: Why “Scrum” Isn’t Making Your Organization Agile: Harmful Misconceptions About Product Owner Role
In a large organization it is very easy to end up in a situation where you have a one PO and one backlog per each team and the teams are optimizing their work. In this setup the PO becomes more team output owner than a real PO. In this setup the team suboptimizes their work which in bigger picture is not helping us to create the best customer value.
This multi team setup with lots of PO’s (or team output owners) takes us even more far away from the customer, since neither the teams nor the POs have contact with the customer anymore. I would even say that that is anti-agile. Make sure that your PO’s really have the power to do business related decisions and fix the organization accordingly.
8. Having product owners doing everything else but what they are actually supposed to do
According to my discussions with POs along the years, it seems to be a pattern that all the PO’s are overloaded with work and often doing lots of stuff that POs are not supposed to do. They have lots of reporting and subject matter expertise related tasks etc.
It is also very common that a PO is understood as a team leader, change manager, the person who implements everything to the teams, developer of new ways of working inside the team, a coach for the team etc. These would be more of scrum master work than PO work, although scrum master should also be more of a coach than a team leader.
At the end, most of the POs are not doing what they are supposed to do: create vision and roadmap for the product, communicate with the stakeholders and customers and work with the backlog. When this happens, there is a big chance that your PO is actually not a PO but a team output owner.
There are couple of things you can do:
- Check that the roles of a scrum master and a PO are understood correctly and the PO is not doing the scrum master’s work.
- Check if there is work that the PO is doing that should be done by the team members.
- Check if you could have e.g. a tech lead who could take some of the work that the PO is currently doing.
- Fix the organization and put only 1 backlog to several teams and 1 real PO on top of that backlog.
What if it feels that a PO is not able to do the backlog and the team members are right people to do it? There is a big chance that instead of bigger items, there are tasks in the backlog. In that case, you should fix the backlog to have items that describe the goal for the product work. The team members can then later on split them to smaller tasks.
Hope you find these tips helpful. It would be nice to hear how these tips fit to your company and what kind of solutions you have developed to make your company more agile. After all, as we are agile, these are the best practices for now and as we learn, we will keep on creating better practises in the future.
