Agile workflow

Karl Scotland has proposed an agile workflow to counter some of the waterfall like connotations apparent when we look at a Kanban board.

So for each feature, one by one, we end up with:

Incubate –> Illustrate –> Instantiate –> Demonstrate –> Liquidate

Does that still seem like a waterfall process?

I think that Karl’s reasoning is sound and I have used similar workflows with SCRUM teams to ensure that they keep the entire value stream in view.

However, before I go on to describe the workflow I am currently using I should stress what this workflow is.

A feature workflow is just that. The feature goes through a number of states from the lightbulb moment to deployed, in use and generating value. A workflow in kanban does not mandate hand-offs between individuals. Equally there is no demand that the team do not swarm over the feature ensuring it travels smoothly and quickly between states.

As Karl states, it is common for SCRUM teams to visualise features as being to-do, in progress and done. I tend to add a couple more states in order to visualise the product backlog; it is nice to have items at the top of the product backlog that are ready for development to pull, everything else on the backlog is simply identified.

So, I have: Identified, Ready for dev, To-do, In-progress, Done.

To tidy this up a little more I can say: Identified, Ready for dev, Committed, In progress, Dev Done.

Again Karl identifies the fact that if it’s not deployed then it’s not generating value. I also tend to work in environments where there is more to do between Dev done with it’s automated unit and acceptance tests and go-live. I’m not saying this is ideal of even that it’s an end state but I am currently looking at workflows a little like this:

Identified, Ready for dev, Committed, In progress, Dev Done, Iterative test done, QA accepted

Where iterative test is an ofset risk mitigation exercise including exploritary testing, some performance assurance and anything else that we can’t pull into the iteration but we’d like to get feedback on ASAP. QA is just that, if we’ve done everything right then there will be nothing coming back from QA.

Of course a workflow like this provides me with the opportunity to visualise work in progress using cumulative flow and to identify bottlenecks. Don’t forget, this is a SCRUM team, we batch 2 weeks work into an iteration because right now that is helping us. Maybe one day we’ll decide to go towards single peice flow but not today.