Headline graphs are from Creative Commons. Oscar the Octopus is an uncopyrighted original art work created by Walter Elias Disney.
Increasingly I am seeing Scrum Masters double-, triple- and quadruple-booked on projects. This has happened mostly in software development-for-pay situations, but it may happen in internal IT shops as well. It’s disturbing because it may be a symptom of numerous dysfunctions:
· The belief that Scrum is all about meetings; lower-skilled Scrum Masters reinforce the impression that facilitating meetings is all there is to it.
· The work not needing Scrum (or wanting to go with another approach), but someone’s standard process saying you have to do Scrum.
· Scrum Masters being overworked by their companies, who spread them too thin in order to avoid hunting and nurturing this skill. (I’d love to be an Inspector General once again, and investigate whether government contracting companies are billing their clients full-time for quarter-time work.)
The outcomes of this situation are predictable: Scrum Masters have too little time to do real analysis of the backlog and work data, don’t have time to help remove blockers, and barely have enough cycles to understand the context behind a Scrum Ceremony.
The Facilitation Fetish
I once worked on a team whose Team Lead thought that great facilitation skills were what being a Scrum Master is all about. This individual couldn’t be persuaded that there was much more to agile than cool meetings, so we went into über-facilitator mode. In private conversations, we called it “feeding the facilitation fetish.” Every meeting had ice-breakers, cool activities, rich graphics, and seasonal themes - even if it was light on useful outcomes.
Those approaches to facilitation are useful to enrich training and outreach events. By themselves, however, their impact on Product Owners and Developers was so-so. Shaking up routine events was fine, but the business and technical teams really needed the agile coaches and Scrum Masters to understand their problems, and to have sufficient Information Technology program experience to help solve them. Facilitation was the sizzle, but it lacked the solutioning-building support that is the steak.
Capitalize on the Scrum Master Role
In many of my early projects, the having a full-time Scrum Master would have been a waste. Most of the teams in my organization were small (usually around five people) and self-organizing by default. They were closer to the eXtreme Programming model than to Scrum in terms of needs and skills. Someone called the “project manager” emerged on every team, but that person was invariably a fellow coder who got promoted to that role. These so-called Project Managers were actually much closer to the XP role of “coach,” although they did also have some financial and personnel duties. They did a lot of the customer engagemeent work and roadblock removal; any additional support they needed was provided by the middle manager they reported to. On small teams, it was manageable, and tacking on a Scrum Master would have been laughable.
Facilitation is a vital skill, but it is a small facet of the Scrum Master’s job. While it’s hard to be a good Scrum Master without being a good facilitator, it’s possible to be great facilitator while being a lousy Scrum Master.
More than once, I’ve worked in situations where agile coaches over-emphasize one particular skill or another to the detriment of focusing on good Information Technology and quality. We all have our strengths and comfort zones. The comfort zone of a scrum master should not be in Scrum ceremonies; it should be in effectively helping quality IT systems come into being.
As I’ve worked with other teams around the world, ranging in size from tiny to massive, I’ve seen many where a communication function to help them coordinate, communicate with outside groups, and deal with obstructions outside their direct scope of control was useful. I’ve also seen increasing cases where basic IT project expertise, such as elicitation and customer interface, just isn’t there. A guide or roadblock-buster to help get things done is needed. Enter the Scrum Master.
Really cool FFF logo copyright 2018 by ISPI, LLC. We’ll be waiting for the t-shirt orders to come pouring in.
If you are in a situation where you need a Scrum Master, you should use the role fully. Get your value out of it. Understand what the role is for.
First of all, the Scrum Master role is not primarily about facilitation. Teams should be able to facilitate most meetings. My preferred model is where a team (including Product Owners and Developers) eventually run all of their own meetings. The Scrum Master shuts up, takes notes and only interjects where things are going off the rails. They tend to address any problems how Scrum ceremonies are run by providing coaching afterwards, not during the meeting.
Aside from the guidance role, the Scrum Master provides vital analysis of team data, makes that data accessible to sponsors, and helps with any disconnects or dependencies that hamper the development team. The scrum master may not own exclusively those relationships outside the team. When teams are performing highly, they may take over managing some of those relationships, as well. The need for a full-time (or even part-time) Scrum Master may go away at the small team level - until they run into more complex situations where managing hurdles become a distraction.
Can They Multi-Task?
Maybe they can multi-task. Probably not.
The adage goes that a good Scrum Master can handle two projects, a great one can handle only one. Scrum Masters do more than just facilitate meetings. Data analytics, data communication, and roadblock busting take time and focus. If the Scrum Master’s time is so limited that all she has time for is facilitating a few events, then you’ve eliminated what’s most important; what’s left are things the development team could do itself.
I have seen some Scrum Masters who are more than double-booked, and who are impressive in their way. Sometimes they are highly knowledgeable of the system being worked on, of the organization’s politics, and of the development team. But over time, the same behaviors tend to surface:
· The Scrum Master falls back into directive PMP mode, assigning tasks out to developers rather than allowing “pull” from the backlog. This is necessary, because the Sprint Planning meeting is about the only time the Scrum Master has to be sure everything will get committed to. (Note the Scrum Master thinking it’s his job to do that, too; it isn’t.)
· The Scrum Master, in order to provide his value, becomes a hard-charging pit bull. Changes made without his permission are treated as insubordination.
· At the other extreme of the spectrum from the pit bull, the Scrum Master becomes passive to the point of apathy. Neither of those extremes fits the servant-leader demands of the role.
· The Scrum Master, not having time to fully engage, gets brushed aside by the Product Owner and the Developers. Often this results in important events degrading into rote exercises and being dropped. The Scrum Master doesn’t have the time or credibility with the team to help them explore the value of pursuing an agile mindset at all, much less Scrum.
· The Scrum Master fails to help the team mature in its understanding of the organization and how to conduct itself within the organization. Without this leadership, teams often get misled into power struggles and sub-par practices. One of the greatest blockers to all IT projects, politics, takes over without a strong advocate and champion of agile approaches.
Whether the Scrum Master becomes an aggressive facilitator or a passive one, being constrained to running events makes her less effective at removing team roadblocks. Aa frustrated Scrum Master boxed in by the facilitation fetish may become a source of roadblocks by demanding all meetings meet a rigid level of formality or always start with icebreakers and other cute activities.
Having a Scrum Master spread himself too thin, even a great one, echoes a typical management mistake with high-performing teams: breaking up a top-notch team and placing its members on new teams in order to sprinkle the excellence around. What actually happens is that top performers are yanked out of a successful environment, and forced to work with reluctant or less competent teams, with no organizational change strategy, communication, training, or other preparation.
This approach limits success. Some valiant people will attempt to succeed against all odds for a while, some will become demoralized. Some will even leave. The net result is usually the same: a high-performing team becomes dispersed to seed several mediocre teams.
Applying this mentality with Scrum Masters has a similar outcome of reducing effectiveness. Having no time to do the core tasks well, the over-committed Scrum Master winds up doing only part of her tasks. Even if she does those well, it isn’t enough. No single team gets the full support it needs from a Scrum Master. Instead, several teams get not enough support. It’s a variation on “Do More With Less,” which generally means, “Do Less With Less.”
If managers want to spread around the skills of a high-performing Scrum Master, one option would be to have that person train and mentor other Scrum Masters. But those junior Scrum Masters should each be allocated full time to a development team in order to learn how to do the role well. And a core part of the mentoring should be on road-block busting and helping make the product evolution visible — not merely facilitating events.
Which leads us to the topic of scaling. In a team-of-teams situation, Scrum Masters have a more important role than asking the “three questions” during Daily Scrums (which some point out even isn’t part of Scrum at all.) They are concerned with helping teams synchronize work so that the product integrates and is tested in Production-like environments as frequently as possible, and even deployed to Production frequently where feasible. Scrum Masters work together to determine what cadences are appropriate across the initiative, help teams agree on how to use time boxes effectively, how to manage elicitation non-redundantly, how to manage solution design effectively, how to determine technical interdependencies and interfaces, how coordinate integration and tests effectively, and how to deploy. They have to “know a thing or two about a thing or two.”
In high-tech environments, I’ve observed that these Scrum Masters are often engineers. They have an aptitude for the role, the primary facets being systems thinking and critical thinking. Surprisingly, seniority has not always been a critical factor, although some experience and skill are present. The common denominator for success for these Scrum Masters in high-pressure situations has not been the ability to facilitate better than anyone else.
How Much Multi-Tasking?
My experience is that Scrum Masters can only effectively multi-task only under certain circumstances:
When they transfer facilitation duties to the teams so that team members can run their own Daily Scrums, Backlog Refinement, Demonstrations, and Retrospectives. Facilitation become a commonly understood skill held by multiple team members.
When the team is stable and in need of only periodic coaching and reinforcement from the Scrum Master. They operate more under the XP model than the stereotypical Scrum team (which is often based on start-up Scrum, not mastery.)
When the roadblocks faced by the team are manageable enough that they don’t pose risk if the Scrum Master is also busy supporting another team.
When the roadblocks faced by multiple teams tend to be routine and similar, so that the Scrum Master addressing them for one team actually benefits several teams.
Admittedly, coming up with a rule set for allowing Scrum Masters to multi-task is dangerous. There are always those managers who will find some loophole to excuse doing something they shouldn’t do. So, I publish the following graph with hesitation.[1] Although there may be other factors, this graph focuses on the complexity of the situation (team discipline and project complexity) and on the skills of the Scrum Master.
The premise of this graph is that simple systems with highly disciplined teams possibly can do with a (minimum) half-time Scrum Master without constraining that person to merely a Facilitator. Larger and complex projects, or those with less disciplined teams, still need a full-time Scrum Master. (Really large projects may actually be doing something other than Scrum while keeping the terminology.)
The X axis is project complexity,. going from simple to highly complex. Scrum Master skills are along the Y axis, going from novice to highly experienced. A junior Scum Master (even with a coach) can’t handle the needs of even a fairly simple project part-time. Even if the development team is highly disciplined, a junior scrum master runs the risk of falling back on facilitation skills in order to remain relevant among the fast-paced work going on around him.
In his play “Peer Gynt,” Henrik Ibsen describes a character going through life with the motto, “To Thine Own Self Be True.” Throughout the play, however, the character Peer Gynt shows himself to be a moral mediocrity. In the end he faces having his soul melted down for raw material because he is too is too selfish for Heaven, and too insipid for Hell.
The line from the play stating that the character’s real motto all along had been, “to thine own self be enough” is priceless. Overextending Scrum Masters (or anyone else) creates a professional purgatory that crushes or repels the highly skilled, and attracts merely enough.
If you are considering having a Scrum Master multi-task, ask yourself the following questions:
Is this based on team need? Or is this just an attempt to cut overhead costs?
What caused this situation in the first place? How do I prevent it from happening again?
Do I understand the Scrum Master’s role? Am I asking for something that will make a highly effective Scrum Master ineffective?
Will this be temporary? How can I ensure that?
What happens if my Scrum Master quits because of my decision to have her multi-task?
If you do have a Scrum Master multi-task, evaluate that situation and, if necessary, change it. Some changes could be:
Shift to the eXtreme Programming model whereby the more experienced team members take over much of what the Scrum Master would do, especially facilitation. Free up the Scrum Master to address blockers and help with data analysis. (Remember, XP has no separate Scrum Master-like role. In some situations, this is preferable).
Hire additional Scrum Masters.
If work has shifted to Operations and Maintenance mode, switch over to Kanban.
Summary
In his book “How to Become CEO”, Jeffery Fox advises to never say “no” to an assignment. While that may be a good recipe for climbing, it is not a good recipe for successful agile development. Overburdening and overconfidence are partly what brought the Agile Manifesto about in the first place. Avoid the Myth of Multitasking.[2] Allow your Scrum Masters to focus and do great things.
~~~
Update: In an interview with BuiltIn, Kent Beck stated that Agile has become “a few religious rituals carried out by people who don’t understand the purpose that those rituals were intended to serve in the first place.” No elaboration needed.
~~~
[1] “Point with pride, view with fear!” Bob Read, Boeing Integrated Defense Systems, regarding metrics.
[2] https://www.thenewatlantis.com/publications/the-myth-of-multitasking