ScrumMasters don't like to talk about their own troubles or failures, even though they say it’s good to fail. They don’t like to admit it happens to them, too. Sometimes it just creeps up. If you've started relaxing your Scrum principles and feel yourself slipping into ScrumBut, take hope: You and your team can recommit.
I have a confession to make. I’m a ScrumMaster, but I’ve let my teams slip into some ScrumBut practices. I’m not sure how it happened, how I let it happen, or how they let it happen. It’s not something ScrumMasters like to talk about—our troubles, our failures—though we say it’s good to fail. We don’t like to admit it happens to us, too. Sometimes it just creeps up. One “I’ll let it slide” turns into multiple and it gets out of hand. Let’s start at the beginning.
When Scrum was implemented at my company, we hired coaches to help with the implementation. There were days of training for all team members that detailed exactly how to “do” Scrum. There were talks of commitments, transparency, estimation (relative, of course), self-organization, and empowerment. We had some resisters, yes, but otherwise everything was great.
Teams started sprinting and establishing their velocities. Sprint goals were well-defined and posted on the wall for all to see. Blockers were brought up regularly, and impediments were discussed and removed with the help of the ScrumMaster. Retrospectives were creative and fun but still yielded plenty of useful inspection and adaption revelations; so many, in fact, it was hard to implement them all. Maybe this is where the problems started.
The first thing I noticed was the daily scrum. The team started out standing, and sometimes it went over fifteen minutes. We were still following the correct format and answering the correct questions, and eventually the scrum tightened up to fifteen minutes or less. Slowly a few people started to lean back on chairs. That was OK; it was early in the morning, after all. Then it evolved to sitting on the edge of the chairs, until finally I was the only one still standing. Then one day, I found myself sitting, too. What had happened? Though the meeting was still running as it should, it had turned into more of a status meeting. Sometimes issues got more detailed and had to be put in the parking lot. Sometimes I had to interrupt, but then again, sometimes other team members did, too. I decided to let this slide; at least we were still doing what needed to be done.
The next thing I noticed was the attitudes. My style is very laissez-faire and hands-off. I want teams to self-organize and make their own decisions without looking to me for approval all the time. How else will the team learn? But what was once lively discussion to estimate stories turned into one person saying a point value and everyone else agreeing without conversation. What happened to our scrutiny of the acceptance criteria? What happened to tasking things out? I let this slide too, though, deciding that the team knows best and maybe they have just become more comfortable in their story sizing and grooming to not need as much discussion.
The last straw was the sprint commitment, though. While I still made sure to coach the team to commit to realistic amounts of work, I was seeing a continuing trend: carryover work. Not just carryover work, but little regard for it. No disappointment for not meeting our commitments. Excuses about things that were added to the sprint as production support at a higher priority and had to be done now. I knew this was something I could not let continue to slide.
I found myself at a crossroads. Either I let the team continue down this path, or I intervene. I chose to intervene. First I did a retrospective on myself to figure out where I had stopped coaching. I realized that the ways different organizations practice Scrum coupled with different team preferences can lead ScrumMasters down the path to forgetting exactly what true Scrum practices are. I reread the Scrum guide as a refresher. Then I needed to get the team back on the right path.
At daily scrums, I once again started standing. I didn’t want to be too confrontational about it, as that’s not my style. Quite honestly, at first the team laughed at me. They didn’t understand why I was standing again, but they certainly didn’t want to. Eventually a couple of people started to feel bad that I was the only one. As a few started to stand up, the others sitting started to feel awkward that part of the team was looking down at them while they sat. Without it meaning to be a motivator based on an inferiority complex, it became one, and the rest of the team finally gave in. This didn’t resolve the status meeting problem, though.
I had to put on my ScrumMaster hat and remind the team that the daily scrum was not a status meeting. It was a daily commitment to themselves and the rest of the team for what they completed yesterday and what they would complete today. I started writing scrum notes on the wall so we could have recorded commitments and hold each other accountable. We also came up with our collective definition of commitment. While this was a practice I hoped would not need to last, it was necessary at the time as a constant reminder.
I also had to remind the teams of the consequences of adding stories to or taking them out of a sprint. It turns out they did feel bad when they did not meet a commitment but were afraid of changing the commitment when new work was added. Though ideally new work should not be added to a sprint, sometimes it is necessary. When it does not completely alter the sprint goal, it is OK to do. The problem was that there were outside influences acting on the team, and anyone and everyone was adding stories. To tackle this, the team decided to take time after the daily scrum and review anything that may affect sprint scope. As a team they would decide what could or should be added and what could or should be removed to still complete the sprint goal and meet their initial commitments. If the sprint goal changed significantly, canceling the sprint would be a last resort.
By taking these steps and really understanding their commitment, I started to see attitudes shift. The team started to care more about the sizes they put on their stories because they wanted to meet their commitments, wanted their velocity to stabilize, and wanted to have less carryover. So the story has a happy ending!
Well, not quite. As ScrumMasters, sometimes we forget the balance between being too involved and too removed. Being a ScrumMaster is hard. It is a constant battle to stay on your game and keep people motivated to perform at a high level, including yourself. We need to walk the talk and hold ourselves as accountable as we hold the team. Sometimes we slip up, sometimes we get lazy, and sometimes we fail, too. It’s not bad to fail as long as you realize it in a timely manner, ask for help, and make a change.
User Comments
Very insightful article. The author did all the right things. To her credit, she was thinking in terms of what would solve problems - not just what would conform to Scrum. Many of the thingis that she did were not really Scrum practices, but were traditional, and the arc that her team went through is what is normal for a team on a new project. Consider:
"Sometimes issues got more detailed and had to be put in the parking lot." - Yes, as a project progresses, things get more complicated, and issue harder to resolve. This is normal.
"what was once lively discussion to estimate stories turned into one person saying a point value and everyone else agreeing without conversation." - That is simply because as a project wears on, people become less interested in other's work, and more focused on their own work, which gets harder and harder. Their attention to the big picture wanes. That is why it is important to have someone who is always looking at the big picture (not a scrum practice) or scheduling a seprate technical issues/design meeting each afternoon to get everybody's attention back on the big picture (not a scrum practice, but more scrum-friendly, although more time consuming for everyone).
"I was seeing a continuing trend: carryover work." - Yes, because more and more dependencies are evolving across features as work progresses, and so the work is getting harder. This is normal. It could also be a symptom of putting work on the backlog that is not well understood - things that should be spikes and not stories. Spikes should not be given points. A story should never be put on a spring backlog unless there are no unknowns about it.
"[starting to stand again] didn’t resolve the status meeting problem, though." - Yes, because standing has nothing to do with anything. People stand in a scrum to keep it short, but it has little to do with any other behavior.
"[We started to] hold each other accountable." - Yes, accountability is important, isn't it? (although it is a bad word in scrum, as vaild pushback against traditional managers who hold people accountable but give them no authority in how they do their work) But what do you do if people don't live up to their commitment? That is often the case, especially in some global cultures that have a tradition of only respecting authority. Team pressure is not always enough. The right answer here depends on the current culture and environment.
"[We started to] take time after the daily scrum and review anything that may affect sprint scope." - And that turned it into a working status meeting by another name. And that's ok, since it had become necessary. Highly effective executives use this meeting format all the time, and it works. Effective meetings are focused, complete each item on the agenda, discussion is issue focused rather than personal, stays on topic, and each issue ends with action items.
This illustrates how important it is to think about effectiveness, rather than "doing agile". Agile is about thinking for yourself - not following a set of rules.
I agree also with much of the article and I find myself typically allowing the team to function (and sometimes stumble) as they find their way.
The one item I think really needs attention whether you are an energetic or a laissez-faire Scrum Master is controlling the scope of the sprint. Agile not only recognizes, but it embraces the reality that software development is a creative and unpredictable process. What helps us is to be able to place structure and expectations around the process so that we build some level of certainty around this.
Allowing the team to consistently not meet their sprint goals is one area that the SM should address with the team, because part of the iteration concept is to understand what can be accomplished by the team in that time period. Allowing them to consistently accept more scope than what they can deliver hurts everyone involved - the team confidence, the ability of management to plan and forecast, realistic team velocity metrics, the list goes on.
The biggest red flag in my mind however is the addition of scope into a sprint after it has started. The Scrum Master must become the voice of reason and strive to prevent any outside interference in the team's execution of the sprint. If BAU issues are popping up that require immediate attention, then there are several ways to mitigate that. Allocate another team or set of individuals to deal solely with production issues, outside of the Scrum team. Do away with Scrum altogether and have teams follow XP or Kanban. But don't subvert the inherent benefits of following Scrum by NOT following Scrum.