Using the Scrum Framework? Stay in your Lane

Anthony Mersino September 22, 2020

I wrote before about bad Scrum and other abuse of the Scrum Framework. One of the common abuses that I see in organizations using Scrum is that they don’t properly use the 3 Scrum roles.

To be effective, these three Scrum roles need to be implemented properly and protected. Like bowlers in a bowling alley, we need each of the roles to stay in their lane.

Just 3 Roles In the Scrum Framework

It’s pretty simple actually, especially if you have been around long enough to understand why the roles are set up as they are. In Scrum, there are three official roles.

There is the Product Owner, the Dev Team, and the Scrum Master. Each of them has a distinct role and set of responsibilities. And when each of them doesn’t stay in their lanes, we get subpar results and bad Scrum.

Let’s start with the Product Owner. In Scrum, the PO has the vision and business acumen. They make decisions, say no, and prioritize the backlog. The Product Owners is focused on identifying the “what” and making sure they are getting a return on investment.

The Dev Team doesn’t focus on the what- they focus on the How. They work together to figure out how to turn the prioritized backlog items into done increments of the solution. The Dev Team is self-organizing and no one outside the team should tell them how to do their job.

The third official role in the Scrum Framework is the Scrum Master, arguably the most confused, abused and maligned role of the 3.

The Scrum Master helps the team self-organize and use Scrum effectively. They are not a PM and they don’t do PM type stuff. The Dev Team or the PO handles most of those project management type tasks.

Everyone else is in a role outside the Scrum Framework. And they should stay in their own role. Like bowlers in the bowling alley, it would make no sense for them to play outside their lane. Could you have someone tossing a bowling ball down the wrong lane? Well no, you should not.

Frequent Abuses of The Scrum Roles

Here are some other frequent abuses that I’ve seen with people not staying in their lane.

1. Telling the Team How to Work.

   Many organizations that introduce Scrum don’t let the Dev Team self-organize. It is typically managers, but sometimes Scrum Masters that tell the team how to work.

   They don’t trust the team or believe they can figure out the how. It could be that they have hired a bunch of dumbasses. Or they created learned helplessness by doing things for the employees and teams that the team should have done for themselves. Either way, someone outside the team is telling the team how to work.

2. A Technology Manager Acts As the Product Owner.

   Another common dysfunction is to have an IT manager act as the Product Owner. I’ve seen this happen when IT doesn’t trust the business to make decisions.

   Huh? This approach fails because we are no longer encouraging collaboration between business and technology and creating shared accountability and results. It simply sets up the likelihood of finger-pointing and blame.

3. The Dev Team Acts as their Own Product Owner.

   Similar to the previous item, the Dev Team should not try to play the role of the Product Owner.

   When this happens, the team tends to work on internal-facing technical items and build solutions by the application layer, rather than building true business-facing functionality. And similar to the previous item, this approach leads to a lack of collaboration and shared accountability.

4. Product Owners Second-Guess the Team.

   I’ve seen situations where Product Owners were constantly second-guessing the team on their estimates or complaining that the team took too long or cost too much.

   This undermines the team’s effectiveness and the virtuous cycle of delivery and affirmation that most Scrum Teams enjoy. In the few times I have seen this happen, it seems to be a political statement more than anything.

   Digging in I found that the Product Owner was previously part of the technology team and they thought that they knew more and could do a better job than the Dev Team.

5. Over-functioning Managers.

   Managers are a bit of a special case. In many organizations that are not using Agile and Scrum, the managers tend to over-function. They tell people what to do and how to solve problems.

   They try to make all the decisions and control everything that happens. This will fail miserably in Scrum. Instead, managers should focus on a few simple things:

   • Hire great team members
   • Align rewards to retain people and support teamwork
   • Clear impediments
   • Create the environment for people to do their best work

It’s pretty simple. Stay in your lane. So why don’t people do it? What do you think?

This article was originally published here.

Business & Finance Articles on Business 2 Community

(30)