Scrum Master Engagement Patterns: The Development Team

TL; DR: Scrum Master Engagement Patterns

Last year, I ran a (non-representative) survey on how Scrum Masters are allocating their time when working with a single Scrum Team. Much to the surprise of many readers, the direct Scrum Master engagement with a single Scrum Team of average size and a typical 2-week Sprint turned out to be about 12 hours per week.

This result immediately prompted two additional questions: What are Scrum Masters doing during the rest of the week, and in what way does a Scrum Master’s work manifest itself over time? While answering the above question requires additional research and data collection, the latter can be answered to a certain grade by focusing on a few common scenarios.

The first article of this series will address the Scrum Master engagement with the Development Team.

The Scrum Master Responsibilities According to the Scrum Guide

Regarding the job description of the Scrum Master, the Scrum Guide is only comprehensive at a meta-level but rather vague at a tactical level, following its “specific tactics for using the Scrum framework vary and are described elsewhere” approach:

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Given that Scrum is a framework — “a system of rules, ideas, or beliefs that is used to plan or decide something” —, and not a methodology — “a system of ways of doing, teaching, or studying something” —, and given the numerous factors that contribute to the varying levels of complexity of any organization, the Scrum Guide’s level of vagueness is both a blessing and a curse. It is a blessing in the sense that Scrum can provide for most organizations a tailored approach to opportunistic, emergent product discovery in complex environments while mitigating the risk that will inevitably manifest itself in strengthened competitiveness by comparison to less agile competitors. It is a curse, as this level of vagueness also opens the floodgates for all sorts of pre-packaged “agile out of the box” solutions by the agile-industrial complex, mudding the water for everyone and giving “agile” a checkered reputation.

It has also led to two particularly artificial constructs in mainly larger organizations over time, confining the roles of the Product Owner as well as the Scrum Master to the tactical team-level. At the organizational level, the Product Owner role is often handled by the product management organization, while the pendant to the Scrum Master role is the newly created agile coach or enterprise coach, both of which I consider unnecessary if Scrum is applied in the right manner and not in some watered-down cargo cult version.

Let us assume for the rest of this article that the organization is applying Scrum as defined in the Scrum Guide, that the organization — particularly the leadership level and the middle management level — is supportive of Scrum, and that the Scrum Teams are comprised of able and willing team members. (So, for example, no engineers are mourning the demise of the hero-developer, who single-handedly saves the organization with beautifully crafted code while burning the midnight oil.)

Scrum Master Engagement with the Development Team

According to the Scrum Guide, the Scrum Master supports the Development Team in the following ways:

The Scrum Master serves the Development Team in several ways, including:

• Coaching the Development Team in self-organization and cross-functionality;
• Helping the Development Team to create high-value products;
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Following this layout, there are three main scenarios for the Scrum Master’s support of the team:

The Co-located, Stable Scrum Team Scenario

In this scenario, everyone is co-located, communication is immediate and direct, and the team’s longevity is granted except for the average fluctuation. In my experience, such a Scrum Team will grasp the basic within two to four Sprints and will be able to deliver a valuable Product Increment regularly within 4 to 6 months, thus building trust among the business folks. Accordingly, the Scrum Master can free up increasingly more time to focus on impediments at an organizational level. (Agreed, this is tautological. However, many people still confuse a problem the Development Team can solve itself with an “impediment.”)

Generally, a Scrum Master‘s pattern of engagement with a maturing Development Team over time may look like something like this:

The end state of this development is the quasi-mythical “invisible presence,” where the Scrum Master is still available for the occasional coaching or mentoring, but otherwise, the Development Team is fully self-organizing.

If we zoom in to the Sprint level, the Scrum Master engagement pattern looks as follows:

While the Sprint start and end are mainly focused on facilitation events, the middle of the Sprint is dedicated to teaching — also stakeholders —, coaching, and mentoring.

The Distributed Scrum Team Scenario

This Scrum Master engagement scenario looks similar by comparison to the first one except that it takes longer for the Development Team to mature due to the reduced level of interaction. Depending on the frequency and regularity with which all team members meet, for example, for Sprint Reviews, Retrospectives, and Sprint Plannings, and whether they all met at least once for a sufficient length of time to go through some of the Tuckman stages, this “stretching factor” can make up anything between 25 to 200 percent.

Let me provide you with an example: Back in 2007/2008, I was a member of a Scrum Team that was split between Berlin and Wroclaw in Poland. We did not only have a day-long kick-off event in Wroclaw, but we also traveled from Berlin to Wrocöaw for every Sprint Review, Retrospective, and Sprint Planning. The Wroclaw team members were also visiting us in Berlin, and we enjoyed Christmas parties together. In short: We were a functional Scrum Team despite the distance. In this case, we probably experienced a delay of perhaps one or two months by comparison to a co-located team.

The Remote, Outsourced Scrum Team Scenario

A remote Scrum Team’s dominating characteristic is the vast distance between the team members, often resulting in a short window of a few hours of communication time over the day. This scenario is typical for outsourced development work, where often the Product Owner and the Scrum Master are not in direct contact with the Development Team. Also, the team members seldom meet in-person to build rapport and go through a proper team-building phase. Additionally, the Development Team is often provided by a service provider and may have a different cultural background as well as management practices. While trying to talk Scrum to the client, the developers often talk waterfall at home, thus practicing known Scrum anti-patterns. More than once, I have rejected reports from agency project managers, pointing at the Sprint Review instead.

In this scenario, Scrum Masters face four main challenges:

1. The inevitable overhead of dealing with project managers less familiar with Scrum.
2. An increased effort to train the members of the Development Team, as the agencies rarely do this.
3. Additionally, dealing with an increased level of fluctuation among Development Team members as loyalty to employers is often lower.
4. Lastly, providing a substantially more considerable effort to facilitate remote Scrum events while dealing with a lesser outcome level at the same time.

All of these aspects feed into a Scrum Master engagement pattern similar to this one:

If you apply a holistic view to agile product creation, the additional effort that is required to make Scrum work, the likely reduced outcome of the Scrum team’s collaboration, and the inevitable delay in product delivery — here: think cost of delay — may very well challenge the original economic rationale that led to outsourcing in the first place. (To simplify the discussion, we assume that the quality level of the code of an outsourced Scrum Team is comparable to that of a co-located Scrum Team.)

Scrum Master Engagement Pattern—Conclusion

As you may immediately notice, numerous factors make these three basic support patterns more complex. For example, there is:

• A high turnover of team members; this might result in a Groundhog-Day-scenario for the Scrum Master, as the team goes through the Tuckman stages of forming, storming, and norming over and over again, before it may reach the performing stage.
• The size and age of an organization as well as its industry. (For example, organizations that strictly adhere to the functional silo and strict budgeting approach of the industrial paradigm.)
• The general technology affinity of the organization. (For example, if “IT” was outsourced during the shareholder value maximization phase, culture clashes between “the business” and the product/engineering teams will be likely.)
• Organizations that operate in highly regulated markets.
• A Six Sigma orientation, resulting in a “failure is not an option” culture within the organization, contradicting the fundamentals of empiricism.

Nevertheless, an understanding of these basic patterns is helpful to support Scrum Masters with their planning and resource allocation.

What kind of Scrum Master engagement patterns have you observed? Please share with us in the comments.

Business & Finance Articles on Business 2 Community

(117)