Dave Stokes

Dave Stokes' Blog

Scrum Insanity

When agile projects go wrong it’s often not a single massive mistake, but a series of small ones that get compounded into something much bigger. Common reasons include:

  • Forgetting to follow the basics
  • Lack of communication
  • The Way of Working isn’t working

No surprises there, but why do we see it happen again and again? I’ve often been told that the definition of insanity is doing the same thing and expecting different results. In fact, the legal definition is the ability to determine right from wrong when a crime is committed. This means if you are not learning and making changes, you are either insane, making original mistakes or you’re doing something criminal.

By running sprint and project retros we can establish what we should and shouldn’t be doing on projects. It is often very simple to follow but it’s hard to remember it all. But this isn’t exam conditions, so we can build a sprint cheat sheet to help. Building one is simply an iterative process of grouping the output actions of retros for each of the sprint activities. I’ve included my own one, that’s evolved over time.


For each activity, we go through all the bullet points to check that we’re not falling into any obvious bear traps. If we are, we then agree as a team whether to mitigate or accept the risk. The risk points are totalled up for the sprint (one for green, two for amber and three for red), so that we know how risky the sprint is. I think of total risk points, as the height of a swimming pool diving board. It’s OK to jump from 10ft or below, but it starts getting scary above 20ft.

If you are exposing a sprint to lots of risks, make sure the client signs up to that. Retros are a good time to reflect by consulting the check list and see how many of the risks hurt the sprint. One area I’ve excluded from this blog is the wider project, particularly around project kick-off and sprint 0. Both are critical to agreeing an initial Way of Working, but I’ll cover that in a separate blog.

Another top tip is to print your cheat sheet on A5, laminate it and make sure the whole project team have a copy. You can even run all the sessions using the cheat sheet as a checklist. As a minimum capture and communicate the total risks points for the sprint. It takes 5 minutes a sprint; chances are it’s less than an hour for the whole project. To have a simple way to mitigate so many possible project problems, surely, you’d have to be insane not to use the cheat sheet.

Comments (3) -

  • Callum Green

    9/12/2017 9:02:50 AM | Reply

    Great blog post and really useful guide for any technical project.  This will certainly help my team identify when projects are going south or ideally, when they are going well!  Looking forward to the next blog discussing ways of working.

  • essay writing

    5/28/2018 11:42:20 AM | Reply

    thru jogging dash and mission retros we are able to set up what we want to and shouldn't be doing on projects. it's miles often quite simple to comply with but it’s difficult to bear in mind it all. but this isn’t examination situations, so we will build a sprint cheat sheet to assist. building one is certainly an iterative machine of grouping the output moves of retros for each of the sprint sports activities. I’ve covered my private one, that’s evolved over the years.The hazard factors are totalled up for the sprint (one for inexperienced,  for amber and 3 for pink), simply so we realise how unstable the sprint is.

  • MaryKittel

    9/13/2018 7:00:24 AM | Reply

    Admire this article for the well-researched content and excellent wording. I got so involved in this material that I couldn’t stop reading. I am impressed with your work and skill. Thank you so much. And again I really thankful for sharing this one. Since I am a writer I really impressed with write up. If you want writing service, one of the best writing service available. Nothing anyway everything is extraordinarily open and greatly clear defense of theme . my site is:  http://cheapessaywritingservice.us/