Introduction
I was working for a startup using a very intriguing split of delivery strategies. Our Software department had four teams using Scrum, while the Operations department’s Platform Services team was (very proudly) using Kanban.
After my “What it means to be Agile” shtick for them, I had a fascinating discussion with our Senior Cloud Architect about his reasons for why Scrum wouldn’t work for the Platform Services team. His rationale was that when the work is performed on an as-needed basis, a two-week lead time for requests didn’t get anyone what they needed. While he had longer-term projects, with the platform in its current state of maturity, adopting a ‘Pure Kanban’ approach allowed them to stay flexible, and enabled agility elsewhere.
He was right. You can’t shoehorn Scrum into every niche. They also weren’t using ‘Pure Kanban’ – their metrics, strategy, throughput, and intention weren’t being monitored – yet their processes still stood up under scrutiny. Why?
Quite often, we start doing something in a certain way because it works, even if we don’t know why. However, without that ‘why’ it’s easy to get stuck. So – this article aims to provide a basic, general overview of the theory of Kanban for software and engineering teams, and why it works the way it does, with the hope that it unblocks you in your process development journey.
(If you haven’t read my previous article on Kanban’s history, I recommend starting there first.)
Kanban is not Agile
Kanban is often incorrectly bundled up with other Agile frameworks. Arguments often revolve around the attention to continuous delivery, the language of ‘cycles’ and responding to change – which are not untrue. However, as a robust framework, it is incomplete. Agile frameworks are scaffolding consisting of rules and behaviours that enable mushy Agile values and vibes; Kanban struggles under such comparison, having little to say about behaviours that nurture individuals, inspire creativity and technical excellence, or encourage sustainable development and retrospection.
Instead, Kanban is a toolkit sitting on top of other frameworks – Agile or otherwise – used to enhance our overall delivery strategy. If we want to adopt Kanban, our question is how to make it work with our chosen Agile framework, rather than treat it as a replacement.
‘Just in Time’ vs ‘Just in Case’
What makes Kanban interesting is where the work starts.
A ‘Just in Case’ model starts work based on forecasts. Product is ‘pushed’ out through the supply chain in high volumes so it’s available if needed later. Recalling the roots of Kanban, this worked for Ford Motors, which could reasonably anticipate the rate that parts would be consumed, had huge warehouses to store them, and could afford waste. This model tanked Toyota, who struggled with demand, had no warehouse space, and was burdened with supply chain issues and sky-high costs.
A ‘Just in Time’ model – like Kanban – starts work based on demand. Product is ‘pulled’ into the supply chain only as needed. Opting for this strategy allowed Toyota to keep inventory low, and survive periods of instability by investing in salaries instead of materials they couldn’t use.
By adopting a ‘Just in Time’ attitude to software, we can optimise our development time and costs by developing only what’s required now, not what we may think others will want later.
Going with the Flow
The best way to ‘pull’ your work forward is if the path is free of bumps and blockers – and that’s where Kanban shines.
The governing principle of Kanban is Flow: the way work progresses from the time it’s requested to the time it’s delivered. Kanban provides us with tools to monitor the predictability and efficiency of how work passes through each stage of its development process (ie. its workflow). A predictable workflow is a healthy workflow, and an effective ‘flow’ allows us to ‘pull’ more easily.
Visualising Flow
The best way to monitor something is to see it – so we make what we’re doing as visible as possible.
Tasks
When a new request comes in, a task is recorded containing a description of the work that needs to be accomplished (eg. a User Story/Ticket/PBI etc). The details for the task don’t need to be comprehensive right away, so long as they’re well-scoped by the time a team selects it for development.
What is essential is that every task should consume roughly the same amount of time. If a task is expected to take longer than others, it must be split into smaller tasks. When we have confidence that each task will take the same time from start to finish, we can ensure predictability.
The Backlog
The Backlog (in Scrum known as the Product Backlog) is the list of tasks that have been created, but not started. The Backlog is ranked by priority, from highest to lowest, using whatever criteria the Backlog’s maintainers (such as Product Owners or Product Managers) see fit.
(Note that this is different from Scrum’s Sprint Backlog, which is a forecast of work plus the Sprint Goal, which nobody can add to or re-rank except the Developers.)
A task can be re-ranked in the Backlog, or modified any time up to the point that it’s selected for work.
The Kanban Board
When a task is recorded, a new, physical Kanban (Japanese for ‘Flag’ or ‘Visual Card’), or Card, is created, representing the task that needs to be completed.
The physical card is then added to our Kanban Board – a physical board with columns for the Backlog in the ‘To Do’ column, and for each stage in our workflow, from ‘In Progress’ to ‘Done.’
When a team member has capacity, they move the top card in the ‘To Do’ column into ‘In Progress’, indicating to everyone that fulfilment for that task has begun.
As that task progresses through different stages in our development workflow, the associated card is moved to the associated column on the board so that everyone has visibility of every piece of work in progress.
Pull Signals
Kanban’s transparency relies on effective mechanisms to communicate when a task is finished one stage of its workflow, and is ready to move to the next. These are called pull signals – a signal to pull the task closer to the finish line.
There are many ways to represent this which are usually more explicit than flagging during a morning stand-up or a department meeting. These could be changing the card owner, or even adding new columns to the Kanban board. Kanban doesn’t have any hard or fast rules for how to do this, beyond that they must be obvious and consistent.
“Stop Starting, Stop Finishing”
The most common blockers for any project (using Kanban or otherwise) are interruptions and pivots. Constantly stopping, starting, and spinning around leads to flow issues in the form of delays, loss of productivity, abandoned work, frustration, tension, and wasted time.
This is why, in Kanban, you never start what you cannot finish, and always finish what you start before starting something new. Work in progress always takes priority, especially over other tasks over the Backlog.
Metrics – Going with the Flow
Boards aren’t just a task list, or a place to view our workflow – they’re a stage for tracking our flow metrics, predicated on our confidence that each task will take the same amount of time from start to finish.
Our ability to read and leverage these metrics allows us to more clearly identify the blockages in our processes.
Time in Column
Time in Column is the time a card sits in a particular column.
This metric allows us to assess whether a task is taking too long (or too short) to move to the next phase, which may indicate an unresolved blocker or irregularity that needs to be resolved.
Pro tip: If you’re using Jira, you can configure your cards to show pips that, when moused-over, indicate the time in column value. Use this in your stand-ups to monitor the flow of work in progress!
Cycle Time
Cycle Time is the time delta between when the task is started, and when it is finished – between moving a card from ‘In Progress’ to ‘Done’.
This metric allows us to assess whether we are estimating or refining our tasks correctly. If the Cycle Time for each ticket is inconsistent, we need to unpack where/why things are getting stuck along the way.
Pro Tip: The ‘Control Chart’ in Jira can show how long a ticket has stayed in each status, and the cumulative time between two statuses. If we’re maintaining effective predictability across our full backlog, we should have low standard deviation.
Lead Time
Lead Time is the time between when a request is created, and when it is finished.
This metric allows us to assess how quickly we are fulfilling requests as they come in, and whether we’re scheduling our work effectively. If Lead Time is inconsistent, we need to diagnose what’s blocking us from starting – or finishing – our tasks.
This is the most important metric for true Just in Time delivery models. When a request comes in, we need to have a clear, straightforward answer about how long a customer will need to wait.
Pro Tip: The same ‘Control Chart’ in Jira can also show you the Lead Time by tweaking a few parameters.
Work in Progress Limits
One way to improve focus is to limit the number of cards allowed in each column. For example – an In Progress column may have a ‘Work in Progress’ (WIP) limit of 4, and there are already 4 cards in the column. Before moving a new card into the ‘In Progress’ column, another card must be pulled forward to make space for it.
Your WIP limit may even be less than the number of Developers on your team, meaning someone is always available to expedite tasks in play with code reviews, paired programming, proofreading, or managing the releases. While WIP limits are often (extremely) unpopular among Developers, they are one of the most effective strategies for managing flow.
Velocity vs Cumulative Flow
Some methodologies allow for tasks to be of variable size, where tasks are assigned a ‘Point’ value (representing an x-factor of time/effort/complexity) instead of a duration. The Velocity metric measures the cumulative sum of ‘Points’ delivered over fixed periods (usually measured in weeks. Think Story Points per Sprint). In this model, predictability comes from having a consistent Velocity metric over the course of months.
Kanban tracks the throughput of individual tasks of a consistent size irrespective of fixed periods. While it’s not incompatible with Velocity, there are other tools to augment our ability to visualise predictability – one such being Cumulative Flow.
Cumulative Flow tracks the number of cards in different columns across a non-fixed time period; a Cumulative Flow Diagram allowing you to visualise where cards are consistently piling up, which could indicate whether we are abandoning work, effectively managing dependencies, and whether you’re resolving tasks in your Backlog at a consistent pace. Predictability comes from having as few cards in each column at any point on a day-to-day basis.
This is extremely effective for cases such as a Platform Services backlog, where the Developer focuses on resolving issues as they come in.
A Compliment – not a Replacement
To use Kanban effectively, your team still needs a clear vision of the specific pattern of daily operations. You have definitions for accountabilities, checks and balances, meeting cadences, feedback loops, and mechanisms for communication and monitoring continuous improvement.
Whether you choose to use Scrum, SAFe, XP, or some non-Agile ‘waterfall’ framework, Kanban can be a useful set of tools – but is not prescriptive enough to be your exclusive delivery strategy.
Conclusion
I had a Scrum team that was fascinated when I told them that we were already using Kanban. They had thought there would have been some major change in our ways of working, and were shocked to learn that much of the implementation of Kanban happens away from the wider team’s view (apart from the pesky WIP Limits).
Our Platform Services team above was indeed using parts of the Kanban toolkit; whether leveraging its full power would have made a massive difference to their fairly efficient flow is hard to say. However, understanding the context and the theory certainly gave them a better insight into why certain behaviours may be working – which is often enough to inspire reflection elsewhere, and get a true transformation off the ground.
With that out of the way, I’ll share some tips and tricks on how to resolve some of the most common foibles, frustrations, and anti-patterns.
More information
This is a fairly straightforward summary of a fairly nuanced topic. It leaves out a lot of strategies on developing effective flows, synthesising metrics, and reading charts, parts of which I may cover at a later point. There are many interesting and more comprehensive sources and tools available. Here are some that I used to help write this article.
