Scrum
Scrum vs. Waterfall or Effectiveness vs. Efficiency
Scrum vs. Waterfall – For all Scrum fans, let’s get the bad news out of the way: Scrum is just a compromise. The good news is that this is the only piece of bad news.
Menu
What makes the role of the product owner so problematic and how should it be designed to make an agile transformation successful?
The first thing that often comes to mind for organizations that want to introduce agile working and Scrum as a method is filling the roles. We have already discussed elsewhere that agile work means much more than filling roles, introducing sprints and meetings and that many organizations, unfortunately, reduce agile work to these things and stop here. Read more about this topic here.
But the first problems come up when defining and filling the roles, which – if not addressed early on – will have far-reaching consequences for the entire process.
The most problematic role is undoubtedly the role of the Product Owner.
First and foremost, most organizations think it is the role of the Scrum Master that is particularly difficult and deserves all the attention. This is why Scrum Masters are usually sent to various agile trainings or are sought after on the external market, while Product Owners often fall through during the preparation phase.
I don’t want to belittle the importance of the Scrum Master’s role – both are absolutely equivalent in their nature, but compared to the role of the Product Owner, it has more acceptance and clarity right from the start.
But what is it that renders the role of the product owner so problematic and how should it be designed to allow an agile transformation to succeed?
In order to understand this better, let’s start with a few basic considerations about the understanding of roles in Scrum and how to classify these roles in the organization. Scrum is limited to three roles, the Product Owner, the Scrum Master, and the Development Team.
By doing so, Scrum breaks with the fine tradition of project organizations of constantly inventing new roles. In addition to the classic project manager, PMO and architecture roles, there are often implementation managers, release and test managers, people responsible for maintaining high spirits or coffee making, etc. This may somehow make sense for project organizations and be well adapted to the circumstances of the project.
Nevertheless, Scrum takes the exact opposite approach and limits itself to exactly three roles, independent of all project conditions.
This is undoubtedly a change of perspective or paradigm shift. This can actually only be explained by the fact – and this is also a frequently asked question, which has a lot to do with the introduction of the Product Owner role – that Scrum is not a project management method in the true sense.
Scrum is more of an implementation method. I have been following this discussion for quite a while now, and I have noticed that there is a bit of a divide. Some see Scrum as a project management method, others don’t. Even in the SAFe Guide you can find in some places that Scrum is seen as a project management method, with criticism that Scrum itself does not scale.
By the way, Waterfall was never perceived as a project management method, so why should Scrum be one?
First of all, it’s a problem that nobody knows them. In the past, this role simply did not exist in organizations.
This is also true, or maybe even more so, for the role of the Scrum Master, but it is still so new and so different, and it is due to the new method that it is much easier to accept (which unfortunately does not automatically mean that the people who take on this role are easily accepted, but that is a completely different matter).
The role of the product owner becomes truly problematic because many organizations think they know what it is all about. For some organizations, the role is very close to that of the classical business analyst, for others, it is similar to that of the classical architect.
Both are simultaneously wrong and correct – and I don’t mean slightly wrong or slightly correct, I mean it is entirely wrong, even though it is somewhat understandable.
First, we will take a quick look at the three roles in Scrum.
However, we’re not interested in the definition of the roles, but in their number. There are three, there are only three and there will always be only three. This circumstance is often given little attention in organizations, but it has far-reaching consequences.
This is because if the implementation of a project (not the whole project itself, Scrum is “only” the implementation method) – no matter what size and complexity, no matter what technology, no matter what organization and in what setup – is based on only three roles, then one thing is clear from the start.
The roles are so charged with responsibility and at the same time filled with tasks and responsibilities and must be so perfectly coordinated that no negligence of any kind can be afforded in defining the role and its positioning within the organization.
And finally, my experience from dozens of projects has shown me that a Product Owner alone decides on up to 50 % of the overall team performance, just by the way he writes the stories and prioritizes them. A product owner can bring down a project entirely with a few (wrong) steps. He bears an enormous responsibility which can rarely be delegated.
Now let’s talk about the role itself. And again we start with a negative example, because I have seen this repeatedly in several organizations. And because I don’t believe in coincidence, I see the reason for this in the above-mentioned struggle of organizations to correctly position the role of the Product Owner in contrast to the business analyst or the architect.
I often see one of two variants.
In one variant a product owner is determined, and he is supported by business analysts who are part of the Scrum team.
As Scrum teams are by definition supposed to be cross-functional, this is not considered a problem at all, but the organization believes that it is acting in the best agile sense.
In the second variant, the business analyst is made a product owner, because the basic understanding is that the product owner is responsible for requirements engineering and stakeholder management. Business analysts are used to precisely this and are therefore predestined for this role.
Both variants are wrong, albeit somewhat understandable or even reasonable or obvious at first glance. But at second glance, both variants have fatal consequences.
There are, of course, other variants in which, for example, architects are made Product Owners or the Product Owner role even encompasses several people – business analysts as so-called “technical Product Owners” and architects as so-called “technical Product Owners”, although I do not want to go into all of that here.
The first two variants are enough to clearly explain the role of the Product Owner. From this, it is easy to see why such additional variants are not good or even completely absurd.
In order to understand why I consider the first variant to be no good, let’s take a look at the general development process. Roughly put, it looks like this:
Business process (functionalities) -> functionality (product features) -> technology (implemented executable version).
First of all, a business process is described. This is done at the organizational level, either as part of a demand management process or immediately afterwards. If the organization has decided to implement this business process, the functionality is already described as part of the implementation. And this is precisely the task of the product owner. Afterwards, the functionality is implemented by the development team.
The business analysts are the ones – if they still exist in an agile organization – who analyze and describe the business processes. This in itself can be a highly complex process, depending on the topic. At a large bank that wanted to introduce the ApplePay business process in its mobile app, for instance, the business analysts had to spend several months checking all general conditions for the introduction of this business process:
Once the organization is prepared for this, terms and conditions have to be changed, and several questions have to be answered: who bears what responsibility, how is this reported to the German financial authorities, what risks does the bank bear, etc.
These are all questions that initially have nothing to do with the product. Business analysts prepare the topics that are later cast into functionality. This means that they work on an organizational level and not in a Scrum team. If they stay in the Scrum Team, a part of the team would always work asynchronously, because they are supposed to prepare future topics, of which it is not always clear if they will even be included in the product. It also becomes difficult to keep the team size small and often they will be the ones writing the stories instead of the product owner.
This brings us to a key task of the product owner. He is the link between the project organization with its stakeholders and the development team implementing the product. He is the “owner of the product”, not of the business process.
It describes the functional requirements of the product and not the technical aspects of the business process. What matters here is the distinction between technicality and functionality. This is because the functionality must not only implement the business process but also take into account many other factors, such as non-functional requirements, compliance requirements, governance, security, etc.
The Product Owner acts as a kind of liaison for the customer.
He represents the interests of the stakeholders in relation to the desired business processes, but also the interests of his own office, i.e., his development team. He will therefore set the functionality in such a way that the business process is well implemented, but the software remains maintainable and can be created with manageable effort.
Everyone who has ever had this role knows how much you have to compromise all the time. In the function that I outlined here, the product owner is responsible for maximizing the value of the product. Again, this should not be confused with maximizing the value of the business process.
And as I’ve just demonstrated, the product owner works on a completely different level, namely on the product level and not on the business process level.
Product owners already have plenty to do with stakeholder management and the transformation of all requirements into functionality and the establishment of effective communication between all parties involved.
If they are required to familiarize themselves as deeply as possible with the business processes, their original tasks will regularly be neglected. The software is designed too feature-heavy and builds up a lot of technical debt, or the teams are no longer optimally supported, at the expense of velocity.
This consideration leads us to the next central aspect of the role of Product Owner. Communication. I have described the role of communication in the agile process here as a “mutual invitation into each other’s reality”, i.e. as an essential transfer process of product visions into technically implemented features in the shortest possible time.
he must succeed in getting his product vision into the heads of the members of his development team as quickly as possible, so that they can develop the most complex system immediately and in small packages in short iterations.
This means that he does not have to be an expert in the business processes, nor an architect who knows the technical architecture of the application in great detail. He must, of course, have access to both – and some others as well – and he needs to know the functional architecture of the application.
In order to be able to do all this, he needs a few basic conditions. And these conditions correspond to the description of the role as listed in the Scrum Guide. He alone is responsible for the product backlog, i.e. for the content and order of the backlog items, no matter if they are user stories (features), enabler stories (technical debt ), bugs, or other tasks.
He cannot delegate this responsibility, but he can certainly enlist help, for example when assessing technical debt. Above all, the development team should be able to provide sound advice, which is why communication is so important, i.e. the transfer of the product vision to the awareness of the team members. Because only if they understand this vision well, they can provide him with competent advice, and they can all work together to develop this vision in the product and bring it to life.
Scrum vs. Waterfall – For all Scrum fans, let’s get the bad news out of the way: Scrum is just a compromise. The good news is that this is the only piece of bad news.
With the WSJF calculator Excel Template you can easily prioritize your backlog. It’s fast, encourages the team spirit and is actually fun! Here we describe how it works step by step.
Why we should not mix agile and classical project management – or why traffic lights are not helpful at roundabouts.
For scaled agile organizations it is frustrating when their project management tools don’t support their processes.
That’s why we developed scagile as an app which actively supports agile best-practices with features you haven’t even thought about and with which you’ll be able to create value flow across your entire organization.
