This is the fourth in a series of blogs on how we are using the Agile methodology at Open Knowledge International. Originating from software development, the Agile manifesto describes a set of principles that prioritise agility in work processes: for example through continuous development, self-organised teams with frequent interactions and quick responses to change (http://agilemanifesto.org). In this blogging series we explore the different ways Agile can be used to work better in teams and to create more efficiency in how to deliver projects. Previous posts dealt with user stories, methodologies and the use of scrum and sprints in open data: this time we go into Kanban. 

Picking a methodology has to take into account both the team doing the work but also the project. Bigger teams call for a bigger methodology, and more critical projects call for more methodology density (higher ceremony or publicly visible correctness). Bigger methodology adds larger amount of cost to the project. So picking a big methodology, with high ceremony, for a small team and less critical projects is a waste of time, money and effort.

Scrum is an example of a relatively big methodology with high ceremony (in the agile universe). There are daily standups, sprint backlogs and commitments, product owner, scrum masters etc. Always going for Scrum may make us look like we’re organised, but we might be organised in the wrong way.

Less can lead to more

The opposite of Scrum in the agile world is perhaps Kanban. It’s designed to not interfere in any way with how the team already works. It may even be an addition to Scrum. It’s a form of what has been called Just-In-Time delivery/development.

In Scrum the team creates a sprint backlog of what the team commits to and what will be worked on during the sprint. During the sprint, which typically ranges from 2-4 weeks, nobody can touch the backlog: nothing can be added, nothing can be modified. Items in the sprint backlog can only be closed. This is done to allow the team to focus on delivery, not requirements discussions.

Kanban works on a different level. In Japanese Kan stands for card and ban means for signal. Kanban could therefore be translated as Card signals and that comes pretty close because Kanban is about using cards or some equivalent of cards to signal progress. It’s a card dashboard showing what’s being done where. There is no sprint that denotes work units, it’s just continuous work and planning when needed, or just in time.

Spreadsheet planning

In its essence, Kanban is progress visualised in a structured spreadsheet. You have columns that show different stages of progress or work. The different stages can include:

• Incoming work
• Brainstorming/Specifications
• Implementation/development
• Ready for review
• In tests/proofreading
• Ready for deployment
• Deployed

This is not a be all, end all list. This is an example of what columns might be included. Kanban doesn’t tell us what columns we should use. Kanban is designed to be an addition on top of our current processes.

The rows in our spreadsheet is used to track different aspects of the project. For example, if we have different members of the team working in different areas: Designers, content writers, software developers, a row would represent each area. This could also be used to track features of the project if the team is homogeneous (all team members work together in the same area, e.g. all software developers).

The cells of the spreadsheet will then include requirements, for example user stories, that are in each stage for each feature or team. If we remember the requirements iceberg, this this is the 1-2 day tasks that we perform.

Visualising progress

As work progresses on each requirement item, it moves between the different columns. This creates the Kanban dashboard, visualising progress of the project. Kanban encourages autonomy and leadership on all levels. Every team member can come in each day, have a look at what’s needed and just do some work and then once done, move it between columns. That’s part of the just-in-time attitude. We don’t need to plan everything in beforehand, things will be done just in time.

That means for managers, who normally push schedules for work to team members, they now have to sit back and give the team autonomy over the process. Likewise, team members who are used to being told what to do, now have to take matters into their own hands and pull the work that needs to be done.

What about prioritisation you may ask? What about team members just picking low-hanging fruit or easy tasks and leave all the boring tasks until last even if they are the highest priority?

Kanban puts limits on each column. How many is up to the team, but it is not allowed to have more than a prefixed amount of requirements in each column at any given moment. So there might never be more than 8 incoming work items, 2 items being drafted, 3 being implemented etc. The only exception to this can be the last column, delivered which collects everything that has been done, but is usually not a part of the Kanban dashboard or if it is, then it’s regularly purged.

So if the team wants to implement a drafted feature but the amount of items in the implementation column has already reached the maximum they need to sort that out first, before they can take on more implementation work. The project manager or client representative will typically manage the incoming work column but that one is also limited by the maximum amount and progress.

Common sense should of course be applied to these limitations. If the team is heterogeneous, i.e. each row in the “pretend spreadsheet” is a different area instead of a different feature, the limitations apply to each of the cells in the column (e.g. we can’t have the content team limit the software developers just because they have more to do).

Principles

Kanban is really simple, it’s all about visualising the work flow and not overwhelming the team. It’s built around four principles:

• It should work with whatever process is currently used by the team
• It helps the team make small incremental changes towards improvement
• It respects roles and responsibilities of each team member
• To each her/his own, team members are autonomous and leaders over their own work

It should be really simple to pick up Kanban and add it on top of whatever you’re doing today. Kanban works really well for whiteboards but the biggest obstacle for a remote organisation is finding a good digital tool for the workflow visualisation; Trello might work if if you don’t care too much about the rows. Google spreadsheet might work if you don’t care about the extra effort of moving things around.

If you find a good way to manage a Kanban board, please share it through the comments below or on our forum!