Or “Doesn’t having a full-time SM or PO result in a significant reduction in capacity?” Or “What happens if we are unable to assign a PO or SM to each team?” Or “What do we do if no one wants to be the Scrum Master or Product Owner?”
And for those that don't want to read the whole article …
The simplest (and most proven) way to address the of coaching to high performance, and ensuring the right stuff is being worked on is through the assignment of a Scrum Master and a Product Owner. When backed by proper training and support these roles will allow you to establish high performing teams which are focused on doing the most important work now.
Pragmatically it is sometimes not possible to staff these roles fully. If this is the case then you should also lower your expectations as to what you are going to get from your agile transformation. The impact is mostly felt in terms of how long it takes for things to get visibly better but might also result in a failure to improve at all. Not having these roles will also result in a your teams seeing problems, the very problems these roles we designed to address.
Large organizations embark on an agile transformation to improve how they deliver value to customers. This is all good. However when we get into the nitty-gritty of an implementation, there are a number of concepts and ideas that just seem counter-intuitive which results in the thinking that some of these ideas will just have to be adapted to “our situation.”
One of those ideas is the idea that we have specialized roles. For example, at the team level we have the role of the Product Owner (PO) and the role of the Scrum Master (SM). “Common sense”, your intuition tells you “says that if I have a someone to take on the role of a full time Scrum Master and another the role of a full time Product Owner then I will have lost the capacity of two people per team, or we need to find budget for all these additional people.” And there are a lot of teams being formed, aren’t there?
This, coupled with a limited understanding of why we have these roles (“a Scrum Master is just an administrator, right?”) results in a reluctance to properly establish these roles in the organization. For example, organizations will opt to:
Don’t get me wrong. These approaches might be required to get started; we need to be pragmatic. But we need to be aware of the tradeoffs we make when we do something that is less that ideal. Our mindset needs to be that we feel bad about making these tradeoffs, rather than thinking we have made good decisions. And, by way of observation, after doing a lot of agile transformations
Large organizations seem to struggle more in identifying full-time Product Owners and Scrum Masters than small organizations despite the presumably even more limited availability of people in smaller organizations.
Agile implementations, and Scrum in particular, created these roles for a reason; they are there to address specific problems that arise from more traditional approaches to delivering value:
So while these roles have a number of other responsibilities, agile implementations leverage these roles so that the team can delivery as a group far more of the right stuff than if they would operating as a set of individuals without those roles.
The team literally operates at a level that is more than the sum of the parts.
Traditional approaches assume the unit of production is the person. Agile approaches assume the unit of production is the team. The problem is that in order to become high performing you need to focus on the interactions between the people, not just the individuals themselves.
In other words you need a coach for the team, someone who takes responsibility for how the team is working together, helps protect the team from outside influences, helps the team address things that are getting in the way of their work, and generally support the team in their day to day activities.
This is the role of the Scrum Master.
Traditional approaches focused on the implementation of multiple projects where people were assigned to projects. The capacity of each individual was typically sliced so that X% was to be used by project X and Y% was to be used by project Y, and so on.
Problems arise when the portion of the allocation is used, but the output required by the project is not delivered. What does the person do? Work more on one project over another? Talk to their manager to determine priorities? The manager might also be the source of a third set of work (“our VP wants us to work on this now!”) as might peers of the person (“could you just help me out on this?”).
The result is that it was often left up to the individual to make the decision on what the most important item is. These decisions are made in isolation from others, from the projects, and from the business.
We need a way to get control of the work and to determine what the most important thing is that the team can be worked on.
This is the role of the Product Owner.
There are two effects on our ability to deliver value when we have these roles in place, and the people doing these roles operate as intended:
By having great Scrum Masters and Product Owners we are able to deliver more value faster
Better and more value delivered; not a bad return on your investment for identifying a Scrum Master and a Product Owner.
It might seem obvious, and it is, that if we don’t set up the role of Product Owner and Scrum Master for success then you can expect the problems the roles was intended to address will remain:
The result is that you end up with an agile (Scrum) implementation that doesn’t provide the benefits you are looking for.
Most agile implementations are not as black and white as this. Reality is that organization do want to go agile but sometimes do not see how they can get there without also cutting a few corners. The selection of the role of Product Owner and Scrum Masters is one of those places that people often cut corners usually by saying that Scrum Masters and Product Owners will be part time either by doubling up the teams they need to support or by indicating that they will only use 50% of their capacity to fulfill the role.
The impacts of this type of approach, assuming that the people selected are trying hard to fulfill the roles include:
If you don’t establish the role well, you risk having all the overhead of agile (Scrum) and none of the benefits.
Practically speaking the usual impact will be a serious slow down in receiving the expected benefits of your agile (Scrum) transformation in most cases. This makes sense. With agile we are putting in place a new system to deliver value. That system is made up of a series of interlocking parts. When you do not completely supply the parts, you can expect there to be an impact on your new system of delivery.
The role of Product Owner and Scrum Master were established to deal with specific issues. This means that if you decide not to use these roles, or if you decide that those assigned to these roles are working part time, then you still potentially have these problems and will need to work to overcome them.
Thinking about the Scrum Master role of working toward a high performing team. Experience tells us that if we want a high performing team, we will need someone to coach that team (try to think of a successful sports team without a coach). It’s not that our people are not professional. It’s just that their perspective is not “how is the team interacting to produce value?” If you do not use a Scrum Master for this, then how will this get done?
Some organizations use managers for this function but there are problems with this approach. Firstly managers are often very busy and cannot dedicate the time required to really build a high performing team. Secondly organizations find the way team members interact with managers is different to how they will interact with peers. The result is that it can be difficult for managers to impact the team in the right way.
Thinking about the Product Owner roles of providing a single view of the most important things a team could work on. Again the problem doesn’t just go away if we don’t set up a Product Owner. By setting up the Product Owner role we also encourage a change in the process. So, for example, when someone comes directly to a team member asking for something specific, it is easy for that person to say “Talk to the Product Owner”.
Some organizations create a process around the the intake system and, instead of having a single Product Owner, they set up a group who is responsible for determining the prioritized backlog. This group then meets regularly to deal with changes, new incoming items, and updates as a result of work.
And for those that don't want to read the whole article …
The simplest (and most proven) way to address the of coaching to high performance, and ensuring the right stuff is being worked on is through the assignment of a Scrum Master and a Product Owner. When backed by proper training and support these roles will allow you to establish high performing teams which are focused on doing the most important work now.
Pragmatically it is sometimes not possible to staff these roles fully. If this is the case then you should also lower your expectations as to what you are going to get from your agile transformation. The impact is mostly felt in terms of how long it takes for things to get visibly better but might also result in a failure to improve at all. Not having these roles will also result in a your teams seeing problems, the very problems these roles we designed to address.