I failed Scrum.org’s question about whether or not the Scrum Master is a management position. I still think it was a trick question, and I did manage a 77% so I guess I’m qualified enough to still talk about Scrum.
The textbook definition of a Scrum Master is someone who “removes impediments” and facilitates the process for the team. I suppose from a process perspective the Scrum Master does do management type of work but in general terms the Agile community doesn’t agree that the team’s manager makes a good Scrum Master. The general thinking is that a manager can circumvent team self-organization and creativity by directing the team and in theory this is fine but in practice it’s just not reality for medium to large sized organizations.
Let’s consider this complex, enterprise organization structure:
(click to enlarge)
This example is loosely based on an enterprise organization I worked with. A Scrum Master will have extreme difficulty trying to cross the boundaries presented in an enterprise organization. Removing impediments are going to be extremely challenging, if not impossible, in this type of organization and there are a number of reasons why:
- Functional Department Objectives: Team members will be taking direction from conflicting objectives. QA’s mandate may to be to reduce bugs while the PMO’s objective is to get the project out on time and on budget therefore sacrificing quality in the process.
- Exposing Dysfunction: Managers are happy in their silos, crossing boundaries to remove an impediment can be seen as a threat to the responsible manager. I encountered a situation where the team I was working in was consistently losing 1 – 2 days of productivity per sprint due to environment problems. When I began removing this impediment all I did was piss off a lot of people and nothing happened. They were quite happy with the current state because it was just too hard and expensive to have proper environments. Even better when I asked “so what do you expect the team to do during these blackout periods?”. The answer was: “nothing”.
- Team member fear: Having multiple managers providing process and direction to the team makes self-organization difficult. Team members will struggle with the courage to do the right thing over getting into a conflict with their manager.
- Impediment is technical in nature, control outside scope of department: I personally ran into this quite a bit. In many cases a back-end system was not available and the organization had a complex support system that seemed to be designed to block all progress by bogging down people in process. Let’s say the team is working on an application that interfaces with a service layer controlled by IT. The process dictates a complex ticket system for resolution and escalation requires moving up your silo to the appropriate level, across to the responsible department, down that stack and then back up, across and down. Sounds confusing doesn’t it? It is. This encourages silo-type behaviour, mis-trust and a whole host of other dysfunctional behaviour designed to follow process over getting results.
- Resistance: I’m not a fan of the term ‘resistance’ personally. Resistance is simply a symptom covering a reaction to change. In the diagram above, if there is fear or resistance at any management level (and there usually is), a Scrum Master’s job is all that more difficult as the SM doesn’t have any power or authority to remove impediments.
So what’s the solution? To be honest, I don’t entirely know. Creating a matrixed organization where the team reports to the Scrum Master may work. Firing all the managers and flattening out the organization may work. Moving from a project-based organization to a product-based organization may work. Pushing the fluff of “hey, can’t we just all get along and work together” may work (although I doubt it). It’s probably going to be a bit of all of these actually but hiring Scrum Masters is the wrong first step.
Based on the sessions I attended at Agile Tour Toronto, no one has Enterprise Agile figured out to any degree of certainty and my opinion is that people are focusing on the practices, not changing the system in which those practices are used.
All I’ve figured out so far is that a Scrum Master in a large organization has no power or authority and a smaller sphere of influence to help with change. If you are expecting to hire a bunch of Scrum Masters to make your enterprise Agile, just wire the money you plan to spend on them to any registered charity, it’ll be money much better spent in the end and you’ll get some nice tax breaks.
Let me tell you story about a team I worked on and why we were successful despite the number of constraints on our team:
- Extremely strong Product Owner: she knew the domain, she knew the politics, she knew was battles to fight and which ones to let go. If our team was technically dependent on a group outside our influence and they wouldn’t help, she’d drop the backlog item and promote something else. Then she was manage the stakeholders appropriately.
- Achiever-level(1) Team Members: We have 1 tester and 1 programmer who were very much achievers that were intrinsically motivated to learn about Agile and technical practices and were genuinely interested int he work they were doing. They inspired the team and were greatly responsible for creating a high performing team.
- Catalyst(1) Scrum Master: I don’t like taking any credit for the success, the team did the work, however I did get some great feedback that I was able to provide a team system that allowed them to step up and take risks. I listened to their concerns, I had one-on-one sessions with them, I gave them timely feedback and I was a pain in the ass when I felt I needed to be a pain in ass.
- The Perfect Storm: Having said all of that, this team had something special. There was a great mix of personalities, domain and technical knowledge/skills and we had a very open and honest relationship across the board.
While this team and project was successful, as a whole, the adoption was not. (sidebar: it’s been 18 months since the adoption started and it’s just now hitting critical mass) The point is, organizations often think hiring a bunch of Scrum Masters to make their projects ‘Agile’ and yet don’t consider the system is not designed to support Agile processes. I spent most of my time at this organization acting as an Agile project manager all the while kicking up to influence change. This organization perceived Scrum Masters as just Agile project managers and didn’t understand that in order to be successful with Agile, the system must change.
Before you decide you need a Scrum Master, take a step back and understand your system and context. A Scrum Master that reports to a manager who may end up looking incompetent from the visibility Scrum will create, isn’t likely to help remove impediments. There’s a reason why courage is a value of Scrum, without it you’re just left with a dysfunctional Agile process instead of a dysfunctional…whatever it was before.
(1) For more information about developmental models, check out Michael Spayd’s article on Agile leadership with references to Leadership Agility by Bill Joiner.