ScrumMaster is Not (Just) a Team Facilitator
The False Dichotomy
Bisexuality immediately doubles your chances for a date on Saturday night.
— Woody Allen
"Do you work as a ScrumMaster or an Agile coach?" — that's a question I'm being asked quite often. Far too often. When I answer that I am a freelancing agile coach, I'm sometimes also asked if I am an "enterprise agile coach or [I guess just] an agile coach". I silently walk away.
Just a few days ago I returned from an open-space un-conference where a group of experienced agile trainers were trying to define the levels of agile coaches — from a team facilitator (a.k.a. powerless coach) to an enterprise-level agile coach (a.k.a. agile god). That discussion didn't go too well.
But I have to tell you that the certification bodies love these wordings. Imagine: if you can convince someone that being just a team-level agile facilitator (a poor boy) can become a level-five-blue-belt-god-mode agile coach — just sign over here, pay over there, and receive a new stamped paper with a hologram.
I personally don't think defining these levels is a good idea. I actually think it is a bad one. Although of course there is a mastery path (or paths) we all follow along our professional journeys, the formal ladder of agile coaching levels is already doing more harm than good to our industry.
But these (certification) machines have been running for far too long to be stopped. So I'm not going to fight them. Instead, I'll try to explain to you, dear human, why this duality — team facilitator vs. real enterprise agile coach — is adding close to zero value.
Speaking of value…
The Value Streams
Scrum helped us to suck less.
— Source unknown
Scrum is a process framework used to manage complex product development. At the heart of Scrum (and of any other agile framework) is the idea of infinite continuous process improvements with the bigger purpose of delivering more value faster to the customers.
The schematic view of the process of delivering value from idea to cash (also known as a value stream) in the most simplistic way might look like this:
In real life a value stream will likely have queues, buffers, loops, bottlenecks and god-only-knows-what. It might start looking as complicated as the example below (taken from an article on Value Stream Mapping):
But in its pure essence: it is still a flow of value that is hopefully reaching its customers.
So the goal of any agile product-development framework (like Scrum) is to help manage — minimize — the complexity of the product-development process in order to be able to start optimizing the value stream. And from this view, the role of an agile coach is to help the organization (including its leaders) start understanding how their value stream looks and how to go about improving it… continuously.
As a matter of fact, the latest State of Agile report proves this, claiming that over 60% of organizations adopting agile are pursuing acceleration of product delivery.
Hence, Coaching Development Teams is Not Enough
If your project is delayed, you should have started it earlier.
— DeMarco, Lister, Waltzing with Bears
Continuous acceleration of product delivery can't be achieved by working only with one (or even several) development teams — unless they are an endless source of all types of inefficiencies. Which is unlikely to be true.
Instead, it requires having a holistic view of the value stream (based on real facts). This implies coaching all involved parties during all of the activities of the value stream: from early idea generation and validation, to feature development and deployment, to maintenance and post-release activities.
Sadly, I see many ScrumMasters who are limited — by the status quo of their organizational structures — to working with development teams. These chained agile coaches are not empowered to help improve the value stream and hence can't help accelerate product delivery. They keep optimizing development processes as if it were the only box of the value stream. And in most cases, there are many more things to start improving.
Working with development teams can be very exciting and inspiring — it requires not only a hell of a lot of empathy, patience and self-awareness, but also a deep understanding of the nature of software development. Sadly, it is not enough. As we all intuitively know: optimizing a part of the process that is not a bottleneck will not have any positive effect on the overall system.
Stuck in Water-Scrum-Fall
"We do Scrum in software development, but since our development teams don't have control over the production environment it is up to the ops now to get it deployed. I'm assigned to the dev team. They have another coach. Perhaps they do kanban." — I do hear this, and it makes me sad.
The dynamics of such an organization are interesting and exciting (for an observer). The organization will keep optimizing and self-improving, but since no one has an overall view or interest in optimizing the whole, it will likely become a source of various local optimizations.
So no surprise that I see companies getting rid of the ScrumMaster role. It doesn't add value. The changes are not observed. In fact, the level of conflict and employment dissatisfaction might even be growing — because of the gap between potential and reality.
And this is not a unique case. They say "this role is not adding value". Of course not, if the key function of the role is defined as "facilitation of team Scrum meetings".
Set ScrumMaster = Agile Coach for a Product Organization
See, understand, and optimize the whole system (not parts), and explore system dynamics. Avoid the local and sub-optimizations of focusing on the 'efficiency' or 'productivity' of individuals and individual teams. Customers care about the overall concept-to-cash cycle time and flow, not individual steps.
So if you want real systemic improvements (and not something fake like an increase in team velocity), you need to redefine the scope of the work of your ScrumMasters. They need to work with the overall product organization. (Otherwise you may just delete ScrumMasters, as Tobias Mayer once said.)
Good news: you don't need to choose between team facilitation and organizational coaching when defining the real ScrumMaster. There is no false dichotomy.
Instead of assigning ScrumMasters to teams (not enough view of the whole) or having your enterprise coaches fly too high (not enough knowledge of the work being done) — see your company as a set of product organizations (organized by value streams), and then have one or several ScrumMasters focus on and coach each of the streams, from idea to product to cash.
Newly formed teams and product organizations will need more team-level coaching than more mature ones. So the density of coaching will likely vary over time, as illustrated below:
Further inspirational reading: a product-wide definition of a ScrumMaster.