Kanban from a Trench

Kanban is a project management technique used, among others, in software development, known for facilitating good quality deliveries. Matt introduces us into some of the practices he has been using as part of Kanban, while working on the BBC Worldwide team in 2013. The software development teams that Matt had been working with had used Kanban boards that cover a following range of areas:

The team pool

This will be pictures of the team members, which get attached to specific tasks as the people are beginning to work on them. Normally there will be two avatars (pictures) per person, to allow them to be assigned to two things at a time.

A set of columns representing the actual process stages

There will usually be a column for each milestone along the development process. There is no prescribed way to set the columns, but for all Kanban beginners, Matt is happy to provide an exemplary set of stage columns:

• Inventory [collection of tasks with no detailed description]
• Identify [a list of features that the team has decided to work on]
• Analyse & Design [in full detail]
• Develop and Quality Assurance [together with automated tests]
• Ready to deploy.

Each of the steps of the process will have a WIP limit applied, as this is the characteristic that actually transforms a task board into a Kanban board. Limiting the work in progress results in elimination of multi-tasking, increasing focus and productivity and getting better delivery rates (the same amount of tasks started gets completed, as opposed to starting tens of jobs and hardly bringing any to an end). It's also encouraged to split columns into sub-columns if necessary, in order to gain higher visibility and better manage the workload / team capacity.

Specific streams

It's often the case, that certain kinds of jobs need to be performed in a certain chain order. It therefore makes sense to present them in this manner. This makes looking at the process and following the progress much easier.

A group of feature tasks

The main objective of using a Kanban board is improving the performance by visualization of the workflow. Great aid to immediate identification of the nature of specific tasks is achieved by color coding the cards in accordance to what does a task entail (red for bugs, blue for new features, yellow for specifications etc.). It's also very important for the board to be regularly updated. No point keeping it, if the information it presents is a week old, is there?

A calendar of important events

Keeping people up to date with when certain features are due, when someone will not be available etc. is a standard part of good teamwork.

Maintenance work

If you take into consideration that software development tends to involve dealing with maintaining the past products (with their bugs and upgrades), as well as developing new ones. This calls for deciding on a good approach to balancing work on both, while keeping in mind, that the new features are expected for a brisk delivery.

In Matt's experience, it is a good idea to either run different workflows or just swimlanes for the two work areas, and assign people to work on tasks from both of them, but without joining them up.

Other practices

Matt also mentions the 3-point delivery estimation that his team had been using (best scenario, worst scenario and expected). According to the points, they decided on which tasks need doing when. Similarly, to each feature there should be an attachment, describing the feature's architecture in 3 stages (current, aspirational, final). There had also been put in place an intricate process of deciding a feature ready, after asking the team about their definition of ready.

The Kanban board is placed in a place well visible to all on the team. Managed and updated by both the team and managers, it remains the reference point for all work and each team member.

Read our article on Kanban for Software Development »