Trifork Blog

Scrum: Just follow the solutions provided below!

May 8th, 2014 by

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.

4 Responses

  1. May 13, 2014 at 16:35 by Scott Duncan

    On the other hand, not telling a team about some generally accepted practices and why people have found them useful (while not mandating them), all in the name of letting the team “self-organize,” may do them a disservice. Struggling with chaos does not necessarily lead to success and positive feelings about working in an Agile manner. I do understand your point, but offering guidance by explaining why certain “rules” have been found useful.

    Some of the “rules” you list are basic Scrum practice which, if you’re going to claim to be a Scrum Master are things you are expected to explain to a team are necessary aspects of the framework. Other rules you mention are more like generally accepted practices which you could mention, but also might want to withhold until some small struggles occur.

    I would not think that allowing “chaos” to rule during a Sprint is advisable for a Scrum Master, but then my use of the word “chaos” might suggest something more extreme than dealing with some impediments.

    I will agree that “chaos” in a Sprint can certainly provide some real focus to a Retrospective and to the support (or lack thereof) from management if the “chaos” has roots external to the team. I’ve had personal experience as a coach for 3 Scrum Masters and their teams with this latter situation when the “chaos” ended up have three whole teams, in a four week Sprint, complete a whopping 5 points between them.

  2. May 14, 2014 at 11:48 by Jurjen de Groot

    Hi Scott, I really appreciate your well thought out response. And I completely agree with the statements that a Scrum Master should know about the practises used in the framework and more importantly why they are part of Scrum.
    I do strongly believe that the basis for the entire framework is found in the Agile manifesto and the pitfall we might face today is pushing all the solutions we found in the past into a uniform way of approaching projects is in a way putting “Processes and tools over individuals and their interactions”
    Believe me when I say that the difference in approach of implementing the framework, lies in nuances. Let me clarify that through two quotes, where the first one is an excerpt from the page regarding the Daily Scrum from Mike Cohn (

    “By focusing on what each person accomplished yesterday and will accomplish today, the team gains an excellent understanding of what work has been done and what work remains. The daily scrum meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other.”

    As a Scrum Master I would introduce the Daily Scrum as part of the framework. I stand by the goal in the former quote that the main part is making commitments to eachother and helping the team gain insight in the progress to getting to the sprint goal. The above quote explain WHY we do a Daily Scrum and still give room to a team HOW to do it.

    The 2nd quote I like to take from wikipedia. This is mainly because the wikipedia definiton usually is the truth as it is today.

    “Each day during the sprint, a project team communication meeting occurs. This is called a Daily Scrum (meeting) and has specific guidelines:

    All members of the development team come prepared with the updates for the meeting.
    The meeting starts precisely on time even if some development team members are missing.
    The meeting should happen at the same location and same time every day.
    The meeting length is set (timeboxed) to 15 minutes.
    All are welcome, but normally only the core roles speak.
    During the meeting, each team member answers three questions:

    What have you done since yesterday?
    What are you planning to do today?
    Any impediments/stumbling blocks? Any impediment/stumbling block identified in this meeting is documented by the Scrum Master and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting.”

    This one focusses on the HOW part. Each line is a solution to a problem we can reverse engineer. For example:
    – The meeting length is set (timeboxed) to 15 minutes.
    I think that before this line was in there, some teams were spending more time a day standing around discussing issues and not feeling the added value of daily communication. A team would only prioritise this rule if the original problem occurs.

    My point was that if you have a team start with the first quote and enough guidance they might end up working like the second quote, but it does ask for a Scrum Master that is working as a coach more than a Scrum Master that knows every solution to every problem in the process

    • May 17, 2014 at 17:18 by Scott Duncan

      So you picked the 15 minute “rule” out of Wikipedia to discuss as an example that concerned you regarding being overly prescriptive. You used Mike’s quote as an example you seemed to like. In the same article you quoted from Mike starts off in the first paragraph with “These scrum meetings are strictly time-boxed to 15 minutes.”

      You say that if the team starts with the quote from Mike you provide, they “might” end up doing what the Wikipedia quote suggests, but then that’s what Mike suggests, too, indeed implies is required. And it is what the definition of Scrum requires which is something a Scrum Master is expected to promote/support/coach.

      Now if you were to discuss starting from a purely Manifesto perspective and seeing where coaching a team might lead, I wouldn’t find that at all objectionable. But if you start with Scrum, then there are specific things the founders of Scrum (and others) expect, otherwise, they would not consider it Scrum. If aspects of what is expected/required in Scrum bother you, by all means, try a different approach. I do agree people should understand WHY, not just HOW, but if you want to change the HOW in Scrum, I think a coach/Scrum Master has to be rather sure everyone (now) understands why to make sure the change in HOW does not lose the WHY.

  3. May 21, 2015 at 14:24 by Ajie

    Hi Jurjen,
    Thanks for this nice article. We figured out that standup meetings are great but needed improvement (they took a lot of time, de-focussed our colleagues and interrupted their workflows). Because of this we developed a SaaS tool to “automate” the daily standup meetings – with just a single email. If you like to take a look: