Scrum: Just follow the solutions provided below!

Doing Scrum is easy! Just follow and implement checklist below and everything will go well, right?

• Deliver in cycles of two to six weeks
• Work in a team sized six plus or minus three
• Every day stand together answering what was done since the last standup and what will be done before the next
• The standup should take no more than 15 minutes
• Every sprint you have to review your process in a retro
• The length of your retro should not exceed the length of the sprint in hours divided by 40
• Stories in sprint should not take more effort than a team can do in two days
• The stories should be broken up in tasks that can be completed in two hours max

In my current project I was asked to be the Scrum Master of a team that had to jump on an already moving train. We took over from a previous supplier that left after a number of sprints in which they delivered a working piece of already shipped software. As part of that they also left part of a Scrum process. Therefore, I found myself with my own mental manual, but being part of a team that is working with slightly different rules already in place. Although the rules were not that different from mine, something felt wrong. The stories were there, they just felt a bit weird. A Definition of Done was hanging on the wall, but it wasn’t doing its job. The next demo was already scheduled, but the goal of the demo did not seem right.

The customer expected me, being the new Scrum Master and all, to hang up my own (above) set of rules over the rules left by the previous Scrum Master. That would make everything better…

So, here I am, sitting at a crossroad on the path of my career. Am I supposed to be the keeper of the rulebook and provided the team with all the solutions I know to optimize their day-to-day work? Am I really the police on how to use the process?

Part of this soul searching was looking back at the Agile manifesto. What was that first line again?

“Individuals and interactions over processes and tools”

This was completely in contrast to what I was doing as part of my professional life. I was providing the processes and tools that dictate how individuals should interact.

I had become my own paradox. I was selling Scrum as a set-in-stone set of rules to make a project a success, instead of a toolbox to help interaction and to work more efficiently.

So now what?

After years of telling Product Owners to stay away from thinking in solutions, but to tell the problem to the team, so they can help in creating a solution, I had provided the team with my own solutions.

Each time a team of motivated people is assembled for a new project, we try to bring out the best in the team. All new technical challenges should be solved using the relevant knowledge picked up while solving previous challenges. And if a problem can’t be solved by anything learned in the past, we expect the team to go out and find the required solution. But no project ever becomes a complete technical copy of the previous project. The same goes for the process. We should not let the process of a new project become the exact copy of the previous project. As Scrum Masters, we should not fall into the trap of thinking OUR process is better than THEIR process. Instead we should take all our knowledge and that of the Scrum Masters around us and drag it around as a toolbox to solve process problems as they arise and not use that knowledge as set-in-stone rules to have teams adhere to.

With this new insight I felt more comfortable in my newfound role of being a coach instead of a rules dictator.

In practice

So how did this insight impact my day-to-day work? I vowed not to set rules and remove all the rules that were already in place. The only rule we had was to deliver a shippable product every two weeks. The team was responsible for finding out how to achieve that.

I have to admit that the first sprint was total anarchy. First of all, the entire sprint consisted of three stories that took way longer than initially estimated. Second, during the demo the team showed the Product Owner the end result, yet it was nothing like he imagined it should have been. Last, the definition of ‘shippable’ might have been more warped than a painting by Dali. The software couldn’t be released, due not being tested on production-like data.

After the demo, everybody got together. During that meeting we defined a set of rules to determine what ‘shippable’ actually meant in the context of this specific project (Definition of Done). One of those rules was that a story was not done until okayed by the product owner. Another was that it had to be tested on production-like data, but obviously there were many more, but all determined and defined by the team.

But we did not stop there, we also defined rules that made sure a story was clear enough for all parties involved before being taken into a sprint (Definition of Ready).

Looking ahead

A few months down the line and I am part of a team that feels more committed to their collective work than ever. Efficiency is higher than ever before. The customer is really satisfied, both with the actual work delivered, but even more with a complete team that takes responsibility by collectively tackling any problem that gets thrown at them, whether technical, process or even a business related problem. Sure, the current rule set looks pretty similar to the one I used in the past. It even looks like the rule set used by a lot of teams working with Scrum. The fact that everybody in the team feels that every rule on this list is needed to work together in the best way possible, is what gives me the best feeling.

Apparently the success of the project is contagious, since almost every week members of other projects come to me, asking for my set of rules and my definition of done. It does feel great to paraphrase wiser men than me, by telling them that the success does not lie in the goal of having rules, but in the journey to get to the rules.