Scrum “Master” Has to Go

Scrum Master has to be the most un-Agile term.

I mean really what do scrum masters do?


  • Facilitate dialogue, brainstorming, interactionfacilitator
  • Demonstrate good positive people behaviors like cooperation, lack of blame, fact based conversations and encourage the team to do the same
  • Manage team adminstrivia like updating systems (or bugging/reminding their teams to do so) or handling reporting up the SAFE chain
  • Provide top cover aka removing impediments and preventing distractions

Mountain Goat software describes the role like this:

The ScrumMaster is there to help the team in its use of Scrum. Think of the help from a ScrumMaster as similar to a personal trainer who helps you stick with an exercise regimen and perform all exercises with the correct form. A good trainer will provide motivation while at the same time making sure you don’t cheat by skipping a hard exercise. The trainer’s authority, however, is limited. The trainer cannot make you do an exercise you don’t want to do. Instead, the trainer reminds you of your goals and how you’ve chosen to meet them. To the extent that the trainer does have authority, it has been granted by the client. ScrumMasters are much the same: They have authority, but that authority is granted to them by the team.


He’s a master: “These are not the developers you’re looking for”

The pervading wisdom, common knowledge says that Scrum Masters are ‘Servant-Leaders’ who ‘Carry Water’ for their teams.

Further, Agile is all about Self-Organizing teams with flat hierarchies, where team members are encouraged to be accountable, to work together to determine the path forward, to take work without being told to. They are groups of self-directed people, not without leadership but not with total command and control.

So why, why, in this world of Servant-Leaders who Facilitate and Bring Water to Self-Directed teams do we still use the word scrum MASTER?

Master has all kinds of connotations and I can only think of one that’s positive. Here’s my list:

Master Negative Connotations

He's a master: Totally not trying to be on his team. "And WILLLLL update jira!!!!"

He’s a master: Totally not trying to be on his team. “And now….you WILLLLL update jira!!!!”

  • Master and Slave as in the American Slavery Experience
  • Master and Servant as in the English Aristocracy Experience
  • There’s another one bought on by the acronym SM but this is a G rated site and I’m not going there

Master Positive Connotations

  • Someone whose skill is at a superior level

The positive connotation doesn’t really fit in our definition of scrum master. If it did, then we’d be saying in effect that scrum masters were people who are incredibly skilled at scrum. Yet scrum is agile and should be open to the input of a self-directing team. So even if I master our scrum process today, that doesn’t mean that after the next retro I’ll still be the master of that process.

But I don’t think that’s what was intended with the word scrum master anyway.


He’s a master: “Have those unit tests complete when I return from the hunt.”

I think what was intended was probably to step away from the term Project Manager and invite the idea of something of a call player from Rugby, which is where the ‘scrum’ term originated. But I can’t find a ‘scrum master’ role in Rugby, so I’m really not sure here. I’m guessing. Maybe someone can inform us in the scrum lore as to why we all call the scrum master the master.

Anyway – The negative connotations of master are enough to throw the term out the window. A slave master?  Sorry – I’m not gonna be part of that process. An English Lord, well maybe, if I could live in Downton Abbey.

Master is not the energy we are reaching for in scrum or agile.

People, can we get a new term here?

Here are a few suggestions:

  • Team Facilitator
  • Team Mediator
  • Scrum Coach

I’m sure there are many more. Feel free to post them here or on twitter.

But seriously, scrum master – that’s gotta go folks.


One way to bridge the gap from raw requirements to user stories

I’ve been on two Agile projects now where the following has worked.  Not perfect but it helps to solve a problem that I’m seeing a lot at the beginning of projects. That is, how do you get from raw requirements and use cases into INVESTic user stories and epics?


Think – you’ve got a new product, you’ve got stakeholders in the room; they are brainstorming.  They come out with a bunch of requirements.  They leave.  The dev team now has to figure out how to take this long list and turn it into develop-able requirements.  We’ve got a lot of tools for dealing with stories once they are baked; estimation sessions, planning pokers etc.   But the tools don’t seem so clear when you are trying to make sense of requirements at the inception of a project.  So here’s one way I’ve seen that works:

Assuming you’ve got that list of requirements I mentioned earlier:

Move requirements into Features


Analyze the requirements as follows:

  1. True Need Analysis – Figure out what the real requirement is behind the ask.  This is usually the domain of the BA. What is the user really asking for?  For example, they may say they want a button that says ‘eject’ but what they really want is a workflow where they can stop the process at any point.
  2. De-Duping and Current State-ing – Figure out what requirements are really mimics of each other.  For example, one user asks for an ‘eject’ button while another asks for a ‘Stop Process’ button. Merge when possible.   Also – it could be that you’ve already built what the requirements are asking for – your current state meets the need.  So give the requirements a current state pass as well.
  3. Grouping and Aggregating – How do requirements  logically fit in with other requirements? What requirements are similar enough that they could be parts of the same feature in a product?  Spend some time grouping those requirements together and give that feature a name.
  4. Acceptance – Determine how you’ll know that you’ve accurately completed this requirement. Check the language of the requirement because sometimes the requirements themselves can become acceptance criteria.
You’ll come out with a not fully baked list of features which you can go take back to the stakeholders for verification.

Prep the Features in a Spike


To fully Prep requirements, create a spike.

What is fully Prepped?  It means that the feature has documented and clarified use cases, user personas who will verify that the feature meets their needs, high level technical specifications if needed, definition of done (preferable with acceptance criteria), and a priority as provided by the Product Owner. Basically it answers what we’re building, who we are building for, how they will use it.

Handover the feature to the development team 

Usually this is accomplished through a separate spike meeting, with a presentation of the findings. Following the handover, the dev team should be able to breakdown the feature into epics and stories and the (currently well documented and doesn’t need to be rehashed here) Agile process takes place.
How are you handling this move from raw requirements into epics and stories? 

It’s a state of mind: Some practical indicators on doing agile vs. being agile

Over the past few years I’ve had the opportunity to work on many teams that call themselves agile. While teams can do the agile process, they may not have an agile mindset. 

An Agile state of mind

I’ve always held out that agile was a state of mind moreso than a process.  More allowing porous flexibility, than stories and iteration planning.  As  PM transitioning from iterative to agile, it’s been a bit bumpy for me.  I’ve wanted too much process, or perfection in documentation – or even too much standardization.  Allowing for being agile can feel chaotic (though as an aside, allowing for a bit of chaos is probably  where Project Management should be heading ).

I think it helps to re-read the original agile manifesto. It doesn’t talk about user stories, or iterations or task estimation. It talks about a mind set – a mental approach, and a set of values.

I thought I’d share my learning with you.  So as a PM, you can have some practical indicators of where your team is with this whole agile mindset thing.

Here are some things a good agile team does:

1. Finds the root cause

AGILE:  When a problem presents itself, a truly agile team swarms around the solution. They figure out the problem and then prioritize it. Because they believe that software should be consistently workable, they almost take it personally when it’s not. So they really want to know why something is not working and they spend time to figure it out.

NON AGILE: Non agile teams tend to initiate surface fixes and then save the root cause analysis for a later time. They are not as passionate about finding the root cause.

2. Questions process and documentation

AGILE: Transition to true agile from iterative was a bit of a challenge for me as a PM. I had to get used to people making me justify why something should be documented. Truly agile teams know the difference between documentation that will sit on a shelf and documentation that will help build great software. And they police themselves, and their leadership, to make sure they don’t waste time.

NON AGILE: Builds in on the shelf documentation into the process because they believe they have to do the work. In other words, they don’t really question authority in this regard.

3. Doesn’t update jira/rally/asssembla that well

AGILE: Another pain point for me, which I have accepted will always be a pain point as a scrum master, is that status updates to story tracking systems is going to be light. I cannot tell you how many times I’ve commiserated with other scrum masters on this point. Better to just accept it and send out the weekly/status – please update your stories/points email.

NON AGILE: Focuses a lot of time on status reporting. Tends to fill out all the fields in the story tracking system. Tends to also then assume that an status email/report must also be filled out.

4. Wants product owner approval

AGILE: Agile teams hesitate if you suggest that you just push code without PO approval. A good agile team trusts, respects and wants the approval of the PO – because that enables them to produce a good product. This is part of the process they actually want to stick to. Even if a release is held up, the agile team will wait for PO approval; schedule be damned.

NON AGILE: Non agile teams tend to push code according to a schedule. The PO had better get on that schedule or they will miss the demo opportunity. In other words, schedule trumps PO approval.


As Thoughtworks empahsizes so well, it’s the difference between Doing Agile and Being Agile

As thoughtworks empahsizes so well, its the differnce between Doing Agile and Being Agile

5. Handles changes without a lot of theatrics

AGILE: Change is welcome. There’s a positive inclination to take a minute and be open, respecting the change as legitimate. This team believes that change is ok – so they have a process built already for efficient processing of changes, and they throw the change into that process.

NON AGILE: Non Agile teams have a process that slows the review of the changes. It’s not an immediate understanding, review and prioritization. Instead you’ll see a change go immediately to backlog. The backlog then grows and grows until no one understands or remembers why something was put there. Then the theatrics begin with the client, who is wondering -> what happened to that thing I asked for – I’m still seeing this bug?

6. Gravitates towards bite sized chunks

AGILE: Agile teams don’t accept large chunks of work. They will scrum around something big and break it down into small chunks.

NON AGILE: Breaking down a task means a) that you can hide within it and b) other people can’t pick it up. So non agile teams accepts a large chunk of work and won’t try to break it down.

7. Consistently tries to figure out how to make things more efficient

AGILE: Agile teams ask the question; how can we be more efficient, faster, more productive. They tend to revisit infrastructure, metrics on systems and incorporate automation into the process (like build servers and CI).

NON AGILE: Tends to revisit infrastructure, efficiency, metrics questions when things stop working or slow down to a crawl.

An Agile mindset is just that – a state of mind, a set of values. Its a constant questioning, and an opening up to possibilities. Its a predisposition to produce great things.

Take some more time with this presentation from Thoughtworks.


Shorten your Standup

Standup used to feel like this

Standup used to feel like this

Our team recently made a change that reduced our standups from 30-45 minutes to 10-20 minutes.

I repeat: 30-45 minutes to 10-20 minutes.

I guess the key question is – how did we get up to 30-45 minutes for a standup? That’s kind of a long time to stand around!

Well, we started using standup to communicate status. This is even though we have an automated agile board – upon which status should be communicated.

And when 12 people communicate status, ie what I did yesterday, what I’m going to do today – we lose the ability to really communicate about things that need talking about.

The sad thing was that after we spent 20 minutes on status THEN we would start talking about defects, problems, and blockers and pretty much people would be ancy and not really interested in talking and solving problems.

So we decided to pull it in and nail it down to what really needed to be discussed. This was deemed to be:

Priority Defects – answering: what problems are we facing in our production process/build?

Any problems with functional test/continuous integration – answering: what problems are we facing in the upcoming process/build?

Blockers – answering: what’s stopping me from moving forward?

This approach got us talking about things that matter.

We are now communicating what we need to do, and who is going to do it; quickly. The result of our actions (read: status) is reported in the automated agile technology tool (which is what it’s for).

The key is really to move from reporting (which is past focused) to assigning (which is future focused).

Feels a bit more like this now

Feels a bit more like this now


I cannot tell you how liberating this is.

Speed it Up: Release the Ownership of Making Changes

Looking for ways to speed up operations on your project?

Think about Releasing the Ownership of Making Changes.

On many processes, there is a Process Owner and the definition of ownership for that process owner includes:

  • Ownership of Making Changes
  • Ownership of Implementing Changes

Ownership of Making Changes is when the process owner must approve a change before its made.

Ownership of Implementing Changes is when the process owner must approve the change before it’s implemented.

The problem with the Ownership of Making Changes is that it takes longer for changes to happen.

Longest Process

The usual flow is:

Someone (let’s call her the Change Agent) recognizes a need for change

  • The Change Agent preps a request to Make the Change to the Process Owner
  • The Process Owner gives approval to Make the Change
  • The Change Agent Makes the Change, along with all the other stuff she’s got to do
  • The Change Agent preps the final change for approval
  • The Process Owner gives final approval for the Change Implementation

Ok so, what if we pulled out the need for approval to Make the Change? We’d lose a bunch of steps and gain more time.

Shorter Process - Ownership for Making Changes has been released

That flow would look like:

  • The Change Agent recognizes a need for change
  • The Change Agent Makes the Change, along with all the other stuff she’s got to do
  • The Change Agent preps the final change for approval
  • The Process Owner gives final approval for Change Implementation

Now…you can really speed things up by training a group of people to do the work, so that anyone can make the change. If you encourage Change Agents to communicate the recognized need for change transparently, maybe through a collaborative system, then any one of the group can pick up the change and make the change. Assuming that the person who picks up the change did so because they don’t have any other work, they don’t have to shuffle it in priority with other things on their plate. So the work gets done faster.

That flow looks like this:

Shortest Process - Many Trained People Can Do the Work

This idea is why Kanban and Agile teams get things done faster.

The Big Picture of Time Savings by Removing the Ownership of Making Changes

Implementation Guidelines

To really make this work, the Change Agents must be people with the skills and training to make the changes. Ensuring that you have a key skilled group of people provides a measure of confidence to Process Owners and prevents chaos when making change.

The Process Owner must still approve the change, which also prevents chaos. You should also create some type of way to rollback if the change is not approved or a place to make visible and shareable drafts.

Try this on a small process and feel it out. You may find that Removing the Ownership of Making Changes results in large, beneficial gains in productivity.

Certified Agile-An Oxymoron

I am inspired by James Turner’s post on O’Reilly Process Kills Developer Passion.

Do we get past this through Agile methods or by being Agile?

James Turner wrote:

“A project where you decide before you start a product cycle the features that must be in the product, the ship date, and the assigned resources is a waterfall project.”

And I thought ‘Yeah’.

Of course, his point was more that too much metric-cized process kills developer innovation, but he’s hit on something that I’ve been feeling for while.

Practicing defined Agile methods is no longer really Agile, as it was meant to be.

If I was to write up an Agile User Story, it would be about changing software development paradigms. It would go:

As a development community, we need a process that incorporates the idea that everything changes, including deadlines, methods and requirements, so that the process itself gets out of the way of good software development.

This is what I call the Spirit of Agile, and frankly, it’s an idea that gets lost in the shuffle. It’s really about removing control, and allowing maximum flexibility so that software developers can create awesome stuff.

I would argue that a lot of people are using Agile methods but not aligning with this Spirit of Agile. So they are using daily scrums, sprint planning and sprint retrospectives as an effective means of communicating about work, but not as a means to provide any flexibility to developers.

So my concern with PMI taking on Agile, or any Agile certification really, is that Agile then becomes a body of knowledge, for which people take a test to become certified. This is about controlled information at defined moments in time. And that is decidedly not the Spirit of Agile.

There’s nothing wrong with that. Agile methods do improve communication. Daily meets, daily reporting, task clarification, are extremely good at organizing people to get work done, and getting people to communicate better.

But the point I’m making, and what I believe James Turner is going, is that true agility would mean the constant adjustment of those methods, and that’s not what a certification is about. A certification is about learning something and practicing it according to a defined method. Well, if Agile was really Spirit of Agile, then that method could and should change, all the time. At a pace too quick for a certification to be built.

And the irony is that there are going to be places who are very locked into software paradigms about scope definition and timeboxing, that will want PMI certified Agile Practitioners to practice Agile without making any changes to process.

They’ll say something like:
“Here new certified Agile Scrum Master- complete this burndown Template, and continue to hold These scrums at These pre-defined times, with These pre-defined people.” That’s not Spirit of Agile.

In a truly Agile world, we would say ‘Here new Agile certified Scrum Master – figure out how to make the team produce great software. Bye. I’ll see you at the retrospective.”

I think it would be good for PMI, instead, to focus on building out a soft skills certification. They still have no equivalent answer to APM’s Behavioral Competence domain, a great program that measures Communication, Teamwork, Conflict Management, Negotiation and Behavioral Characteristics.

The Uncertainty Principle OR How to Choose the Right Methodology

I ran into a old PM buddy in the frozen aisle of Trader Joe’s the other day. “Are you Still doing Agile?” slipped from lips before I could stop myself (it’s sort of ‘Gosh Michiko – can’t you turn it off at Trader Joe’s on Saturday?’ Sigh).

Which One Do I Choose???

Anyway, my friend was gracious,and it turned into a why-we-have-abandoned-Agile discussion. His company, mind you, was one of the very early Agile adopters and is the place I learned and came to love Scrum. A huge, established, reputable and very solid financial institution, it was perhaps a little bold of them to try.

Nonetheless, he explained, Agile just didn’t fit. And they gave it a good go too – with dedicated Scrum rooms, co-located developers, lots of whiteboard space..the works.

I’m still scratching my head, and the blogsphere is hot with choosing-the-right-software-development issue posts. Sometimes its friendly how-to articles, like Project Smart’s recent post on Waterfall vs. Agile and sometimes it’s out and out Waterfall vs. Agile wars; like the Integrated Master Schedule showdowns between Herding Cats and Critical Path. May the best blogger win.

But I like what the newest methodology contender has figured out. Lean Startup is way out there – they think Agile is slow. But Lean Startup leader Eric Ries based his method on the degree to which a problem and solution is known or unknown. He asks to what degree the solution is known and to what degree the problem is known. The problem question is: ‘what is the problem we’re trying to solve?’ The solution question is: ‘do we know what we need to do to solve the problem?’ I think he’s on to something, because the question about degree of uncertainty is reflected in the organizational culture of a company.

So I started mentally evaluating companies I’d worked for in light of these two questions. And I found that where the problem is known and the solution is known, the company is less likely to take on rapid development software methods. Whereas, where the problem is unknown and the solution is unknown, the company culture tends to welcome and keep using rapid software development methods.

For example, the large financial institution. The problem is ‘how can we grow money for our clients?’. That’s a pretty stable problem and is well known and built into the company’s value statements. In other words, if you’re at that company, you know the problem, there’s no way you don’t. And the solution is well formed; ‘work the market’. So all software projects at the company are approached from this angle. Agile didn’t take off there, but incremental waterfall works well.

A smaller software company I worked for; the problem was ‘how can we build our expertise into a software product to satisfy the needs of unique niche?’. The solution was well defined; ‘customize a COTS solution’. That company also uses an elaborated incremental waterfall approach. Surprisingly, given their small size, I thought Agile would take off there too, but it didn’t.

Another large financial institution; the problem was ‘how can we reduce our financial risk in a shaky mortgage market?’. The solution was unknown. And in this very large, well established institution, Agile projects do quite well.

I used to think it was the size of the organization and or the organizational aversion to change that determined the software method. But now I think it’s the extent to which the problem and the solution are either known or unknown; ie the degree of uncertainty.

The Lean Startup idea is that both the problem and the solution are unknown. So the point is ‘continuous development’ with a ‘minimally viable product’ so that the team can ‘fail fast’ and and move both the problem and the solution from the realm of the unknown to the realm of the known. I wonder if and when this happens, Lean Startup will have to go more Agile. That’s another discussion.

Kanban developed to maximize the production of a known solution. Developed from the automobile factory floor, the solution was well known; ‘we are building cars’. But the problem was unknown from year to year; ‘what kind of car is the best this year?’. In this situation, where the solution was well defined and stable, but the problem could change, Kanban developed; which controls the build speed of solutions, regardless of how that build changes over time.

It’s starting to feel a little like this:

Known Problem/ Known Solution – Use Iterative/Waterfall
Known Problem/ Unknown Solution – Use Agile
Unknown Problem/ Known Solution – Use Kanban
Unknown Problem/Unknown Solution –  Use Lean Startup

I’ll keep using these two questions as I try to figure out what works best where. But I think what’s really becoming quite clear is that there is no one way, anymore. And it’s not just an Agile vs. Waterfall world either. We’ve got to start developing new tools to help PMs make quick assessments and get on track to successful implementations.