Waterfall On A Wall - It's OK

I've had several conversations recently around 

"Isn't a story wall/Kanban board just a waterfall process presented on a wall?"

For teams new to Agile the answer to this question will typically be yes. And that's ok.

In this post, I share the value that can be gained by visualising your waterfall process on the wall & what advise on what your next steps could be...

Here is an example of typical story walls/Kanban boards I've seen at various organisations (at various stages of Agile maturity):

Testagility-example-story-wall

The columns are the stages the story progresses through, the green cards are new change requests, the red cards are bugs (change requests to fix previously delivered change requests which were incorrect) & blue cards are infrastructure change requests.

On the surface, it quite clearly is a waterfall process. So how do you go beyond cargo culting by throwing cards onto a process mapped on a wall?

The primary value comes from the fact that you have visualised your process! Now everyone can see what each story/change request has to go through before it can start delivering value for your customers.

It is the beginnings of a value stream map & can be used to help improve your process using such metrics as:

  • Time per story in each column
  • Time per story through all the columns (lead columns)
  • Number of stories per column
  • Number of different types of stories

In the contrived example above, you can see 5 cards in "Analysis Done" indicating there are 5 stories that have been picked up, worked on, put down again & are now waiting to be worked on again.

This indicates that there is a bottleneck in the process which is impacting the flow of work through the process (In organisations less mature in Agile practices, you typically see these "queues" of stories in Development Done whilst the team works out how to be more effective at Agile testing...)

If I was to walk into an organisation with this wall, my first task would be to understand what is causing the bottlenecks to see if we can alleviate that congestion.

This is starting to delve into the work of Eli Goldratt & his Theory of Constraints - a subject for a different post.

What this post gives you is an example of how visualising your process can help you on your Agile journey.

As you mature, you'll start improving your process which can be reflected on the wall. For example, you can start to remove handovers between team members as your collaboration gets slicker & pieces of work get smaller. This means you can remove your "Done" columns.

Similarly, with closer collaboration, you can merge the "In Analysis", "In Development" & "In Test" columns to just the 1 "In Development" (as design, build & test are all part of development) 

Some important points to note about your board & process:

  1. Each team member only gets 1 avatar - you can only work on 1 thing at a time
    • If you find yourself moving your avatar back & forth between stories, you probably have too much WIP
  2. Make the board/process policies explicit (game rules) by collaboratively agreeing when stories can be pulled into the next column (not pushed!) & sticking them above the board
  3. Keep the board updated so it reflects the most current project status

Let us know if you've asked yourself the question "Isn't a story wall/Kanban board just a waterfall process presented on a wall?" & whether we can help by having a look at our Services

 

Thanks,

Duncs