Impatience is My Biggest Scrum Master Flaw

One of the responsibilities of a Scrum Master is to coach the Development Team in self-organisation. I wholeheartedly agree with this.

That said, I also wish to help my teams advance. There are so many things that I’d like to see them do, like:

  • Improving the Sprint Goal so that it is clear, inspirational and ambitious;
  • Limiting Work in Process (WIP) instead of doing many things at the same time;
  • Making the Sprint Goal the topic of discussion during the Daily Scrum, instead of mainly discussing the progress of individual Product Backlog Items;
  • Having an ambitious Definition of “Done”, instead of being fine with an easily achieved one;
  • Having more spice during the Sprint Retrospective, instead of always wanting to do Mad-Sad-Glad;

And many many more. I see so many things that could be better. But I’m going too fast for my teams. Let’s clarify with a couple of examples.

Example 1 — The stubborn team

My team always had trouble finishing their items in one Sprint. Then, at a retrospective, we had an interesting discussion about swarming (working together finishing an item) and limiting Work in Process. At the end of the discussion the team decided to only select 2 items for the next Sprint. They also decided to work on the items piece by piece, working as a team. I was super happy with the discussion and their decision. And I was even more happy during the Sprint, because:

  • the team experienced the joy of actively working together;
  • the team finished everything that they had planned and were more productive than in previous Sprints;
  • the Product Increment was more to the liking of the Product Owner and the stakeholders.

Having had this obvious success, I expected that the team would decide to continue this way. But they didn’t. They decided that they now had found ways to work together more effectively, so they would go back to working on two items at the same time. I argued that they could expect to return to the situation that they thought they had resolved. But there was no persuading them. Unsurprisingly, they fell into old habits and the Sprint was terrible.

I was sure that they would have learned the lesson by now. But no. The team decided — to my horror — to try out working agreements, sticking to building multiple things at the same time. Only when this Sprint also was a disappointment, they decided to go back to one item at a time and swarming. It took them 3 Sprints to embrace a practice that had proven its worth after 1 Sprint. Being the Scrum Master, it was 4 weeks of agony for me (our Sprints are two weeks long).

Example 2 — Skipping the Sprint Review

My team knows why they have a Sprint Review and are happy with the value that it brings to them. But when the company organised a town hall at the same time as their Sprint Review, they agreed to cancel their event completely. I argued that the Sprint Review has been so important for them and that I’d advise them to find another time-slot for it. They wouldn’t listen. Only to find out a Sprint Review later that they continued working on an item that was seen as not important by the stakeholders, convincing the Product Owner and the Development Team to abandon it altogether.

Where’s the fine line?

I’m often struggling to find the balance between the following two things:

“Coaching the Development Team in self-organization” — Scrum Guide 2017

and:

“Helping the Development Team to create high-value products” — Scrum Guide 2017

I will always help uncover issues to improve, helping them to raise awareness of practices and tools ready to be used and helping them to be open to experiment. But it is up to the team as a whole to decide what to do. I do have a voice in this, but as one of the 7 to 10 (in my case).

I often think that I know best how to deal with a Scrum related issue. But this should not result into me crossing the line of self-organising (Development) Teams. With that I believe that the team improves at a slower pace than they could improve. But when they take an improvement step, it’s with the whole team. And that’s also worth something.

Do you recognize my pain? I’m very interested in how you have been dealing with it.

Do you want to write for Serious Scrum or seriously discuss Scrum?

Writer, editor, founder of Serious Scrum. I love writing about maximizing value. https://www.linkedin.com/in/willemjanageling

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store