An Agile Workflow

A common topic of discussion around kanban is whether the workflows or stages in a kanban system are counter to the Agile principles of cross functional and collaborative teams.   Its easy to talk about a feature going through the following flow in a kanban system:

Analysis –> Build –> Test –> Release

which I confess looks very waterfall-ish and I can understand why this can raise warning flags about the suitability of the kanban approach.  This got me thinking about how best to express a typical agile-friendly workflow.

Lets begin with the common basic stages on an agile team’s ‘story-board’.

To Do –> In Progress –> Done

Ideally, ‘Done’ means In Production, but often it means Ready for Release.  From a Lean perspective, features that are ‘Ready for Release’ but not yet ‘In Production’ can be thought of as inventory, and we want to minimise inventory, so visualising that inventory would be useful.  Thus we can change the workflow to:

To Do –> In Progress –> Ready for Release –> In Production

Looking at the start of the workflow, a common practice in Scrum is shaping the backlog, or grooming the backlog.  This is the process of ensuring that the the Product Backlog Items that we take into Sprint Planning are well-formed.  That is, that they are small enough, and understood well enough, for the team to be able to plan and deliver them within the time-box.  I don’t think this is Scrum specific.  There will always be a step of taking a business problem or goal, and transforming into pieces that can delivered incrementally and iteratively.  Sounds like Analysis to me.

To Do –> Analysis –> In Progress –> Ready for Release –> In Production

Features which are ‘To Do’ have not had any significant time invested in them yet but they are generally formed to some extent.  We can say that they Incubate. ‘Analysis’ has baggage associated with it so we can give it a different name. I like the idea that we Illustrate what we need to do as it seems to allow for the notion of using executable requirements or other lightweight, quick feedback techniques.  ‘In Progress’ now really means ‘Build (and Test)’.  We can say that at this stage we Instantiate the illustration.  ‘Ready for Release’ means that we can Demonstrate what we have instantiated.  This could also include any validation or acceptance by the business. Finally, when a feature is ‘In Production’ it should be generating value, so we can say that we Liquidate it.

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

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

Does that still seem like a waterfall process?