Aspects of Kanbanoriginally written by Karl Scotland
Our summary and key takeaways
Karl Scotland explains the concept of a Kanban system for software development. He identifies the important aspects from which Kanban systems can be viewed in order to understand and improve an overall organization's delivery capability: workflow, visualization, work in process limit, cadence and continuous improvement. This article provides deep insight into those areas and their implications on a system.
In software development “workflow” reflects the way value flows from development to end customer and the importance of how the customer's response impacts the system. A workflow can be recognized by Value Stream Mapping, which can increase your process transparency and add to the understanding of the process.
This basic technique works on assessing how value flows through the system and what are the necessary steps along its road to the final value increase or creation – usually a step will be divided further into smaller steps and then joined back again to visualize the value added.
Karl mentions that there is typically a workflow waterfall associated with the path that value takes. It includes the following stages: incubation, illustration, development, demonstration and liquidation. He notes, that none of these stages shall be attributed to specific team members, as they are only indicative of the process, not specific tasks.
This is the part of a Kanban system, where the work is being translated into a visual aid, working on the principle that visual information is much more quick to absorb and retain than a written word.
There are several steps in which visualizing work on a board acts as a productivity and transparency boost for the team. Having the board creates a mental model in users' minds, it then gets reinforced by their carrying on looking at the board and finally it becomes part of the users' augmented reality (don't even have to look at it to see what's on it).
As the entire team builds these mental models, the Kanban board becomes the workflow model, updated regularly and truly representing the process. The most important thing to keep in mind when creating a Kanban board is making sure that the “data ink” on the board is kept to a minimum and the “data density” is high. By data ink we understand the actual wording of the task descriptions (the shorter the better), by “data density” we see the amount of information displayed in a specific area (the smaller the board, the easier to get an effective “at a glance” look).
Work In Progress
This is the crucial aspect of Kanban, which allows you to create a real pull system, one that does facilitate the team's ability to drop multi-tasking and pick up tasks one after another, completing more than they're starting.
This allows for regulating the balance between the system capacity and demand.
Utilizing WIP limits impacts the teamwork, productivity and the inventory. Karl advises on how to measure the performance by monitoring the system's Cycle Time (the # of tasks in process divided by the average completion rate) and by analysing the throughput (regulated by limiting the work in progress or decreasing the number of new items for the team to get to work on).
By putting a limit on how much can be progressed at any time, productivity improves. With this assumption, you ought to be able to get the team to focus on the current work, collaborate on the features that create bottlenecks, start new work as soon as the team's available.
This is a key mechanism to representing the team's capacity. Even though in Kanban you're not really using timed iterations, there need to be some way of establishing how quickly something can be delivered by the team. Henceforth, by monitoring the average completion rates, and including the transaction and coordination costs, the team manager shall be able to establish a system's cadence. Having the ability to do that provides a sense of completion and progression.
Once cadence is coupled with service level agreements (as a guide, not an obligation), there is no reason why a system shouldn't be reliable and predictable from a stakeholder's point of view.
A characteristic aspect of Kanban is striving to always make the process better. Whether achieved simply by limiting the WIP or by adding retrospective meetings and pin-pointing parts of the system which may not work quite as well as should, all you do in Kanban is flexible and changeable. It's a prerogative to find improvement areas and reduce unnecessary and ineffective steps and procedures.
Whichever way, and however seriously you're going to try the Kanban approach, make sure you're aware that Kanban is not as much a methodology as a set of rules, which are flexible and shall be adjusted to suit your particular needs and situation.