I Killed The ScrumMaster (And Why He Had It Coming)

Death of ScrumMaster

Them there is fighting words!

Yesterday I was asked by a client about how to optimize a team that was already doing very well.

Without having to think twice, I immediately knew the answer.

“Get rid of the ScrumMaster”

Why? Was the SM doing a bad job? Nope, they had an awesome SM. Was the SM confused with a PM? Maybe a bit, but no more than normal.

Here’s the thing: after watching dozens or hundreds of teams try to be Agile and be all nice and Scrummy, I keep coming back to one thing: having a special person who only does SM duties is like having a person who only does database work, or a person that only works on the UI. It just doesn’t fit into a cross-functional team experience. Worse yet, it starts creating a wall between the developers and the rest of the organization.

It wasn’t meant to do any of that, but it does.

I’ve long thought the SM role should be rotated among the team members, and the more Scrum teams I work with, the stronger that feeling. I see an entire industry sprouting up around “being a leader in your team” and the implication is clear: the SM is a leader, they’re a sheep dog, they’re a facilitator, they’re expected to have special people skills.

In other words, the ScrumMaster is just the 21st century version of the Project Manager.

Only it gets better! Back in the old PM days, if the team didn’t perform, you took the PM out and shot him (figuratively, of course). Maybe then you moved on to decimating the team itself. The PM was always responsible when things went wrong. Nowadays, the modern SM has completely dodged that part of the job. Team not doing well? Hey, we’re Agile! That means the team is in charge. If the team isn’t doing well, dang it, it’s the team’s fault! I’m just this leader facilitator guy. Can’t help it if you give me a bunch of schmucks to work with.

Don’t get me wrong: I firmly believe in team accountability, and the team has to own and deliver in a sprint. It’s just that the ScrumMaster role is also part of the team, yet it occupies some kind of weird place where it’s also supposed to be a champion for the process.


I will now share with you the dirty little secret of technology development that everybody knows but nobody wants to admit: it’s much easier to take a developer and add on some social, management, negoation, or other skills than it is to bring in an expert in those skills and have them amount to anything useful. We’re treating ScrumMasters as if they’re some kind of end to themselves. They are not. They simply have some special things to do on a sprint. Any developer should be able to do these things. After all, your team is working in a co-located manner, right? And you all get along with each other — heck, you sit right beside each other! Developers are pretty good at counting, are they not? And who can’t make a couple of line graphs?

Nope, the ScrumMaster job needs to be rotated among the team. Everybody should have a turn. Kill the idea that there’s some special guy, special skill, and special technique that’s involved. It might help sell a lot of training classes, it might give something to do to all those folks in your organization with those PMP certifications, but it’s not helpful to the team or to the value stream.

And don’t get me started on the problems with the Product Owner role :)

Enjoyed this? Check out the video follow-up done later that day.

October 24, 2013  10 Comments

We need more rubber ducks in Agile

Stand-ups, as we all know, form the backbone of work in Agile. People gather once a day and go over three questions: What did I do yesterday, what am I doing today, and what obstacles do I have?

There’s been a lot of writing about how important stand-ups are. In fact, if I had to pick only one thing from all the Agile practices to implement rigorously, it would be stand-ups. They allow a team to communicate better, organize their work, make commitments to each other, and dynamically plan their day. Done well, they can lead to an almost meeting-free workplace. Done poorly, they become just another question-and-answer status report.

We all know how they work. But why do they work? Traditionally, we’ve talked about how informal conversations work better than written documentation. Get folks in a room and have them tell each other what their situation is. This allows folks to make commitments to the team and share with the team things that need attention. It’s all about communication.

Recently, however, some authors in the business management community have suggested that the key part of the stand-up is the third question: what obstacles do I have? I’ve long thought this was the case. Identify your obstacles and that way the rest of the team can help you with them.

But that’s not what they mean.

Examining great business leaders, such as J.D. Rockefeller or T.Boone Pickens, each of them felt that the key to their success was their daily meetings with their team. But the reason wasn’t peer-to-peer communication. It wasn’t even identifying problems. It was having each person on the team vocalize what their worries and obstacles were.

You see, many of us carry around a list of things we’re worried about and that we need to work on. But the area of the brain that carries these concerns is actually different from the area best suited to work on it. By requiring that we vocalize and explain our worries and obstacles, it engages the parts of our brain better able to solve problems.

Developers see this all of the time. When they run into a particularly nasty bug, many times they’ll start talking aloud to themselves, explaining what they’re trying to do and what they expect the result to be. As they “talk out” the problem, their brain, by hearing the words, begins working on the problem from a different angle. Pretty soon the problem is solved. This method even has a name — “Rubber Duck Debugging”, which means you can put a rubber duck on your monitor. Talk to the duck when you’re having problems, and you’ll better be able to solve them.

The same benefits can be gained by talking about what you’re planning to do. Vocalization dramatically helps execution.


I’m not sure I buy into this as much as others do, but it does bring up some fascinating ideas to increase productivity for our Agile teams. Perhaps we should be concentrating much more on having team members talk honestly about problems instead of focusing so much on commitments. Perhaps teams themselves should have more games where they verbalize, explain in detail, and write down concerns.

Perhaps we need more rubber ducks.

September 16, 2013  Leave a comment

Compensation in Agile: Membership Model

How do you reward Agile teams and people on Agile teams? It’s vexed CEOs and Agile organization ever since we started using the word “Agile”

On one hand, you want to reward people who perform better than others, whatever “perform better” means. On the other hand, Agile is a team sport, so really great players might be the ones helping the rest of the team stand-out, not necessarily those getting all the good press. Agile is about teamwork. People ahead of process.

On one hand, you want to reward some teams more than others. If a team comes up with a way to save the company millions each year, it’s not right not to acknowledge that. On the other hand, in a true Agile program environment, teams always don’t get the types of projects where that kind of savings can happen. You don’t want to preach standing teams and a common backlog and then at the same time start paying off teams that get the choicest work.

You might also want to pay people who have worked longer at the company, because they know the domain better. Or maybe those who have worked longer without moving up are considered something to be shunned. There’s all sorts of business decisions an organization needs to make, based on data, but at the same time once you create a process for evaluating people, you’re obviously placing the process at a higher level importance than the people themselves.

Agile principles and “normal” business principles don’t get along so well.

Enter the membership model of performance compensation.

The membership model says this: There is an “Ultimate Ideal” employee that has properties we value and all agree on. Nobody is that person, but we all strive to have these same characteristics in order to help those around us. We reward people and teams based on how close the rest of us think they get to achieving that ideal. Because we must make decisions on this data, everything is force-ranked, and hiring/promotion decisions are based on multiple rankings by different people over time, i.e., we need to move people around. No one ranking amounts to much, but overall a pattern can be determined that shows how well we live up to the ideals we set for ourselves.

So, for instance, a company might decide that their perfect employee has four characteristics: they make work fun for those around them, they understand the needs of the customers, they creatively come up with simple solutions to hard problems, and you would trust them with the most valuable things you have.

Given that model of perfection, each quarter teams anonymously force-rank each other against that ideal. Who on the team makes work the most fun for those around them? Who would be in second place? Who on the team makes work the least fun for those around them? Then you move to the next ideal. By mathematically combining the results, you can determine overall which person ranks highest in each of the ideals. Over time, as people work in new teams and with new customers, each person’s individual ranking comes closer to what could be considered a group consensus of how well they fit the ideals everybody agrees to.

In this way, you’re not asking how much better one person is compared to another. You’re asking which people we would include in the company if we only had 100 employees. Or ten employees. Or five. You’ve created a system of deciding how likely it is for each person to be a member of the club. Some folks might not be the best choice for membership, but that has nothing to do with their skills or value as an individual. It’s a culture question, plain and simple. This is the culture we value. Here is how people stack up against our ideals, as measured by each of us.

The neat thing is that each organization can create its own set of ideals. There’s no one-size fits all. It’s lightweight yet it scales out and optimizes automatically. It creates a ranking system that works across organizations of any size. The same system can work for both teams and individuals. And it provides for a framework to either reward people or let them go, depending on how well things go at your organization.

The only way to create a process and methodology to evaluate people at an organization is to have a people-centered process, where folks evaluate each other. Otherwise you create the same type of mess Agile was supposed to get us out of.

September 4, 2013  Leave a comment

Principles of Test-Driven System Architecture TDSA


System Architecture is the assembly of system-level components to support the software deployment. This includes servers, database engines, balancing hardware, auto-failover procedures, and so on.

System Architecture, just like software, should conform to pre-established tests as it is being built and used.

The following patterns are the current state of the art in Test-Driven System Architecture (TDSA)

  • SA should be programmatically (dynamically) configurable and not static

  • Initial SA tests and an SA framework should be set up before or concurrnetly with the first release of the product

  • SA tests should run continuously and be as non-deterministic as possible

  • SA tests should grow as new architectural concerns appear during development

  • SA tests should include turning off components, slowing them down, and flooding them with data

  • Continuous testing should provide immediate feedback on the health of the system

  • Feedback data from the test should indicate how the architecture should be reconfigured to optimize throughput

  • One hardware or software component failing should not cause the system to fail

  • One hardware or software component running slowly should not cause the system to run slowly

July 12, 2013  Leave a comment

Mary Poppendieck, Tom Poppendieck On Lean, Agile, and Lean Startups

Meet Tom and Mary Poppendieck, the folks that introduced Lean to the world of technology development. In this chat, we go over how both of them ended up writing Lean Software Development. What’s the benefit of applying Lean principles to the startup community? How important is a Product Owner in a technology team? How can organizations get past the barriers that prevent them from effective Agile adoption?

It’s a wide-ranging and fun conversation, and they have a new book coming out too! Here’s hoping we can chat again sometime.


Click to download mp3

April 26, 2013  Leave a comment

15 Minutes To Scale Out Agile (2013 Video)

Have more than one Agile team? You’re probably interested in some pattern to “scale out” your organization; help multiple teams work together as efficiently as possible.

So what are the various options out there? What’s been tested, what has the most traction, and what is going to help us the most? What do we have to be concerned about?

This is a quick 15-minute discussion of teams-of-teams in Agile.

If you’d like some more information about Metrics in an Agile program, check out this 15-minute video on Agile Program Management:

April 20, 2013  Leave a comment

Startups, FGPAs, Certifications, and Making Agile Work. Video Interview With Big Visible’s Agile Coach Alan Dayley

Can you effectively use Agile and Scrum when you’re creating your own circuit boards as well as programming them? Does it make sense to pick up a lot of certifications as a coach? What role does lean startup play in BigCorp and agile transition? Has the name “Agile Coach” become more of a burden than a benefit to people trying to help people transition? Is the word “Agile” perceived by many to be just another in a long line of management fads? When you’re helping a team become more Agile, should you be very directive or Socratic? What happens when the team decides to do something that you as a change agent think is a bad idea?

I tried to hit Alan with all the usual tough coaching questions. You’ll have to watch the video to see how he did.

Alan Dayley is a lead coach at Big Visible Solutions. He has a technical background and is working in one of the support roles for Agile 2013.

April 3, 2013  1 Comment

Jonathan Kern Interview (Agile Manifesto)

How do you start out working in testing in the military aerospace industry, then end up being one of the authors of the Agile Manifesto?

In this interview, Jon Kern tells us about his journey. How testing led to coding, which led to architecture, which led to becoming an Agile thought leader.

Jonathan was on-hand to see the rise (and subsequent fall) of Model-Driven Development and Model-Driven Architecture. In fact, he helped write some famous apps, consulted for others, and had a ringside seat as it all played out.

Now a Ruby on Rails programmer and team lead, he sees Agile Implementation from both a methodology and a practitioner’s standpoint. This interview was good enough that I need to come back for part 2!

April 2, 2013  Leave a comment

Better Stand-ups in 12 Minutes

The standup is one of the easiest things to do in a team, the one that’s done most often, and the thing that can have the most positive immediate impact.

So why is it that it seems such a waste of time?

There are lots of reasons, one of which is that communication is so natural to people that they don’t notice critical communication even when it’s happening.

Here we go over how to have a high-energy, effective stand-up, starting right now. Buckle up! It’ll be fun.

March 14, 2013  Leave a comment

Robert “Uncle Bob” Martin Interview (Audio)

Tiny Giant Books presents an interview with Uncle Bob Martin
MP3 File – 54 Minutes (25MB)

Robert Cecil “Uncle Bob” Martin has had a long and distinguished career in IT, beginning with industrial computing and continuing through being an author, speaker, and thought leader in the Agile community.

In this audio interview, Bob talks about his early life, his first computer, his first programming job, how he got fired, and how he decided that he needed to take programming a lot more seriously. He also talks about how he got into writing and publishing, his views on how TDD and functional programming work, and what his plans are for the future.

(Tech note: This was created as a video interview using Skype, but the video recording app did not function correctly.)

Uncle Bob Stats

  • Birth Year: 1953?
  • Home State: Illinois
  • Best Known For: Agile Manifesto, Clean Code, Founding Object Mentor

Books by Uncle Bob

March 4, 2013  Leave a comment

« older posts newer posts »