Managing flow with Kanban boards
We have seen elsewhere that there are three main component parts to effective management of Agile work:
- A Work Management System which stores all of the work and associated data
- A backlog which organises the work by team and product to give clear prioritisation
- A Sprint backlog which selects the work for the next iteration
Agile boards
Agile boards (or “Kanban boards”) are a very popular way of displaying the status of backlog items. In general these are used for the current items, which in Scrum means the Sprint Backlog. This is a set of work decided in Sprint Planning and then tracked over the period of the Sprint.
Agile boards represent work items as “cards” or summaries organised in columns, which show the status of the work item. The team moves the items between columns as a visual way of indicating the status of each work item.
The key use of an Agile board is a visualisation tool, generally focussed on the Sprint backlog, or used with a continuous flow approach with no iterations. This is not to have a separate set of data, but a clear way of visualising and managing the data.
There is often a misunderstanding that an Agile board becomes a “Kanban” board only if iterations are not used. Some tools (such as Atlassian’s Jira) use this terminology, contrasting “Kanban” with “Sprints”. It is true that Lean approaches focus on continuous flow but boards can be used effectively with or without iteration.
By having a central reference point there is visibility of status for the whole team, and the board becomes a focus for communication and highlighting changes. It pulls the team together to work as a team and can be used at Daily Scrum for a quick visualisation of progress towards the goal.
Make your workplace into a showcase that can be understood by everyone at a glance.
Taiichi Ohno
Boards and columns
Kanban boards have at least three columns, representing work to be started, work in development and work completed (to the quality in the Definition of Done). Teams may choose to add more columns, each representing a separate state.
The states in your own Software Development Lifecycle (SDLC) and how these map to columns in boards is something for you to agree, but in general it is a good idea to start simply.
It is easy to over-complicate and this rarely adds value.
Multiple states works well with clean hand-overs as we might see between machines in a factory. In Agile development, the team are cross-functional and work items may bounce between individuals and states with less of a defined boundary.
For example, development and verification (testing for functional correctness) are often not separate. One individual (or two using pair programming) may write code and unit tests and also perform initial testing. However, validation (testing against acceptance test) or code review may involve a handover to a different individual for independence and so may be usefully represented as a new column.
Kanban boards in Lean manufacturing
The history of Agile Boards goes back to the use of Kanban in Lean Manufacturing in the 1940s. This display medium is sometimes referred to as “Kanban boards”, although there is in reality only a tenuous connection.
Kanban is Japanese for “sign board”. It is a generic term but was adopted for a specific part of the Toyota process.
When tracking parts in a factory, Toyota would associate a set of parts with a card. For example, a box of bolts would have a specific card which always stayed with the box. The card “represented” the box of bolts, wherever the box was and whether full, empty or in use.
When the card was sent to the supplier, it represented an empty box, and was then returned with a full box. It stayed with the box until empty and was then sent back to the supplier.
What was the value added by the card? The key value is that it was a way of controlling the inventory. Inventory control is an important method in Lean, and excess inventory is one of the Lean “wastes”. Excess inventory costs money and uses space, so a factory runs best if it keeps just enough inventory for its needs and no more.
In the same way as a country limits the amount of money printed, Toyota would limit the number of cards to only the number needed. Perhaps for this box of bolts one would always be in use, one being supplied and one full waiting for use. So there would be only three cards. Since the cards represent the boxes of parts, extra boxes causing extra inventory cannot be created.
Electronic Kanban boards
Electronic Kanban boards were later developed which showed where each Kanban card was across the whole factory. They showed the state of the associated parts – waiting, in use, at the supplier. This gave centralised managers a status view of all of the inventory.
Modern Agile boards evolved from electronic boards as a centralised view of all of the work. The software boards are a visible method of showing the status of the work in the work management system. Historically these were physical (generally sticky) cards fixed to a wall at the team’s location. In a more modern form they are typically integrated into a work management system.
Kanban boards and flow
The board format can be used very successfully as a visualisation tool within Agile development. This allows you to see the overview of work status. Most Agile teams using boards probably use them in this way. However, there is no real connection with Kanban approach, and this doesn’t utilise the Lean ideas for which Kanban was invented.
Kanban was developed to control inventory, and of course there is no exact equivalent to inventory in software development. However, I would suggest that a “Kanban” usage of boards focusses on flow and on how the work is flowing through the team.
Using a board as a flow visualisation, you can see if the work is progressing smoothly. With the simple three columns, we can see the level of work in progress by the size of the middle column. If a large number of cards are in progress we risk lacking focus and not creating working software that we can review.
We might add a column for code review, after the development column and before completion. If we see multiple cards in this column, it suggests we have a bottleneck around this area. Flow is being disrupted and items delayed waiting for review. Remember that waiting is another key Lean Software waste area. The board allows the team to see these buildups and waste. They can then pick up the work or alter processes to reduce the buildup in future.
Good practices
Agile boards are an effective visualisation tool. Although they are not a requirement for Agile development, you should generally ensure that all your teams have access to these and are familiar with how they work.
Understanding how best to represent your software lifecycle is important. Separating too many states as columns can separate work and prevent team integration. However, having key states as columns will help visualise blockages.
Efficient flow is closely linked to minimising work in progress and disruptions from waiting and handovers. These can be made visible by careful use of Kanban boards. You will need to coach teams to look for, and address, bottlenecks when work in progress becomes high.
Promote a “look right” mindset in each team. Since the right hand columns are closest to completion, team members should always be scanning the columns to the right to see if they can help the team close work items. For example, they might contribute with review or validation before looking at the left and starting a new item.
Leave a Reply