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.

CheatSheet

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.

The Rad Retro

On our Agile / Scrum projects, we found we were suffering from the same issues coming out of Sprint retrospectives:

  • We overlooked many of the important events in the sprint
  • Not everyone was engaged
  • They were taking too long

Having carried out a retro on the retro, we now have a new approach with the sprint poker planning cards. We go through the list of questions (see table below) and score on how we feel about each one, using the cards. The scoring is as follows:

  • 1   –  Mad
  • 3   –  Sad
  • 5   –  Ad(equate)
  • 8   –  Glad
  • 13 –  Rad(ical)
  • ?   –  Don’t know or not applicable

The planning cards will remain hidden until all the team are ready to reveal. We then question the outlying scorers and discuss / re-score until we have a consensus value. Scores of 5 are ignored but for the others we agree what went wrong / right, why and the action. The lower the score the longer you should spend on it, to work out what needs adding to the start-doing, stop-doing and keep-doing lists. The high numbers can also be discussed in order to identify potential learnings for future sprints \ projects. The list of questions are:

  • Understanding of what’s going on, planned and blocked (Communication)
  • Operating as a single team; pulling in the same direction (Teamwork)
  • The assumptions the sprint was based on were accurate (Information accuracy)
  • Did we know what the sprint success criteria looked like (Definition of Done)
  • Access to data, environments, accounts and permissions etc. (Technical preparation)
  • Architecture fit for purpose based upon the requirements (Design)
  • Right quantity and quality of meetings to make decisions (Meetings)
  • Are we happy with what was in the sprint and what was delivered (Delivery of sprint)
  • Right amount of quality testing (Testing)
  • How impressive was the demo of the sprint deliverables (Playback)
  • Avoided or mitigated blockers (Blockers)
  • Risks, Issues, Decisions & Change trapped and actioned (RAID maintenance)
  • Is the sponsor providing energy, decisions, direction, clarification and backing (Sponsorship)
  • Considering everything, better or worse than last sprint (Overall project trend)
  • Have we missed anything that needs covering (AOB)

The approach makes everyone think about each of the questions and must come up with a score that they can justify. Doing this engages everyone and targets all aspects of the sprint. We find calling out the outliers is key as it can quickly help identify way of working issues. The retro takes about 30-40 minutes.

I’d recommend adding the actions into your risk log, so that they get followed up in the subsequent sprints.

We have also expanded the questions to cover a project implementation review / retro. Get in touch if you want more details of what they are.