It might look like rapids, but it’s still a waterfall

This is my second post in my Scrum coaching patterns series.
In my last post I asked for some help with a pattern format that I could follow and at least one person must have read my blog as I now have a shiny new format to follow thanks to Gareth Evans for this.

This is based on Linda Rising and Linda Manns “Fearless change” work, and for anyone not used to this format (like me) I have included the basic format Gareth sent me here. I have modified the purpose of some of the headings, as this a pattern for spotting a pattern as opposed to a solution to a problem outright.

My second pattern comes up all the time, on teams both old and new, I think it causes more sprint failures than anything else. It is my hope that if you can spot this pattern and learn how to avoid it, then you can be even more Scrumtastic.

Name

The Cataract of Stealth

Opening story

Do you often find that your developers are running out of work before the end of a sprint and are trying to bring more work in? Do you often find that you have all the stories in a sprint open and the last few days are are mad dash of tests and bug fixes? Do you look at your burndown chart and all looks well, as you still keep missing your commitments? If you do then you have probably been hit by the cataract of stealth.

Summary

The cataract of stealth is rarely intentional, but it is an effective way to impede your sprints from delivering their true potential. It can be easily spotted when looking at a team’s visible work space, looking at a burndown chart on its own will not give you this information. I believe this pattern is on the rise as more and more teams use electronic workspaces that do not let you view an entire sprint at a glance (scrolling does not count) and the team only make it visible during standups.

When you look at a visualisation of a sprint you should see a sort of tag team effect where 1 or 2 stories are in flight, as they get close to being finished the next stories are kicked off. The process is repeated until all the stories are finished. This method limits the likelihood of failure to the lowest priority stories for that sprint rather than risking the whole.

The picture below illustrates this effect:

Stories flow from one to the next not all crashing into the last days of the sprint

When you are not doing this (or using a similar ethos) you are in effect running a two week waterfall (classic) project with all the inherent risks that that method may have.

The diagram below represents this pattern showing dev / build work happening up front for all stories followed by testing and some sort of acceptance.

So if you always feel the heat at the end of a sprint and your testers craft great plans but get overrun with work in the middle of the sprint then it’s likely that you are suffering from this problem.

All the work looks like it’s getting done but you are piling risk up at the end of the Sprint.

It’s worth noting for both patterns you can get the exact same burndown chart, looking at the chart alone will not help you spot this problem.

Context

This pattern can be found in any team using Scrum, it’s more likely in:

Newly transitioned teams
Teams where there is little trust between roles
Team make-up out of balance
Teams without a visible workspace or without access to an easily accessible electronic one
Little or no test automation.

Problem

This pattern can be triggered in a number of ways and sometimes by more than one trigger at the same time.

Triggers:

Muscle memory
- New teams (new to Scrum) often suffer from trying swap from old patterns of working to new ones (especially if they have worked in a certain way for a long time).
- Each role unconsciously sticks to old patterns that break the overall flow of a sprint for example:
  - Designers not letting anyone see anything until they are 100% satisfied
  - Dev’s not showing their code to peers and team members until they have finished
  - Testers working in isolation and throwing bugs backwards and forwards, rather than working together
  - BA’s so far ahead that this sprint has little meaning any more
- Working how you used to will not work with Scrum and you can go back to a two week waterfall in one sprint without ever even noticing. If anything an external experienced set of eyes is invaluable to help spot and gently guide people out of practised behaviour and in to new modes.
Imbalance in team roles
- To many of one type of role and little movement between roles (I worked with a team of 7 dev’s and 1 tester who was left to do all the testing), this leads to the many waiting for the few.
- The many then Start more work as they need to be “busy” and this further compounds the problem.
- If you test a sprint after you have built something this is a strong smell that you have this issue. (yes i know this should not happen, but i have seen it happen and have seen people ask to do it that way, as it “made sense”)
Poor visualisation
- If you can’t see the state of all your stories in one glance it’s really hard to spot any patterns.
- Whilst I love tools such as Rally for their powerful story management and reporting aspects, I still think a physical board is much easier to work from and maintain.
- If you don’t visualise the work you have to rely on the burndown chart alone to see what is going on, my discussion above shows the flaw in that single view.
Lack of test automation
- Due to the nature of an Iterative and Incremental creation process, and the building on and enhancing of existing features as the product matures means that there is a good chance that some sort of regression will occur
- To combat that you need to perform tests to give you some confidence that’s all is well
- If you or your organisation don’t see the value in test automation then you will soon come unstuck and your build quality will suffer
  - So you test sprint 1 by hand – all good
  - In sprint 2 you have to test all the work done and do your regression testing for sprint one
  - In sprint 3 you have to test all the work done and do your regression testing for sprint one and two
  - You see where I going here, unless you have one developer and fifty testers you will be up a certain creek without a paddle in no time at all

Forces

The cataract of stealth has many allies for example:

Little or no wall space for visualisation
Little or no ability to change team composition
Test automation – pah it’s costly and ineffective
If I wanted to be a “< insert role>” then I would have trained to do that instead attitude
“Scrum is easy” why do I need to see how other people have done it attitudes don’t help either
It’s the <insert last role in chain>’s fault – poor root cause analysis in retrospectives may see you miss this for many sprints
Done?, I’m done, he said he’s done and she’s pretty much done so we are done right? – get a definition of done and use it!

Essence of the solution

Once you see the problem and you have the courage to fix it my advice is to start small and fix one thing at a time.

Start with the premise of “how as a team can we take one story from ready to done” this should bring up a few juicy problems to solve. If you get stuck on where to start then try the Mikado method, it should put you on the right path to success.

One team I visited had a unique (short term) solution to this problem, they agreed that their visual workspace would only show a single story at a time. They repeated this until the pattern of working became the norm for the team and they could go back to having all of the stories on the board.

If you have a long list of things to fix and you don’t know where to start then here are my top 2.

Sort out team balance – either by changing people or getting people to agree to cover more than one base
Automation – you must get this working at all costs

Rationale

So why do I think the cataract of stealth is a real problem and not just some way to get more coaching work!

Well it boils down to one thing, “Working software is the primary measure of progress”. This is one of the principles of the Agile manifesto and is key to why this problem must be solved.

If we have as much time and money as we need to make something then finishing a sprint does not matter, when is this ever the case?
So if we do care about how much we can do and by when, then we need a rough tool to help us do that.
Velocity is the rough tool we use to help us understand how many stories we could complete in the time / money available, but it relies on work being completed within a given time box (sprint)
So if we don’t complete work within the time box how can we calculate our velocity?
If we can’t calculate our velocity then we are working blind and likely to have a very unpleasant surprise!
So in the end we need to finish as much as we can, in a repeatable high quality manner to help us understand what we might finish and by when.

Resulting Context

Avoiding or fixing this problem will: