BarcVox

The voice of business architecture. And more.

Agile. Product. Owner. Scrum. Master.

Anthony, a virtual colleague on LinkedIn, posed a question relative to scrum masters. I’d like to spend some time in this segment responding to that question. But first, I’d like to outline the key functions of the role of a scrum master, as I feel that this role is misunderstood, or at least mis-implemented, in many organisations. I’ve written much on my position that I feel that most organisations do not implement Agile correctly, so it’s not really a surprise that they don’t get this right either.

I’ve been given feedback that Agile is a loose framework and shouldn’t be taken dogmatically. I agree. But, this said, there are still optimal and suboptimal ways to implement anything. So, you don’t need to abide by the orthodoxy, but then don’t complain that you aren’t getting the efficiency you were expecting. And you’ve got no place to complain if it’s less effective than what you were doing before you jumped on the Agile bandwagon.

The analogy I like to use is to consider visiting a medical doctor. To achieve a better health outcome, she advises you to exercise, stop smoking, stop eating fast food, and get more rest. It will add ten more healthy years to your life. You are free to follow the advice to get the additional ten years, or you can tell yourself that her advice is too hard to follow. You are free to adopt all or none of the prescribed behaviours, but if you don’t abide by the protocol and don’t achieve the additional ten years, you don’t have grounds for complaint. The same goes for Agile roles.

Product owner is another role they tend to get very wrong. I’ll share my perspective on the essential aspects of a product owner; then I’ll follow with similar treatment for scrum masters; and then I’ll respond to the question Anthony posed.

The role of a product owner is to understand the needs of customers or end-users and prioritise the release of the features that will provide the most combined value for you and your users. In my mind, the biggest miss is that of the ownership aspect. The product needs an owner—not a renter; not a leaser; not even a part-owner or a committee. It needs a single owner.

This owner should be accountable. In a perfect world, the owner would have P&L responsibility for this product. This would need to have portfolio management logic applied, but that’s a topic for another segment. What I am saying is the product owner is the final arbiter. If this person makes some bad calls, it might be time to replace the owner, but the owner’s authority should not be undermined or diluted. It’s not a place for democracy. That might be a topic for another segment as well. The reason a product owner needs this authority is to maximise speed and decision efficiency. We don’t need a constant chorus of ‘I’ll get back to you on that’, ‘my manager overruled my decision’, or ‘we don’t have consensus opinion on that feature’. You need a person who knows what the users want, and the goal is to get this feature functionality to them as fast as possible. Full stop.

Imagine you are manager of a professional football team. You are not the owner, but in your role, you own what the team does on the field. Imagine that a football match is a development sprint. Now, imagine instead that you have to validate every decision with people above you. What should my starting lineup be? Let me get back to you on that. Should I make this replacement? I don’t know. I’ll have to ask. The product owner needs a level of ownership that gives them the authority and the concomitant accountability for outcomes. At least in the moment. At least for this sprint.

We all know what happens to managers in sports that continue to make choices that don’t lead to the outcomes we hope for and pay them for. They get sacked. But they don’t get second-guessed in the middle of a match. And they don’t get sacked in their first match. You’ve delegated decision authority to them. You trust them to make a decision. It works or it doesn’t. By hiring or appointing this person into this role, you’ve acknowledged that you think they can perform this function. Now, let them do it. And like a football club manager, don’t expect them to win every game. But, if they hit a losing streak of 0 and 10, just maybe it’s time for a change. Besides, if you make every choice by committee, is it fair game to fire the entire committee? Magic 8-ball says yes.

The implication of this is that proxy owners don’t work. If you cannot make the decision, you are a weak link. In a business relationship, the owner can never be on the IT side. Well, unless your product or service is owned by IT. Following the same logic, in a consulting relationship the product owner can never be on the vendor side. You may want to have lower-level product managers or proxies, and that’s fine. But this should not come at the expense of the product owner. At least have this person on speed-dial for the time where a decision is necessary to continue progress.

Let’s talk about scrum masters. The purpose of a scrum master is to remove obstacles and impediments to delivery. This is not a leadership role, as the team should be self-organising. The goal of a scrum master is to be the one to block and tackle and to unblock blockers. This is no pedestrian role. You need a person with connections in the organisation who is persuasive to ensure blockers are removed quickly and effectively. Whilst the product owner is responsible for what features will be included as well as the sequencing of their expected implementation, the scrum master is responsible for ensuring the delivery team has whatever it needs to deliver product features and functionality. Any unresolved questions are an impediment.

Whilst the product owner may have the final say over which features need to be included in a release, implementation may require the involvement of additional stakeholders who may have commitments of their own. If this is an impediment to progress, the function of the scrum master is to remove the impediment before it impacts the delivery team, so they are not sitting by idly waiting to be productive. This is why a scrum master needs to have connections and have influence. This is why this is not an entry-level or junior position.

Now, let’s consider Anthony’s LinkedIn question. I’ll restate it:

How do you staff the Scrum Master role in an organization with a small technology team?

I have a couple of clients who want to use Scrum. They have one small technology team of 8 or 9 people; they are a cross-functional team with end-to-end delivery capability. They want to use Scrum, but they don’t have a person to play the Scrum Master role, nor do they feel that they can spare a full-time person for one team this small. What would you recommend? I’ve outlined some options below:

  1. Hire a full time scrum master
  2. Train the team manager to be a scrum master
  3. Ask for a team member to volunteer to be a half time scrum master and work as developer for the other half their time
  4. Rotate the scrum master role within the team
  5. Have no scrum master
  6. Something else?

I responded on LinkedIn, but I’ll share my thoughts here.

  1. A full-time position is problematic, owing to the stated constraint of not being able to cost-justify a full-time role. Full-time availability is less of a necessity than someone who can dedicate enough time to execute the role. I suggest that 50 per cent of someone’s time is not enough, so I’d recommend shooting for the 75 to 80 per cent range. But this person needs to have the qualifications of a scrum master, as we’ve already discussed. Otherwise, they are just a gopher. And whilst that might be helpful and even part of the role, it would be a wasted opportunity to gain the benefit a scrum master can bring to the table.
  2. Training the team manager to be a scrum master might be a workable solution. But not knowing how they are defining the team manager, if s/he can perform this function and has the qualities already mentioned, then it’s not a bad solution. I do feel that there may be a conflict of interest and this may violate the self-organising nature of the team. And, given the 75 per cent functional availability, my first question is, ‘how does this person have so much slack time?’
  3. Having a team member split time between, say, a developer role and scrum master, say 50-50, is probably putting the project at risk. It certainly loses momentum. Even if the person is both a competent scrum master and a competent developer, which don’t share many common skills, it doesn’t really allow for the appropriate level of attention, which should be closer to 75 per cent than to 50.
  4. Rotating the role sounds like a lottery I wouldn’t want to play. You’ve got a round-robin of people, not all of whom are likely to have the skills to execute the function. It wouldn’t even be likely that one would, let alone 8 or 9. And who is training these people? I think that it would be difficult to rationalise or cost-justify this rotational solution.
  5.  As for having no scrum master, just say no. We’ve already discussed this. If you don’t grasp the value proposition of a scrum master, you probably shouldn’t be playing the scrum game in the first place. I love baseball, but I think we can get by without a pitcher. They cost too much. What do you think? 
  6. As for ‘something else’, this takes us back to my starting position, a connected and influential taskmaster. I feel that it’s a horrible idea for the Product Owner and Scrum Master to be the same person. I can’t discourage this solution enough. The biggest reason is the conflict of interest. The product owner should be outwardly focused on serving the needs of the customer, whilst the scrum master should be inwardly focused on serving the needs of the project and the delivery team. I recently discussed this problem in an analogy in a recent podcast, so you might want to check it out.
Image: Illustration of the focus of a Product Owner versus that of a Scrum Master

Bonus Content

Just to put a finer point on it, let’s see how the above options devalue the contribution of the scrum master. If one doesn’t understand the value of the scrum master, they probably don’t receive the value it has to offer. And they are setting up the scrum master for failure—though the administrivia could be spotless.

Imagine replacing scrum master with another role. I’ll present one rendition, but in your head consider if we asked this about a vice president, a CFO, a developer, a programme manager, a sales manager, or some other role. I’ll use CIO for my illustration.

  1. Hire a full time CIO
  2. Train the team manager to be a CIO
  3. Ask for a team member to volunteer to be a half time CIO and work as developer for the other half their time
  4. Rotate the CIO role within the team
  5. Have no CIO
  6. Something else?

If this sounds ridiculous to you, but the scrum master role doesn’t, you may want to bone up on what a qualified scrum master can contribute to your scrum project.

There you have it. In this segment, we’ve talked about the roles of product owner and scrum master in Agile. You should understand the key functions of these roles and a sense of the value each lends to the Agile team and project. From this, you should grasp why skimping on these positions is a recipe for failure.

5 thoughts on “Agile. Product. Owner. Scrum. Master.

  1. Bry, thank you so much for the deep dive into this question. I like how you systematically evaluated each of the 6 possible approaches to see why that was a bad idea. I really wanted to explore this topic and prior to now I hadn’t taken the time to really think deeply on this question. I will be writing more about it myself in an upcoming post on my blog.
    Cheers!
    Anthony

Leave a reply

Your email address will not be published. Required fields are marked *