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.
Aha! So They Can Multi-Task!
Well, maybe they can mutli-task.
The adage goes that a good Scrum Master can handle two projects, a great one can handle only one. The reason for this is that Scrum Masters who do more than just facilitate meetings need time to carry out their responsibilities. 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 ceremonies, then you’ve eliminated everything important; what’s left are things the development team could do itself.
That’s why my thinking about this is binary: either you need a Scrum Master more than half time, or maybe you don’t need one at all.
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 her 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 ceremonies degrading into rote exercises and being dropped, because the Scrum Master doesn’t have the time or credibility with the team to help them explore the value of pursuing an agile mindset.
· 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.
The net result is that the Scrum Master becomes either an aggressive facilitator or a passive one. Either way, the Scrum Master becomes less effective at removing team roadblocks, and in fact can become a source of roadblocks.
Having a Scrum Master spread herself too thin, even a great one, echoes a typical management mistake with high-performing teams: breaking up a top-notch team into smaller 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 valient 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.
Following this mentality with Scrum Masters has the same essential result. 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 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.
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. 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 elictation and design effectively, how to determine technical interdendencies and interfaces, how coordinate integration and tests effectively, and how to deploy. They have to proverbially “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 facet being critical thinking. Surprisingly, seniority has not always been a critical factor, although some experience and skill is a common factor. The common denominator for success for these Scrum Masters in high-pressure situations has not been the ability to facilitate better than anyone else around with no other domain skills.
Allowing for 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 because the Scrum Master is distracted with 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.
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 the mediocre — merely enough. We must avoid that.
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 just quits because of my decision to have him multi-task?
If you do allow a Scrum Master to multi-task, look for ways to monitor that situation and, if necessary, change it. Some changes could be:
· Assign an assistant, making sure that person has complementary skills. Don’t have an assistant who is not skilled in the things the Scrum Master doesn’t have time to do.
· Shift to the XP 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 many situations, this is preferable).
· Recognize when work has shifted to Operations and Maintenance mode, and switch over to Kanban or Scrumban. Re-focus the Scrum Master’s work appropriately (or, allow the Scrum Master do to so). If she is competent, this won’t be a problem.
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