You’ve been redirected to SolutionsIQ.com. BigVisible and SolutionsIQ have joined forces, and–lucky you!–you still have access to all of that awesome content. Dig in.
Recent discussions with my colleagues have got me thinking precisely about the role of ScrumMasters in organizations. When I first started coaching teams to adopt Scrum I would argue that the ScrumMaster was not—and should not be—a functional manager. ScrumMasters were something else, a servant leader, a team coach, even a cat herder, but they were definitely not supposed to be managers who directed the work of team members. I believed, and encouraged companies to try and develop the ScrumMaster as something entirely distinct from project managers or functional managers. It was a third role with a different description and career track.
Today, after having coached many teams, I’m not so sure. I’ve seen that kind of ScrumMaster role work sometimes, but I’ve also seen quite a few attempts that have ended poorly. Organizations that try to shoehorn a special ScrumMaster role into their existing structure, tend to regard the ScrumMaster as nothing more than a “facilitator who runs a couple meetings every sprint.” As such it becomes a very diminished role, one that people consider a “part-time assignment.” Too often ScrumMasters become multitasked to incompetence as they are expected to support too many teams. Or the “title,” such as is it is, is simply given to someone on the team with no real expectation that they should do much more than try to keep the stand up to 15 minutes. In other situations I have seen managers—usually project managers or development managers—assume the role of ScrumMaster, run the basic ceremonies and change very little else about what they do every day.
This is causing me to rethink my assumptions and I find myself coming to a potentially controversial conclusion. ScrumMasters and agile coaches are actually just managers, granted they embody a different set of values and ideals than those espoused by command and control managers, but they are managers nonetheless. Thus, when organizations begin to adopt practices like Scrum and they begin to deputize ScrumMasters, they are effectively changing the leadership and power structures of the organization. The ScrumMaster’s role is in direct conflict with functional managers as they compete for the same niche within an ecosystem.
As I recall from biology, no two species can occupy the same niche, when two do there will invariably be competition until one is forced from it.
What Exactly Does a Manager Do?
Before I can confront the question head on about whether or not managers and ScrumMasters are the same thing, let’s agree on some sort of framework for scoping what a manager actually does. This in itself is probably a loaded question and one that many people see very differently. For my purposes, let’s take the 10 management roles espoused by Henry Mintzberg, a professor and prolific writer on the topic of management. He identifies three different levels of activity and describes the various roles played on each plane. I then pulled some of the basic ScrumMaster responsibilities from the latest version of the Scrum Guide to see how they fit.
- Ensure the rules of Scrum are understood and implemented
- Ensure Scrum team follow the practices, theories and rules
- Communicate to those outside the team know what interactions are helpful and which are not
- Communicate the vision & goals, as well as specific items within the backlog to the team
- Teaching the team to create clear & concise backlog items
- Work with other ScrumMasters to help with the implementation of Scrum in the organization
- Coach and lead the team to build high quality products
- Lead organizational change to help Scrum teams be more effective
- Remove impediments
- Find tools & techniques to help the PO manage the backlog
- Facilitate meetings
Now some of these may appear to be quite command and control, but when you dig deeper, they are merely meant to represent concepts, which can be done both in an authoritarian way and by enabling those within an organization. For example, controlling has a very negative connotation, implying that one of the key roles of a manager is to direct others by formal authority. While this is true, that is a very narrow definition. Controlling also includes the design of the environment and organizational structures—which would most likely include Scrum teams, team space, maybe even some of the information radiators—in such a way to guide people towards desired behaviors. Defining rules for decision making and delegation would fit within this category as well. Thus, while the first impression may be that this model does not apply to more modern interpretations of management, I actually find it quite flexible. Indeed, it may cause us to rethink what we do when guiding agile teams. For example, when I work with a team using a Kanban board, and I put a work in process limit on a step, or I tell a Scrum team to respect a 2-week timebox, I am actually controlling them.
If we look closer at the actual descriptions of the ScrumMaster’s responsibility, it becomes clear that this type of model is absolutely compatible with what a ScrumMaster does. In fact, if I showed you the items in the right and simply replaced “Scrum” with something like “SDLC,” I’ll bet most people would think I was talking about a very traditional project or development manager.
How Does the Conflict Manifest Itself?
If organizations don’t confront this elephant in the room, it can lead to some unhealthy compensating behaviors. In organizations where there is a strong hierarchy of functional managers, the ScrumMasters may find themselves in direct conflict. I have seen teams where developers were forced to work from what we dubbed the “shadow backlog,” which represented the work their line managers gave them, whether or not it aligned with what their team was doing. As one of the developers pointed out to me, his functional manager controlled his bonus and career path, and that could create a pretty compelling case to neglect what the product owner was prioritizing for what his boss was telling him to do. This has the added problem of breaking down communication, as functional managers lean on their own direct reports to get things done in the organization. The specifics vary, but in circumstances like this, it becomes very hard to motivate a self-organizing team in these circumstances; all but the best ScrumMasters find themselves embroiled in political fights they can’t win.
The other common anti-pattern is when the role of project manager is simply subsumed by another role—frequently development managers or project managers in my experience—and there is no discussion about how the ScrumMaster role reinterprets and lays out different ways to achieving the ends that many manager are used to realizing with fairly directive means. Again, this is not a hard and fast rule. I have seen some project managers in this situation really excel and become outstanding ScrumMasters, but it is not guaranteed.
These are just two of the most common forms of conflict, and each situation is different. Fundamentally though, I am coming to the conclusion that as we introduce this new management role, which is most likely competing with the traditional managers, we are surfacing a bigger struggle within organizations. In this situation, those who are part of that traditional organization are very likely to feel threatened by this model and only resist harder.
The Unfortunate Case of Coaching and Management
Just last week I was pointed to a blog by Scott Bellware, “The Unfortunate Case of Agile Coaching and Servant Leadership”. It posits some interesting ideas, and I can’t say I agree with all them, but let me start where he begins the post by listening to James Womack, who argues we have too much leadership and not enough management.
When Womack talks about heroic leaders trying to convince other people to “follow me” and act against their own best interests, it sounds very much like what I have seen some ScrumMasters do as they attempt to unite a cross-functional team within an organization that continues to maintain a strong functional hierarchy of managers independent from the teams. From here Scott points out that in most organizations seeking agile coaching, the root cause problem is that the management team is not currently equipped to the task of running an organization using agile practices and techniques. If this is indeed true, then trying to carve out the ScrumMasters as a new role independent from the old structure becomes an approach that may come in conflict with the traditional management structure or simply never be empowered to realize the change the organization hoped to achieve.
So, if I go back to my earlier biases, my efforts to coach teams may have been counterproductive, or at the very least, not as productive as they could have been. There is a perspective within the agile community that says management is the problem, that we need to clean out middle management and empower teams. If only managers could get out of the way and let people do the “real work”, then we would see things get much better. At times I have subscribed to this thinking and sought to build independent & autonomous teams outside of the hierarchical management structure. This gets me thinking though, what if the point of intervention was focused on the managers, rather than the teams. What if the point was to guide managers on how to lead work by creating the boundaries and constraints of Scrum teams, rather than assigning individual tasks? It seems one challenge would be the high level of interdependencies between managers.
With most organizations functionally structured, multiple managers need to be involved in the delivery of one thing. To take a simple example, imagine an organization with analysis, development, and testing structures. If we instructed management to guide teams with constraints and environment design, all of those managers would need to agree in order to build a single environment with shared constraints. This probably talks to a larger problem, that managers frequently don’t work as teams accountable to one another, and instead oversee their own functional area with limited view into the overarching goals and challenges of the organization. Ironically, this is just like the traditional waterfall development team, where the developers have no idea what the testers will do as everyone is managed by a project manager.
A coaching intervention focused on those problems would look very different from the grass roots, bottom-up approach many of us are familiar with, where we would coach a couple of teams, show how awesome they can perform, and then look to grow that. That approach may still have merit, but perhaps we need to acknowledge that it was developed in a time when we were still trying to prove how effective these practices were. Today, the consensus has shifted and quite frankly I don’t know of any organization that isn’t already trying to do something with agile. So, the need to “make the case” may not be what it used to be, allowing us to try more ambitious, higher level, interventions. Exactly what those look like, will need to wait for another blog post.