Clients, delivery, change and Kanban

Darwin stated in his book “On the Origin of Species” that “It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.”

What any project team team fears the most are unexpected changes, but at the same time we all know that changes will be part of a project. These changes can be driven by economic conditions, or by strategic changes in the company, or simply because the initial idea doesn’t sound as bright as it sounded at the beginning of the project.

An average size project will be delivered between 6 – 12 months. A lot can happen, and a lot can change, in that period

So to paraphrase Darwin: “It is not the richest of the companies that survives, nor the biggest that survives. It is the ones that are the most creative and adaptable to change.”

Some of the best examples of companies that have adapted themselves to changes are IBM (in 2005 selling their personal computer business to Lenovo), or General Electric (diversifying their business continually, it is the only company that opened the Dow Jones index that is still trading) or lately Apple, with the launch of the iMac, iPod, iTunes, iPad.

“Agile” and “Scrum”

So now let’s bring this idea, quick adaptation to change, to the project development framework. Probably the first thing that will come to your head is the agile approach and “Scrum”. Scrum is an incremental software development methodology following the agile principles. One of the main characteristics of Scrum is the iteration of development. These iterations, called sprints, are “timeboxed” software deliverables. At the beginning of the sprint it will be decided what should be delivered at the end of it. The average length of a sprint is between 2 and 4 weeks.

But even if Agile-Scrum is very good methodology, what are the constraints that its adopters experience in a fast paced software development project?

1. The client (customer) typically only has input before the sprint starts, not during it.
2. If a developer has finished their work during the sprint, they must wait for the next sprint for more work.
3. If a change that affects the delivery of the sprint happens, the value of the work completed may be lost.

All these constraints are a result of the timeboxed approach that Agile-Scrum uses. So is there any non-timeboxed approach that will let us adapt quicker to the changes? The answer is yes!

Kanban

Kanban was invented by Taiichi Ohno as a solution for making Toyota’s manufacturing processes more efficient. Toyota wanted to mimic the supermarket approach of “Just in Time” (JIT) where the customer has what they want, when they want and in the quantity they want, while the supermarket stocks only what they believe what they will sell in the very near future.

Even if producing software is a different activity to making cars or selling bottles of milk at your local Tesco Express, the same principles can be applied. We want our client to get what they want, when they want, using just the amount of resources needed. We don’t want wastage (rotten tomatoes at Tesco, or software developers bored with nothing to do), we don’t want overstock (1000 cars that are not going to be sold and need to be stored somewhere, or four developers that have nothing to do so spend the whole day talking about Star Wars or The IT Crowd) .

Quick introduction to Kanban

Kanban means billboard. All the Kanban development is managed through the billboard. These are some examples of a Kanban billboard:

There are two things that you will notice straight away:

1. The two billboards don’t have the same naming in the columns. That’s correct!  Kanban is a tool that we will use to develop a product. Tools are there to help us and to be adapted to our purpose and not in the other way around.  We are going to define the best structure for our way of working. This is an exercise that all the project team should be involved in as there should be a consensus around it. The whole team should be comfortable with this structure and stick to it as much as possible.
2. On top of each column there is a number. That is the work in progress (WIP). The WIP indicates the maximum amount of tasks that are allowed to be in this column at the same time. As with the number of columns and their structure, the maximum WIP of each column should be agreed by the team.

Next Time…

So how does Kanban actually work in practice? Now that you have seen how a Kanban billboard looks like it’s time to see how Kanban works.  In Part Two of this article we will walk through a detailed example.