Why ScrumMaster is a Full-time Job

Teams and sponsors invariably ask the following question during initial Agile/Scrum training: “Is ScrumMaster really a full-time job?” When I immediately answer with a resounding “Yes,” the looks of incredulity are impossible for the team and sponsors to hide and equally impossible for me to ignore. More explanation is always necessary.

It is, however, a perfectly valid question. My response to the accusatory stares and occasional guffaws begins with a description of what constitutes a living, breathing product team. In the software industry we have deluded ourselves for decades that a group of individuals who just happen to be working on the same project constitutes a “team.” Therein lies the essence of the problem: building actual product teams is hard work, harder than almost anyone who takes on the role of ScrumMaster for the first time can imagine.

The first problem I encounter as a coach is that most organizations lack a person with the correct skill set to be a successful ScrumMaster out of the gate. I always try to steer clients away from the idea of appointing a ScrumMaster at all, preferring that they ask for a volunteer – after I have described in detail what the role requires. Barring the self-organizing solution, I encourage clients not to appoint a technical lead, architect, or functional manager as ScrumMaster. The first two sets of people are usually interested in the technical aspects of the work only and would find the duties of the ScrumMaster role an unwelcome distraction. Functional managers typically find it particularly difficult to wrap their heads around the servant-leader concept, especially if they are accustomed to issuing detailed instructions to the people inside their functional silo. Functional managers generally also find it difficult to adapt to the idea of cross-functional product teams, seeing such a development as either against nature or as a direct threat to their own positions. Finally, even if a functional manager is completely on-board with Agile values and principles and Scrum practices, the authority relationship that exists may prevent team members from dealing with their manager/ScrumMaster properly. It is difficult as a team member, for example, to express concerns in a Retrospective about the ScrumMaster’s handling of the role when that same person is your functional manager.

None of this is to say that technical leads, architects, or functional managers are always unsuited to the role of ScrumMaster; it is simply a more difficult adjustment at best and an unwanted distraction at worst. My advice always comes back to self-organization. Sometimes the best ScrumMaster is the person on the team who doesn’t have the most advanced technical skills. Since a large portion of the ScrumMaster’s duties revolve around being a Scrum champion and coach, so-called soft skills are much more important to the role than sheer technical prowess. When everyone realizes fully just how thankless and even dangerous (in the corporate/professional sense) the role of ScrumMaster can be, only those individuals who are really interested will volunteer.

My friend and colleague Jeff McKenna often says that the most applicable training he ever received in preparation for being a ScrumMaster was his extensive coursework in family counseling. While this statement initially generates laughter, whether genuine or of the nervous variety, it gets the point across unambiguously. A product team is very much like a family, with the major exception that most or all of the members of a team can choose to join a different team if things get too difficult. For the most part, however, teams have to work through the inevitable rough patches if they are ever to achieve high levels of performance. Remember, the Tuckman Model ends with Performing, but only after passing through the Forming, Storming, and Norming stages.

So what are the essential skills and characteristics of a good ScrumMaster? How about starting with this list, which is neither complete nor exhaustive:

• Calm
• Patient
• Able to listen rather than talk
• Has the courage to take on organizational and cultural impediments
• Comfortable when team members talk about personal issues that affect their work
• Encourages team members to express how they’re feeling about the work, Scrum, their teammates, etc.
• Understands and supports collaboration
• Supports – to the point of demanding – self-management and self-organization
• Tenaciously protects the team from distractions and outside interference
• Dedicated to learning tools and techniques to foster team development
• Understands that it’s about the team, not the ScrumMaster
  

Understanding the role and responsibilities of the ScrumMaster changes the question from “Is ScrumMaster really a full-time job?” to “Who wants to be a ScrumMaster?”

All for now.

...-.-

The Trouble with Agile

I have been on a disturbing number of coaching engagements this year that ended in something less than complete success. Indeed, it would be more accurate to categorize these engagements as failures falling somewhere between dismal and catastrophic, depending on the engagement.

The storyline was disturbingly familiar in all cases, however. Every one of these engagements began with one or more standard Agile/Scrum training courses, which is always a good thing. The disturbing part was the degree to which the training revealed just how uninterested in Agile the organization really was. Attendance in the class or classes was by compulsion, usually to the extreme discomfort of the participants who typically received no reprieve from their normal responsibilities during the two or three days of training. That is always the first “uh-oh” moment in any training course. It doesn’t always end badly, but is certainly not a good way to start.

During the training, as I present the various principles and their related practices, comments from the class indicate where the entire engagement is headed. For example, when I talk about just-in-time planning, relative estimating done by the people doing the work, or working in Sprints and the implication of focusing on a single project for the duration, the responses usually fall into one of several categories depending on where we are in the failure continuum. If an engagement is in the “dismal failure” part of the spectrum, the participants’ responses fall into the realm of “That is so cool! Too bad we’ll never be able to do that here.” If, on the other hand, we’re in catastrophic failure country, the responses are more along the lines of “The PMO/management provides all of our deadlines/scoping/estimates/project matrices and there’s no way that’s ever going to change.” If such utterances emanate from a functional manager, Project Manager, or executive in the class, the needle hits the peg on the “Catastrophic Failure” side of the gauge. Ordinary working people express identical sentiments, but with a sigh of hopeless frustration. Either way, the result is inevitably the same.

Another fatal expression I hear during training sessions on doomed engagements is: “How can we change (insert Agile practice here) to fit with the way we work here?” Or, “How can we (insert company name here)-ize Scrum?” As a coach, you know you’re in serious trouble whenever you hear these statements.

All of these issues boil down to a failure to understand that Agile requires deep and sometimes difficult organizational and cultural change. There is no quick, easy fix, no veneer to overlay on top of a company’s current organization, culture, or processes that can fix their deep-seated dysfunctions.

The vast majority of these failed engagements break upon the rocks of the most fundamental Agile principles and practices: If a company is unwilling to change its organizational structure to break down functional silos so that real-live cross-functional product teams can come into existence, well, there’s simply no use in even talking about the additional layers of change that are required to move forward.

The trouble with Agile is that it is essentially an all-or-nothing package of principles and practices, that is, the rules of the game which must be followed. There is no picking and choosing among key principles and practices, and therefore no magic wand, no quick fix, no “Fix our quality/delivery/efficiency problems, but don’t change anything” solution. Executives, functional managers, Project Managers, and people on the front lines all have to be committed to changing their organizational structures, culture, and processes, sometimes in deep and potentially painful ways, if the company is to reap the full benefits of Agile and win in the market.

“Agile” is a hot buzzword these days and companies large and small (but mostly large) are hoping to jump on the bandwagon. Unfortunately, many companies are looking only for the quick, painless fix, the flavor of the week, not the kind of far-reaching change that is going to transform the organization into a powerhouse of innovation and adaptability. And that is the trouble with Agile.

All for now....

...-.-

Highly specialized teams and the software ecosystem

Winter has definitely arrived -- for the moment -- along the northern Front Range. Before the wind came up, there was a solid 16 inches of snow on the ground here. Now there are bare patches interspersed with deep drifts. Unlike a true winter storm, however, the follow-on was not a deep, bone-chilling cold. It's already just above freezing and the forecast calls for rapidly increasing temperatures beginning tomorrow. By next week it should be downright fall-like again. Wintry weather is so much easier to take when it is doled out in discrete parcels.

But now back to Scrum teams....

Last time I wrote about Scrum teams operating as organisms within an ecosystem. Some teams find their environmental niche very cozy, so much so that they specialize to a degree that makes them vulnerable to changes in the broader ecosystem. Software companies and software operations within other types of companies both operate in notoriously changeable business and technological environments. If a Scrum team becomes comfortable, complacent even, with its current skill levels and dispersion of knowledge, disaster can be lurking just around the corner.

In my experience, there are two problem areas that revolve around specialization. The first involves teams that know their domain and technology inside and out, but have stopped learning. Some teams have even stopped learning about how to improve their processes and interactions, making them stagnant and vulnerable to any changes, whether internal to the team or in the external ecosystem.

The other problem area is internal to the team: individuals have specialized skills, as we expect, but there is very little cross-functionality. The team does not practice pair programming, does not engage in code reviews, does not engage in collective design or shared refactoring -- in short, lacks the generalizing specialists that are key to keeping teams alive and growing. Teams in this state are also highly vulnerable to changes in their ecosystem, but they are even more exposed to changes in team composition. If any member of the team leaves the company or simply moves to a different team, the overly specialized team will suffer as a result. If they have been complacent for a long time, they may not remember how to adapt to changed internal or external circumstances.

So, what's a coach to do? For the first type of specialization, that of stagnant domain and technology knowledge, a good coaching technique is to plan a small amount of slack, say five to ten percent of the team's Velocity, into every Sprint which team members can use to broaden their knowledge. A good tactic is to use Spikes to keep research projects time-boxed and to encourage team members who take a Spike task to provide a report to the team that lays out their findings. As formal tasks, Spikes are also more likely to be taken on during a Sprint. Another way to help a team broaden its knowledge is to place stories or tasks on the team's improvement backlog, which the team plans out during Sprint planning and updates at every Sprint retrospective.

For the second type of specialization, use each Sprint retrospective to encourage team members to set pair-programming rules or goals, schedule shared code reviews, and perhaps also lunch-and-learn sessions taught by each team member on a rotating basis. These ideas for improvement should also be added to the team's improvement backlog, prioritized, and planned out during Sprint planning. Teams that lack adequate cross functionality generally have difficulty meeting their Sprint commitments, making these types of improvements even more vital.

What happens to teams that continue along their path of excessive specialization? As organisms occupying a specific environmental niche, they may suffer irreparable damage if anything about their ecosystem changes, including internal team modifications. In the natural world, organisms that are unable to adapt to a changing ecosystem become extinct. Teams can suffer a similar fate, metaphorically speaking, if they lack the versatility, skills, and tool sets needed to adapt to an ever-changing business, corporate, and technological environment.

All for now.

...-.-

The Agile Team as Organism

In his brilliant book Agile Software Development (2002), Alistair Cockburn describes Agile teams as ecosystems (pp. 109-110). He talks about how teams create their own internal ecosystem, with certain team members frequently having a disproportionate influence on how the team develops and, more importantly, how the team learns to work in its broader environment.

While co-teaching a CSM course recently -- and in the middle of presenting a section about team development -- the thought struck me that Agile teams are actually much more like an organism living in a broader ecosystem, rather than the ecosystem itself. The ecosystem in which Agile teams live exists at several levels, the most immediate being the project on which the team is working, either alone or in parallel with one or more other teams. A team must adapt its behavior and possibly also its composition to the immediate environment if it is to survive, let alone prosper.

Beyond the project environment there are various levels of the corporation, more in larger companies, of course. Beyond the corporate environment, there is the larger system that encompasses the particular market in which a the corporation competes, the regional economy, and finally the global economy. Each of these levels within the broader "ecosystem" affect and influence Agile teams, forming the various threads of a complex web of interactions that play out on a daily basis. At the macro level, an Agile team is subject to the broader trends in the global, national, and regional economies in which that team lives. Any given team's ability to influence its ecosystem on this scale is extremely limited.

Closer to home, however, at the project and corporate (or more immediate corporate division) levels, Agile teams have a much greater influence both on what happens within those ecosystems and how the team adapts as a living, breathing 0rganism within its environmental niche. In the natural world, all organisms make behavioral changes at some level and undergo sometimes startling physical changes driven by natural selection to adapt to their environments. The motivating factor is survival, both of the individual and the species.

Agile teams operate in surprisingly similar ways. First, teams want to survive, or at least the individuals that comprise the collective organism we call an Agile team want to survive. Successful teams, those that survive, adapt to their environment in ways that allow them to occupy a niche in their ecosystem successfully. How do Agile teams adapt? First, they need to be properly constructed organisms, with the ability (and the authority) to change their composition as needed to be effective. Agile teams need to be able to invite new members to join -- and existing members to leave -- in order to adapt to the requirements of surviving and thriving in their ecosystem.

Secondly, Agile teams must use the feedback loops built into Scrum to understand both their environment and what is required to survive in it. The daily Scrum and the Sprint Retrospective are the two primary means teams have of gathering information and acting upon it. Successful Agile teams use these opportunities to adapt to their ecosystem by adjusting their behaviors and composition appropriately.

The definition of a successful Agile team-as-organism is a team that not only survives, but thrives in its ecosystem. As in the natural world, the relationship is symbiotic: when a team thrives, it affects its ecosystem positively as well, that is, the team produces top-quality software, on time and within budget, that satisfies the company's customers, leading to more sales and therefore a better, richer environment for the team. Another similarity with the natural world is that Agile teams are not engaged in a zero-sum game. By improving the environment for itself, an Agile team is enhancing the broader ecosystem as well, making it more likely that other organisms -- Agile teams -- will be able to survive and thrive.

Highly specialized organisms, however, often do less well when the ecosystem changes around them. More on that in a later post.

All for now.

...-.-

Learning to coach while training

Winter has put in an early appearance on the Front Range of the Rocky Mountains this year. After almost two decades of very late arriving winters, this year is shaping up to be much more like those I remember growing up, with winter firmly ensconced by Halloween. The weather pattern could certainly change, but this has been a nice reminder that Colorado's weather is, if nothing else, highly variable.

The low overcast today seems to have put me in a contemplative mood. A thought that has been rolling around in my head for some time now concerns the nature of communication in the Agile training sessions I conduct. We tend to think of training as a one-way street, with the instructor delivering the curriculum and answering questions along the way and the participants in the class absorbing the information presented. I have noticed, however, that by the end of a two- or three-day training course, I know far more about the working lives of the people taking the course than I would ever have expected. For example, I know if they constitute a working team, regardless of whether they claim to be such. I also know a great deal about their frustrations, impediments, and constraints. I have a solid grasp of the role each participant plays on the team or pseudo-team* and even some sense of how they work together -- if indeed they do.

Given that in any training session, during the presentation portion (as opposed to labs and workshops), I am the one doing the talking at least 80% of the time, I am always surprised to realize just how much I have learned about the participants in the room. I try to answer all questions in-line and make full use of the Parking Lot to capture topics that are either tangential, more advanced than we can discuss as a class at a given moment, or simply beyond the scope of the current course. The Parking Lot then becomes the basis for a moderated discussion at the end of the formal presentation. But even before that point, I have learned much of what I need to know about a particular group of people to begin coaching them in their use of Agile or Scrum.

My employer typically uses various workshops or other discovery sessions to prepare for hands-on team coaching. While I find these types of activities useful for filling in the blanks, I also find, to my great surprise, that most of the information I gather using such tools simply reinforces the picture I was able to construct essentially unconsciously during the initial training. Given the often challenging and difficult nature of coaching agile teams, having learned so much during the initial training is a welcome head start.

All for now.

...-.-


* A pseudo-team is a group of individuals who just happen to be working on the same project at the same time, but without engaging in any actual teamwork.