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?
Hi Karl,
So is this post about renaming steps in a process? Is this the root of the problem that we face? That the labels drive the wrong behaviors? I think the words you have chosen are interesting, I just don’t think the debate is about words.
David Anderson made very strong statements at Agile 2008 about his philosophy of supporting the traditional activity based model of managing and operating IT, and that hand offs between groups are both acceptable and inevitable. My concern is that the speed and quality of output of the process is controlled by lossy information handoffs between each step in the process. Various approaches are being tried (ie. pairing adjacent groups) to deal with this problem. The better approach is to simplify the process by using co-located cross functional teams, pull testing to the front of the process, and make everyone responsible for quality, including the customer. In this case I would use different words, because the steps of the process are far less important than how the team works together to deliver the features.
Regards,
Robin Dymond.
“Does that still seem like a waterfall process?”
Why, yes, it absolutely does.
I suggest that for as long as Kanban-like processes are described in terms (and with pictures) that not only allow for but positively afford a linear, gates-and-handoffs, no planned re-work interpretation a great many people are going to be resistant to it.
[…] An Agile Workflow (Karl Scotland) […]
[…] 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: […]
Karl,
As I understand it the states you have described relate to the states a feature goes through, not necessarily people who hand-off work. Kanban does not preclude swarming.
I’ve added some detail on the workflow I am using with a SCRUM team here http://www.agiledesign.co.uk/scrum/agile-workflow/
Karl,
Why do you bother? 😉 The fact is that a Kanban sequence (one feature from backlog to release) is about such a short time frame (a day, maybe 2/3?) that the sequence you use is going to be very similar to analysis, design, implement, test, implement. Of course it is not linear, why do we even discuss that? But because the feature is now assigned to a small group of people they will know what to do, even if that means “breaking the sequence”.
Much of this discussion is about people getting hung up on the “tool” (the steps on the board) and completely missing the point of the process itself (reduce inventory!).
I would just start with the simple process description (to do -> in progress -> done) and forget about this discussion. When working with a team they can agree exactly what steps they need, without the whole blogosphere lecturing them! 🙂
I find the debate about this rather puzzling. Any process that supports the values and principles expressed in the Agile Manifesto can be deemed an “agile” process. What is there in the “kanban” model that conflicts with agile values and principles?
For me there is no problem at all with
Analysis –> Build –> Test –> Release
because the difference between Waterfall and Agile is a difference of SCALE in the sense of FRACTAL THEORY.
Waterfall is a single linear scale, Agile is a NON-LINEAR Fractal Scale where the 4 steps above are repeated in an improvement spiral.
In fact this 4 steps come from the PDCA of Deming, the founder of Quality who taught it to the Japenese, which comes itself comes Walter Shewhart which comes itself from the scientific principle of Aristotle circle 🙂
Everybody does exactly these steps for each story in SCRUM in the “In Progress” stage
Analysis –> Build –> Test –> Release