Scrum Master Heroics Can Hurt Agile Teams

Scrum teams work on complex problems. Solutions emerge during these type of projects; over time and after many sprints. When a scrum master becomes the “hero” and mandates solutions, he/she can cause lasting damage to the scrum team.

Scrum Master Heroics

Uplifting Hero – JD Hancock – Flickr

All nighters, caffeine fueled coding marathons, and last minute deployment heroics happen regularly on projects death marching to a forced conclusion. That behavior manifests on agile teams as well. But the “hero scrum master” anti-pattern surprised me during a recent exchange on LinkedIn.

A scrum master explained his role as follows:

“I would prefer to be considered as someone who managed to make the team get past the hurdles and obstacles and make it to the “Miller Time” to chuckle and laugh about how silly they behaved in reflection.”

Not exactly the model statement for self-organization and self-management.

My own struggles with dropping the command and control habit are here and here. During those episodes I thought I acted in the best interest of the team and with best intentions. And I believe that this scrum master feels the same about his actions.

With that said, the consequences of directing instead of coaching can be significant and long lasting:

  • No Ability to Experiment: When a scrum master “solves” all of the teams problems, the scrum team will not learn how to experiment. We constantly inspect and adapt our practices. Some changes work; others don’t. Dictating answers robs the team of these possible improvements and lessons.
  • Scrum Team Members Withdraw: Apathy sets in when scrum masters mandate solutions. A disengaged team can lead to silos of knowledge and individual actors as opposed to a gelled and cohesive scrum team.
  • Whole Team Concept Compromised: Every member of the scrum team contributes to and owns the project. If a hero scrum master is solving all of the problems, the scrum team can become dependent on this hero behavior. Coaching others to solve issues and impediments can help make sure that teams grow, mature, and find success together.


As the LinkedIn exchange progressed, it became clear that a bad system/environment drove the scrum master’s behavior:

  • Job Security: When I asked why the heroics were needed, he replied “Either one is a passionately participating and involved scrum master or he is someone that can be replaced tomorrow and no one may notice any difference.” Understandable, but not in the spirit of servant leadership.
  • Carrot and Stick Mentality: He also added, “Sounds to me more like letting people succeed or fail but suffer so they can change out of necessity at the cost of damaging the team’s image/pride and team spirit. This to me is something a villain would resort to.” Experiments do not appear to be valued at his company. Neither does failure.
  • Bad Scrum: The scrum master’s environment “smelled” toxic. The scrum team does not have a Product Owner. The QA team works in India and gets code nightly from U.S. based developers. The list goes on. Perhaps, without the heroics of the scrum master, nothing truly would get done at his company.

The scrum master heroics can appear to help in the short term, but over time the negative impacts – especially the loss of continuous improvement – amplify. The sprint retrospective can help uncover these issues. But once these items make the impediment list, the scrum master still has the difficult task of addressing these system issues up the organizational structure.

Being a servant leader is hard, but as the consequences above indicate, we should coach our teams to be empowered and self-sufficient and remove system impediments…even if it makes us a bit uncomfortable.

[QUESTION] Should Scrum Teams Use Hardening Sprints?

The Scrum Guide says that at the end of each sprint a “potentially shippable” increment of software should be delivered by the scrum team. But what happens when system dependencies and other release constraints make shipping impossible? Enter the “hardening sprint”.

All done |

All done |

A hardening sprint is a specialized sprint where scrum teams work on things such as: integration testing, performance tuning, security reviews, and localization.

It is not a catchall for new features, sloppy code, bug fixes, and other work that signals poor craftsmanship. Be on alert for some of these common misuses:

  • We ran out of time and didn’t full test this feature, we’ll finish testing during the hardening sprint
  • User documentation didn’t quite get done for this feature. I’ll finish that up during the hardening sprint
  • No need to engage support | security | infrastructure now, we’ll bring them up to speed during the hardening sprint

These abuses are why many of the scrum gurus will tell you that hardening sprints are an “anti-pattern” or just flat out bad. A quick google search reveals past flame wars and pointed blog post demeaning the use of hardening sprints. This volatile territory. You’ve been warned.

However, I do not agree that scrum teams who use hardening sprints have lost their way.

It is true that by using a hardening sprint, the scrum team is admitting that they did not deliver “done” software during their preceding sprints. This is an indication that their definition of done is lacking. This could be an impediment to the team’s future success.

But this could also be an intentional decision by the organization. A pristine definition of done is expensive. Continuous integration, high test coverage, and strong devops organizations take time to build and implement. Along with a lot of money. During the early stages of an agile transformation, hardening sprints may be mandatory due to some or all of these practices not being in place. This is ok, but please keep these 3 important ideas in mind when deciding to use a hardening sprint:

  1. Be transparent with the Product Owner about what “done” means:  If “done” isn’t true until after the hardening sprint, the Product Owner has the right to know. Being open about why the hardening sprint is necessary will allow the PO to make better decisions about releases and ensure that their forecasts and product planning are more meaningful.
  2. Don’t abuse the practice:  A hardening sprint isn’t a free pass to be lazy. Keep the work within the hardening sprint to a minimum and continually be on the lookout to reduce the work that is necessary to complete in hardening sprints.
  3. Reduce the reliance on hardening sprints over time:  Your goal should be to eventually eliminate the use of hardening sprints. In some organizations this will not be possible due to various constraints, however, continually inspecting the reason for sprints and looking for ways to reduce their frequency and duration can help the scrum team get value delivered faster to their customers.

The bonus idea to wrap things up is to make sure that your decision to use a hardening sprint is intentional. By that I mean that scrum teams should have a plan for conducting hardening sprints and a long-term goal to eliminate them to the extent possible. If left to chance, many of the bad practice mentioned earlier can and will creep in to your hardening sprints.

Question: I’d love to hear your thoughts and experiences on hardening sprints. Do you use them? If not, why not? If so, how have they helped your team? You can leave a comment by clicking here.


How Do We Get Back to the Values and Principles of Agile?

Unfortunately, I was not able to attend Agile 2014 in Orlando this year. Fortunately, the agile community loves to share. While reading the many blogs and tweets from the conference, I spotted a trend:   Scrum co-creator, Ken Schwaber, wants the word “agile” back.

Ged Carroll | Pow | Flickr

Ged Carroll | Pow | Flickr

 “What is Agile?”

After returning home from Agile 2014, Mr. Schwaber offered an answer on his blog.

Any software activity that conforms or attempts to conform to the values and principles of the Agile Manifesto for Software Development.

For those of you that are new to agile and scrum, The Agile Manifesto for Software Development has 4 value statements that drive the activities and behaviors of agile teams.

  1. Individuals and interactions OVER process and tools.
  2. Working software OVER comprehensive documentation.
  3. Customer collaboration OVER contract negotiation.
  4. Responding to change OVER following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

The second question that Mr. Schwaber addressed in his post is:  “If you could add another value to the Agile Manifesto, could you state it?

His answer is excellent.

We value practices, tools, consulting, coaching, and software organizational work that continuously improve their adherence to the Agile Manifesto OVER Tools, products, methodologies, processes, practices that only use the word Agile to market themselves to make money and whose correlation to the Agile Manifesto is coincidental.

The latest scaling trends in the agile community feel like nothing more than money grabs. In fact, according to posts on Twitter, Mr. Schwaber said just as much during his talk:

So where do we go from here?

There are upcoming events that have embraced the sentiments that Mr. Schwaber shared. These groups are working hard to get agile coaches and agile teams to put the spot light back where it belongs – on the values!

On September 26th – 28th the Agile Coach Camp is taking place in Indianapolis, Indiana. This “un-conference” seeks to push the limits in guiding software development teams, managers, leaders and beyond, while staying true to the values and principles at the core of the Agile movement.

The ideal attendee is a passionate agile practitioner who is active in the field and excited about sharing what they’ve learned.

Agile Coach Camp is a peer to peer learning experience in an OpenSpace setting with Deborah Hartmann-Preuss  facilitating this year.

If you also feel that the agile community has drifted away from the core values, this Agile Coach Camp is an excellent opportunity to connect with agile coaches who share your concerns. The conference tickets start at $89.00 USD.

You can find more information about the conference here:  Agile Coach Camp | Indianapolis, IN | September 26th – 28th