The End of the Scrum Master

Scrum Master is a roll that many have heard of, but few understand. That’s because the role isn’t needed. Well… it isn’t needed in the traditional sense. Let’s explore some background and alternatives.

The Background

Scrum Master as defined in the principles of the stalwart Agile Manifesto: “…” ← It isn’t defined. Scrum Master as defined by the ScrumAlliance.org: “The ScrumMaster helps the Scrum Team perform at their highest level. They also protect the team from both internal and external distractions. ScrumMasters hold the Scrum Team accountable to their working agreements, Scrum values, and to the Scrum framework itself.”

The above descriptions illustrate two things…

1. A Scrum Master is not necessary to adhere, to operate, or deliver in an agile manner.

2. The Scrum Master role is usually defined by groups or organizations promoting a specific agile framework/methodology.

The Issue Today

The issue today is that the world has moved past the need for a one-size-fits-all agile approach. Agile frameworks should no longer be “by the book”, but rather revolve around a canonical set of guiding principles. The “build your own” mentality around agile frameworks & programs is discussed in a different post. That being said, regardless of the framework being employed the title “Scrum Master” and its traditional descriptions create a narrow view of agile delivery.

Ask the following questions — reference the relatively vague descriptions of a traditional Scrum Master role:

• What role does a Scrum Master need to play in team refinement activities? The team should be the owners of refinement activities. A team should feel empowered to determine its destiny. A Scrum Master does not work through a backlog of daily work - nor are they dedicated team “scribes”.

• Is a Scrum Master looking into process bottlenecks? If so, how? Doubt it. Most Scrum Masters are able to observe superficial issues with a team; and can take a routine approach to addressing them. Did someone say longer retrospective discussions? A better approach would be to incorporate deep analytical metrics to help define & address root causes to both team successes and failures.

• Do teams actually need a Scrum Master to facilitate meeting occurrences? Adults need to adult. Teams need to be empowered. And Scrum Masters don’t need to become team secretaries. Set the meetings up, define the meeting purposes, and go to those meetings.

• Why is “Scrum Master” used as a blanket term within the agile community? Does it mean master of all scrum knowledge? Does it mean master of all scrum artifacts? — Has any other title, especially one without much authority, ever used the term “master”? So, does it mean any of those things? Prollllly not. The name “Scrum Master” isn’t great.

The Post-Scrum Master World

The future is rife with opportunity! Instead of the traditional role of “Scrum Master”, the future calls for true team empowerment, analytical analysis, and automation. The future call for an “Agilist”! An Agilist is a role which focuses on an organization, or subset of teams, by defining targeted agile operating guidelines. This allows an orgaization & teams to grow in their own way — while still operating within a structure and in accordance with a set of standards.

An Agilist promotes a culture of self-determination, uses KPIs to review performance/health, and champions the use of “best fit” agile practices.

*For more on agile frameworks & methodologies see: “Finding The Right Agile Framework”

Make Your Jira Workflow… Work.

Workflows are not typically something that people get excited about. Workflows are typically some form of codifying a process from start to finish. Perhaps workflows have specific status gates, quality control measures, or even automated triggers. But, in many cases workflows are static and not regularly “managed”.

Standard Workflows

While the following thoughts around workflows can apply to many areas; consider the world of software development — and specifically consider the use of the ticket/release management tool: Jira. Without getting into complex configuration details, it can be said that workflows are usually manually set for a team or group. Workflows are set similarly to the workflow to the left. The above is a useful standard workflow for agile software development. It tracks everything through various stages of refinement (pre-grooming/grooming), development, review, and acceptance. Additionally, a lot of metrics can be gathered from the movement of tickets/etc. through this workflow. However, this kind of a workflow can be improved to create a dynamic process flow, by incorporating some non-standard ideas. The Avant-garde Workflow Two newer ideas being implemented into Jira workflows are:

1. Statuses should usually not have “gates” post-refinement. tickets/items should be able to move freely up to the point of merging or acceptance. This reduces the chance of a stalled item or extra administrative overhead.

2. Workflows should incorporate statuses which encourage a pull-based flow. Workflows should encourage the movement of work, through explicitly exposing the current status and/or bottleneck. This thought process is taken in-part from the idea behind “Kanban Guide for Scrum Teams” https://www.scrum.org/resources/kanban-guide-scrum-teams

An example of how a pull-based workflow might look is as follows:

Workflow process order: top to bottom and then left to right

The above workflow incorporates the two newer ideas listed, and encourages a “pull” type flow. This allows tickets/items to move into a given status of the workflow on a more granular level. For example: An item will leave the “Dev” stage and move to the “Ready for UI/UX Review” stage (assuming a regular circumstances). Benefits of an Avant-garde/Pull-based Workflow Beyond the obvious granularity and exposure of statues specifics, a pull-based workflow allows for the collection and review more nuanced metrics. The golden nugget of combining granular statuses, along with metrics, is valuable due to two primary things…

• Teams/groups have a better understanding of “where” something is in the workflow, and who is responsible for it given its current status.

• Teams/groups gain better insight into their historical & potential throughput through detailed metrics, including expanded cycle time.

Here is an example of the way cycle time can be observed for a team using a pull-based workflow — displayed using the ActionableAgile plugin for Jira: