Skip to content

Mike Cohn's Blog - Succeeding With Agile™
Syndicate content
Succeeding With Agile
Updated: 4 hours 19 min ago

The Career Path of a Scrum Master

Tue, 05/16/2017 - 18:00

I blogged recently on the question of whether a Scrum team can ever get so good that they no longer need a Scrum Master. In this post, I’ll address a closely related topic: Assuming that the role of Scrum Master does not go away, what is the career path for a Scrum Master?

In my experience, a Scrum Master’s career will usually evolve in one of four directions.

Multiple and More Challenging Teams

A typical career path for a Scrum Master will start with serving one team. After a while that team becomes less time-consuming to work with, as issues are resolved and the team takes on more responsibilities itself.

At that point, a good Scrum Master will seek additional challenges. Often the logical next step is to begin working with multiple teams concurrently or from working with more demanding teams or products.

When developing new Scrum Masters, I prefer to put the person in a position to most likely succeed. That will means working with a team that has neither any difficult personalities nor unrealistic delivery expectations. But, to go from good to great, the Scrum Master will need to learn to work under more complex conditions.

This leads to the philosophy that success is often rewarded with additional challenges.

Mentor

A Scrum Master who has been successful in a variety of different contexts and teams, might choose to move into a role as a mentor to other Scrum Masters. This will especially be true and feasible as the Scrum Master gains skills and experience.

In many organizations, this role would be called an Agile Coach, with the most common job description being that an agile coach coaches Scrum Masters (and their teams).

Personally, I’m partial to such individuals mentoring rather than just coaching. Much of the benefit these experienced individuals provide comes through them offering guidance (“I suggest you do it this way”). Because of this, I think of these individuals as having become agile mentors.

This is an appropriate path for Scrum Masters who have learned that their true passion is the creative act of developing a product--largely independent of whatever the product may be. Some Scrum Masters enjoy the process of enabling creativity among development teams so much that it almost doesn’t matter what the product is.

Think about the radio DJ who just loves being a DJ and doesn’t care if he’s playing classic rock, the current top 40, or classical music.

The Scrum Master who loves the process more than the product is a likely candidate to follow a career path into becoming an agile coach or mentor.

The Scrum Master Becomes a Product Owner

Other Scrum Masters, however, learn that they love what their team is building more than the act of creating it. Those Scrum Masters become good candidates to become product owners.

I don’t want to imply that a product owner role is above the Scrum Master role in an organization. I consider the roles equivalent in a typical organizational hierarchy.

But some Scrum Masters learn that they care deeply about the thing being built rather than the process of building the thing. And from having worked with a team long enough, some of these Scrum Masters learn enough about the product, industry, users and such to become good product owners.

The Scrum Master Becomes a Manager

Scrum Masters are most assuredly not managers themselves. But through their Scrum Masters duties, Scrum Masters often work closely with those who are. And some will find that work intriguing.

Scrum Masters become adept at guiding teams without much authority to say, “Do it because I say so.” Because of this, many can move into management roles where they could demand compliance but because of what they’ve learned from being Scrum Masters, know it usually is best not to.

Especially if a Scrum Master has retained technical proficiency, moving into a role like QA director or development manager can be a fulfilling, logical step.


Scrum Masters often become coaches, mentors, product owners, managers or continue as Scrum Masters in more challenging situations.

A Scrum Master Has Options

There are many paths a Scrum Master may pursue. The skills learned in becoming a great Scrum Master will serve that person well whether they choose to become a mentor, manager, product owner or just work with more challenging teams.

In some ways, asking what is the career path for a Scrum Master is like asking what is the career path of a professional athlete.

Some professional athletes use their former careers as springboards to move into broadcasting. Others use the money they’ve made to start businesses--where I live in Colorado, car dealerships and pizza restaurants seem popular with retired athletes. Some athletes use their fame to enter politics.

Still other professional athletes would find the topic of a career path preposterous. They didn’t become athletes as a path to something else. Becoming a professional athlete was the goal itself.

And so it will be for many Scrum Masters. The role of Scrum Master can be an end itself. Doing it more and better can remain the goal. A professional athlete cannot perfect his or her sport. A Scrum Master cannot perfect that skill either. There is always room to improve. And so, for many Scrum Masters, there may be no career path other than the continuous improvement in themselves that Scrum Masters demand of their teams.

Where Are You Headed?

If you’re currently a Scrum Master, what do you think is next for you? If you were formerly a Scrum Master, what you done since leaving that role? Please share your thoughts in the comments below.

Categories: Blogs

Does the Scrum Master Role Ever Go Away?

Tue, 04/25/2017 - 18:00

Scrum Masters coach, mentor, guide, and enable their teams to develop great products. For a new team in an organization that is also new to Scrum, this can be a challenging and time-consuming job.

At first, a Scrum Master may spend time educating the team about the Scrum framework itself. The Scrum Master may have to convince the team that, yes, something potentially shippable can be developed in less than three months. The Scrum Master may mentor the team on new practices, such as test-driven development or continuous integration. And the Scrum Master of a new team will spend time helping the new product owner learn how to do that job.

It can take a lot of work to do this. But, it does get easier.

The Scrum Master Role Gets Easier Over Time

Over time, the team improves. And the skills team members acquire from their first steps with agile help them learn, evaluate and adopt new practices.

It is perhaps comparable to learning a new language. At first we learn through memorization. Later, when we know enough to begin conversing in the new language, we can also learn through context: One word in a sentence is new to you, but the other words provide enough context that you can discern the meaning of the new word.

After seeing some early benefits of Scrum, teams don’t need as much convincing to try new agile practices. And, over time, the Scrum Master gradually removes organization impediments to agility. Perhaps an early battle was with the facilities group to move people so that the agile team could sit together. But once fought and won, that battle does not need to be fought again.

This argues strongly that the job of the Scrum Master does get easier over time. In general, it will take less time to be a good Scrum Master a year into a team’s agile journey than it did at the start.

Why the Job Gets Easier

The Scrum Master role gets easier in part because team members begin to take on parts of the job.

After a while, team members need less coaching. They learn how to facilitate some of their own meetings. Team members work more closely and directly with the product owner, so the Scrum Master is no longer needed to resolve communication roadblocks and resolve issues. There are fewer organizational impediments to agility. Those that remain can be particularly difficult to resolve, but there are fewer of them.

And so, the Scrum Master job starts to take less time as the team and organization become better at Scrum.

But Does The Role Ever Go Away Entirely?

But does the effort required to be a ScrumMaster ever go all the way to zero?

Not in my experience.

Even the best Scrum team continues to benefit from the coaching, guiding and mentoring provided by a good Scrum Master. With that being said, some high-performing teams might find they do not need a ScrumMaster full time anymore. They might, for example, opt to have a technical team member also function as the Scrum Master.

But my experience is that even the best teams benefit from having a Scrum Master.

What’s Your Experience?

What have you found to be true about the Scrum Master role over time? Do you agree it takes less time as the Scrum Master and team become more experienced? Have you worked on a team that had so fully absorbed the role of Scrum Master themselves that they did not benefit from a designated, even part-time Scrum Master?

Categories: Blogs

Why Getting to Done Is So Important

Tue, 04/11/2017 - 18:00

One of tenets of Scrum is the value of getting work done. At the start of a sprint, the team selects some set of product backlog items and takes on the goal of completing them.

A good Scrum team realizes they are better off finishing 5 product backlog items than being half done with 10.

But why?

Faster Feedback

One reason to emphasize getting work to done is that it shortens feedback cycles. When something is done, users can touch it and see it. And they can provide better feedback.

Teams should still seek feedback as early as possible from users, including while developing the functionality. But feedback is easier to provide, more informed, and more reliable when a bit of functionality is finished rather than half done.

Faster Payback

A second reason to emphasize finishing features is because finished features can be sold; unfinished features cannot.

All projects represent an economic investment--time and money are invested in developing functionality.

An organization cannot begin regaining its investment by delivering partially developed features. A product with 10 half-done features can be thought of as inventory sitting on a warehouse floor. That inventory cannot be sold until each feature is complete.

In contrast, a product with 5 finished features is sellable. It can begin earning money back against the investment.

Progress Is Notoriously Hard to Estimate

A third reason for emphasizing getting features all the way to done is because progress is notoriously hard to estimate.

Suppose you ask a developer how far along he or she is. And the developer says “90% done.”

Great, you think, it’s almost done. A week later you return to speak with the same developer. You are now expecting the feature to be done--100% complete. But the developer again informs you that the feature is 90% done.

How can this be?

It’s because the size of the problem has grown. When you first asked, the developer truly was 90% done with what he or she could see of the problem. A week later the developer could see more of the problem, so the size of the work grew. And the developer is again confident in thinking 90% of the work is done.

This leads to what is known as the 90% syndrome: Software projects are 90% done for 90% of their schedules.

Not Started and Done

In agile, we avoid the 90% syndrome by making sure that at the end of each iteration, all work is either:

  • Not started
  • Done

We’re really good at knowing when we haven’t started something. We’re pretty good at knowing when we’re done with something. We’re horrible anywhere in between.

What’s Your Experience?

Have you experienced problems with teams being 90% done? How have you overcome these problems? Please share your thoughts in the comments below.

Categories: Blogs