At GDS, we believe that self-organising teams create the best results. So we give each of our teams the autonomy to pick the delivery approach that works best for them. On the GOV.UK Publishing Platform, we use Kanban to help us manage the work we do.
Kanban was created by Toyota in 1950s Japan as a system to help them minimise waste in car manufacturing. More recently it was adapted for use by software teams. Nowadays it is one of the most popular and lightweight agile methodologies, and is in use throughout GDS on software and non-software teams alike.
There are five principles that we use in our Kanban system:
1. Visualise our work
All our work is visualised on a Kanban board. We use an online tool called Trello, but lots of other teams use a physical team wall instead. Each column represents a stage in our production process. Each card represents a problem that our development team are trying to solve. Cards flow from left to right, from “To do” on the far left all the way to “Done” on the far right.
Each card contains detailed information about the work the team are doing. But at first glance we only show a brief title, categorisation labels and the avatar of any team members working on it. We keep it simple so that we can quickly convey to team members or stakeholders what we’re working on, what stage it’s at and who is working on what. Visualising our work also allows us to see how work flows through our system and spot areas that may need improving.
2. Limit work in progress
In each of our Trello lists, we’ve set a work-in-progress limit. For example, we can’t have any more than 4 cards in “doing” and 2 cards in “technical review”. So if the technical review list is at capacity, it becomes a bottleneck, stopping any more cards from getting pulled through from “doing”. This gives the team a clear visual message that they need to focus on the cards in technical review in order to unblock the system.
Limiting work-in-progress makes sense because humans are bad at multitasking. When we work on too many things at once, we become less efficient. If we do fewer things, we can do them better, and often faster. Work-in-progress limits force teams to work together to stop bottlenecks emerging.
They can also be used to correct behavioural issues in a team. By having a low work-in-progress limit on Technical Review, we encourage team members to get into the habit of reviewing other people’s code before picking up new stories, which increases the efficiency of the team.
3. Manage flow
Our focus as a team is making work flow from “to do” to “done” as quickly as possible, allowing us to deliver value to our users early.
Cycle time is our measure of flow. It measures the time taken for a piece of work to be complete once started. Reducing our work-in-progress is one of the best ways to reduce cycle time. Another is to break big features down into smaller, consistently sized user stories, helping us to achieve predictability in our delivery.
4. Make policies explicit
In Kanban, ‘policies’ are the rules that define how our team works together, and like every other part of our process we try to keep them simple and visualise them.
Two common policies in Kanban teams are “definitions of done” and “acceptance criteria”. Definitions of done are criteria all pieces of work must meet before they can be considered done, or to move from one stage to another. Acceptance criteria are similar, except that they are unique to each story.
We also have a team charter which documents our collectively agreed team values and working practices. This helps new joiners to understand the way we work, and reminds existing team members of the actions we’ve agreed to.
5. Improve collaboratively and evolve experimentally
We use regular retrospectives to give everyone in the team a chance to identify and discuss potential improvements in a safe and supportive environment. We ask questions such as what’s working well, what’s not working so well, what have we learned and what can we change. Out of these discussions come actionable improvements we can use to try to make our process better.
For example, we recently added a policy that once a developer finishes a task, they should always try to pick up a task from the right-hand side of the board. These decisions are always experimental - if a policy doesn’t solve the problem it was introduced to address, it would be scrapped by the team at the earliest opportunity.
It’s ok to break the rules occasionally
Work-in-progress limits and policies are not laws that we hold ourselves to rigidly. Sometimes, it makes sense to break the rules, so long as it’s a conscious decision. If and when this happens, it’s important for the team to reflect on whether this is a one-off exception, or whether the policy needs to be adapted.
Why Kanban works for us
We operate in an uncertain environment, and we’re constantly learning more about the needs of our users. By releasing valuable new features continuously to our users, we get feedback quicker which gives us the information we need to make better decisions. And by delaying product decisions to the last responsible moment, we make the most of this knowledge and minimise waste in our process.
Why Kanban can be useful for a team new to agile
The focus in Kanban is on evolutionary rather than revolutionary change. It takes the processes and policies a team has now, and adds work-in-progress limits, a focus on flow and a commitment to continuously improve over time. It creates the environment necessary for a self-organising team to evolve itself over time. That’s it. There’s no special job roles or meetings that are required for it to work. This makes it an effective tool for change management, because people generally dislike change that is externally imposed and find it easier to make progress one small step at a time. If you’re keen to start using Kanban but are new to the methodology, it makes sense to enlist the help of a delivery manager or agile coach.
Alan is a senior delivery manager on GOV.UK. You can follow him on Twitter.
6 comments
Comment by Dan Dineen posted on
Great article Alan. Thanks for putting it together 🙂 Is there a downloadable version of the team charter document anywhere? I'd love to have a look at the whole thing.
Comment by Alan Wright posted on
Thanks Dan! It's not something we've got online, so I've shared a copy with you via email. Cheers
Comment by Malcolm Doody posted on
"once a developer finishes a task, they should always try to pick up a task from the right-hand side of the board." ... isn't that the "Done" side 🙂
Comment by Alan Wright posted on
Not that far to the right Malcolm 😉
Comment by Leon Shivamber posted on
Fantastic application of Kanban. Wish more electronic supply chains would embrace these simple yet effective management methods. Congratulations
Comment by Alan Wright posted on
Thanks Leon!