Scrum or agile development in general has been around for quite some time now, but it is still a hot topic in many organizations. Implementing Scrum or any other form of agile development successfully contains some challenges. This is especially true for large organization with many established processes, organizational structures and stakeholders.
Three of the most common mistakes that large organizations make about Scrum are connected to the Product Owner (PO) role:

  1. Too many compromises are made in the staffing of the PO role

  2. The POs do not get enough organizational support

  3. The designated POs are rarely trained in Scrum, unlike many other employees


Let us visit these mistakes one by one:

Mistake 1): The larger an organization gets, the more stakeholders a project typically has. All of these stakeholders have opinions about the prioritization and the content of features. From the team’s perspective, this can be fatal: the more people give the team input about those topics, the more confusion is created. Therefore, the PO must be able to rally all the other stakeholders behind and be the single interface to the team.

Ideally, the PO directly represents the business. This gives her or him the authority to decide about the business’ priorities, but it requires also that the business side is committed to investing the time that is necessary to play the PO role well. Sometimes, daily interaction with the team may be necessary to ensure good progress. If this involvement is not possible, the PO should be another senior employee with a good link to the business side so that he or she is able to synchronize all stakeholders without affecting the team.

What is generally not a good idea from my experience is to use a business analyst as PO because this role typically does not have the levels of competence and weight in business decisions required by the PO role.

Mistake 2): We already saw that the PO needs the authority to make crucial decisions, namely about feature priority and content. This means that the PO needs strong management backing. Besides this, the PO needs other support from the organization: because those people that are good fits for the PO role are usually already quite busy, it often pays to give them support in describing the features and requirements in detail. In other words, they need business analysis support. From my experience, it works best if the business analysts are team members, but more than one model is possible in this area.

If the PO does not get this support, the typical consequence is that features and requirements get not described sufficiently (which significantly affects the team performance) and that the PO does not have enough time to do what he or she really should: keeping the big picture, coordinating stakeholders and setting priorities right.

Mistake 3): Typically, an organization that is starting to implement Scrum is sending some of its employees to Scrum training courses. Most of these training courses are for the Scrum Master role, which is the one role in Scrum which is responsible for making sure that the process is followed correctly. What is often neglected, however, is that the PO is probably the most important role in Scrum and therefore would need training just as much as anyone else.

Therefore, many POs are not really aware of how their team is supposed to work now and stick to their old working habits. This results in a lack of prioritization, a lack of content-wise leadership, confusion in the team, and an inefficient or even ineffective process after all.

As a summary, always remember: the Product Owner is a huge part of Scrum’s success. You should not neglect the importance of this role. Especially in large organizations, you have to take this seriously if you want Scrum to deliver on its promises. Making compromises with the Product Owner role can be an expensive mistake.