Karl Scotland started a discussion examining whether the workflows or stages in a kanban system are counter to the agile ideals of cross-functional and collaborative teams. He started by noting that the stages on a kanban board can look a lot like the phases of waterfall. The ensuing discussion clarified that stages are not necessarily hand-offs, and led to other insights as well.
Karl started with an examination of a kanban system that looked very similar to a waterfall process:
Analysis -> Build -> Test -> Release
Next he looked at a typical Scrum taskboard, which looks like this:
To Do -> In Progress -> Done
Karl then looked for ways to have this taskboard reveal more information about how work is flowing through the system. In many environments, features (stories) that have been marked 'done' are not immediately released, or put into the production environment. In these situations, in can be illuminating to mark the distinction between 'ready for production' and 'in production' on the board. If the board reveals that work in progress is piling up awaiting release, the business might decide to optimize the process by adopting continuous deployment, for example.
Karl goes on to find other ways to subdivide the stages on the taskboard. He also suggests names that he feels are more indicative of the work going on at each stage, ultimately arriving at this flow:
Incubate –> Illustrate –> Instantiate –> Demonstrate –> Liquidate
The ensuing discussion began with Robin Dymond noting that simply changing labels isn't likely to change behavior, but that changing labels could be part of a bigger solution:
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.
Keith Braitwaite had this observation:
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.
This observation is congruent with much of the agile doctrine, which seeks to avoid hand-offs and eliminate or shorten sequences, in order to facilitate tighter feedback loops. For example, while the agile practice of test driven development has stages:
Test -> Code -> Refactor
In practice, a developer will cycle through these so quickly that tracking them on a taskboard would be tedious.
From a lean perspective, what is important is that features are continuously pulled through the system (continuous flow), as opposed to work being queued up and then completed in batches. The traditional waterfall process is an example of a batch-and-queue approach. All of the requirements gathering work is done in a batch, with requirements getting queued up waiting for design work to begin. Similarly, the design work is doe as a batch and the output is queued up for coding, and so on.
In a continuous flow system, features are pulled from the backlog and then worked on continuously until they are completed. If there are identifiable stages during development, a kanban board can be used to identify where work in progress is stacking up. These bottlenecks are then targeted for process improvement, to keep the work flowing through the system efficiently.
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.
Vasco Duarte felt that the discussion was too focused on process and tools, and missed the point of kanban, which is to reduce work-in-progress.
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."
Indeed, if the kanban board is being used to make sure that each of the required activities has occurred, it is being used to enforce the team's definition of done, a job better suited to a simple checklist.
Do the states on a kanban board seem like stages in a waterfall process to you? If so, is the similarity superficial or important? Leave a comment and share your perspective.