Kanban at New Broadcasting House

The BBC’s New Broadcasting House, overlooking the impressive BBC Newsroom, was the venue of the Kanban Meetup on 15th November 2012. Hosted by The BBC Academy, the event was organised by Agility in Mind working in partnership with the Academy team.  Around fifty people attended from many organisations, with a common interest of sharing their experiences of using Kanban and to connect up with others. There was time before the main talks for people to get together over refreshments and find out where people had come from and why they were there. Andy Wilson Head from the Centre of Technology at The BBC Academy, gave a very warm welcome to everyone and introduced the speakers.

Stuck in the middle

First up was Edward Scotcher, director at Agility in Mind, who told the story of Mehran Karimi Nasseri, who was stuck in Paris Charles de Gaulle Airport from 1988 to 2006.

Mehran was granted refugee status and, on his way to Britain, he had his papers stolen and got stuck in the Paris airport.  The authorities didn’t know how to handle the situation – he couldn’t leave the airport and enter France and he couldn’t travel to any other country.  He was stuck in the middle of someone else’s system and the rules could not be broken.

Ed talked about the world of software development, where today there is often a big cumbersome process with many rules and where development teams often find themselves stuck in the middle. For example, the adoption of agile methods such as Scrum, offer great opportunity to improve the development process but, in doing so, show up bottlenecks and deficiencies external to the Scrum team. As they improve their internal process, external problems are emphasised even more.

When Ed was working with a team at the BBC recently he helped them to map out the process they go through to get a product into development. It showed that the steps they went through before development was far more complex and demanding than their Scrum-based development process. This gave them insight so they could take action to address blockers and inefficiencies “upstream”. He made the point that, within just a short amount of time, they were able to model the existing process and begin to make things visible – beginning to use Kanban tools and apply the principles in simple, practical ways.

So, in looking at Kanban, Ed explained there is plenty of hype, with people trying to exploit the simplicity of the approach and force a more rigid framework. Maintaining alignment with agile principles, Kanban offers teams the tools to begin to visualise the processes in place and to break down those self-imposed rules which everyone accepts, but few question why.

Ed brought us back to the story – whatever happened to Mehran? Well he got ill and the only way to deal with it was to take him to hospital and the only way to do that was to break the rules.  So it seemed those rules that kept him confined for all of those years could be broken but no one was brave enough to do so, until things got critical.  Ultimately, whatever we do, is all about people: individuals and interactions are more important than processes and tools – and rules.

From Scrum to Kanban

Sabina Kamber Salamanca is Senior Technical Project Manager and Agile Coach for BBC Future Media, Programmes and On Demand and talked about the transition to Kanban for the Media Playout Team. She is a passionate professional, eager to improve the way her team delivers even better products.

Sabina explained that, with her team, she has adopted Kanban because they wanted to better understand how product was flowing (or not) through the entire process – upstream and downstream of development.  The outcomes being sought were to achieve continuous flow of software product and reduce the time from concept through to delivery.

Whilst Scrum has been used for some time, true across much of the BBC Future Media, their inspection of the development process showed that it was great at emphasising what takes place internal to the development team, but gave little or no insight into getting things ready for development or getting them into live. They also identified that the fixed, two-week, development cycles had become a constraint and the use of story points for estimating and forecasting were no longer considered to be robust.  Rather, they wanted product freely flowing and wanted real measures of flow based on time (lead and cycle times).

The team lives and breathes a Kaizen culture and used agile principles of inspect and adapt to achieve incremental change to their process. In fact, their first Kanban board modelled the existing process, with the Scrum development model fully intact. They introduced columns to the left and to the right of the Scrum Sprints. When they were ready, they began to take out some of the existing ceremony, such as Sprint planning, and began to “pull through” items to be developed. They then developed and implemented Exit Criteria for each of their Kanban columns.

Their Kanban board today has much better defined columns and they have removed the Scrum-specific ones they had before.  Developers and testers pull work through when they have a “gap” (the capacity to take it on).  Work in Progress limits are applied in “Getting ready for development”, “Development” and “QA” columns. There is also an express lane, that allows them to deal with critical pieces of work.

Continual improvement is now a central part of the team and they ask themselves questions such as:

•       Are we building the right thing/s?

•       Are we delivering with frequency?

•       Are we happy with the time it takes us to complete the work?

•       Are we happy how much we take on versus our capacity to deliver?

•       Is our quality fit for purpose?

Sabina and her team still believe in and are aligned with agile principles and values, which they continue to nurture, and they still have to deal with problems.  It was clear that, by modelling the entire process and engaging stakeholders in the adoption of Kanban, meant also that the principles and values need to be adopted wider than her team, something which they will continue to promote.

This is such a great story of passion and courage to do things differently for the benefit of the product and it’s stakeholders, but achieved incrementally and without preaching a new set of rules.  Rather, people working together, to deliver a better product.

Lead Time and Throughput

Dan Brown is an experienced Agile Coach, ScrumMaster and Agile & Kanban Trainer, and has worked with many organisations, including the BBC.

Dan addressed the subject of Lead Time and Throughput, using some maths to illustrate the concepts.  He began with a challenge – to count the number of stars shown in Andromeda, a task that no one was easily going to do in the time available and, given that there are in the order 1000 billion, a pointless task if we had tried. Life in the software world often involves estimating the size of the unknown and the unfamiliar.

Instead of estimation, Dan illustrated with a simple example, and maths to go along with it, how predictability could be applied and be more useful.

At a “Drive Thru” take away, a customer drives up and orders a burger; when the order is ready, the customer drives away. In this example:

Lead Time (LT) – time measured from when the customer arrives to when customer drives away – how long the customer has to wait.

Cycle Time (CT) – time measured between each customer driving away, on average.

Throughput Rate (TR) – how frequently customers drive away with burgers (e.g. number of customers per hour), the inverse of Cycle Time.

Work in Progress (WIP) – the number of customers in the process waiting for their order to be fulfilled.

In the example, if there is just one window, where the attendant takes the order, takes the payment and delivers the take-away, then the average Lead Time will be equal to the average Cycle Time – there is only one step in the process.

However, if there are two windows, one taking the order and payment and the second fulfilling the order, then Lead Time and Cycle Time will be different, as customers will be “stuck in the process”. In other words, when we introduce Work in Progress we have an impact on Lead Time.

For example, with the two windows, if it takes 40s to take the order and payment and then 50s to deliver the order, then the Lead Time is the 40s + 50s = 90s.  However, if you look at how often customers are leaving the Drive Thru, you will just look at the second window, where they will be leaving every 50s, the Cycle Time.

So why do our customers care, when receiving software product?

Throughput Rate: how frequently will new features be delivered?

Lead Time: when will this feature be done if we start now?

Cycle Time: if I’ve just received a new feature when will the next one be done?

And this then allows you to derive how long the whole product will take.

Product Time = Lead Time + (Number of features * Cycle Time) i.e. the time for the first feature to get through plus the time for all the following features.

As an example:

You deliver one new feature every two days: Cycle Time = 2 days; Throughput Rate = 0.5 features per day

Let’s say, each item takes 11 days to deliver: Lead Time = 11 days

If we have 100 features to deliver

Then Total Product Time = 11 days + 100 * 2 days = 211 days

But you have to remember that averages for Lead Time, Cycle Time and Throughput Rate will smooth out variances, which could be significant in real life.

Little’s Law links these values and, although Dan didn’t have time to go into it on the night, here is the formula:

Or

Now, if the time at each of the windows changes, so that it is slower at the second compared to the first, say 50s and 40s respectively, then our Throughput Rate is limited by the time at the second window.  In this case, we would have a car at each window at any one time so WIP is 2, the Cycle Time is 50s therefore the average Lead Time = WIP * CT = 2 * 50s = 100s.

However, if we have space between windows, then a queue will build at the second, although the length of that queue will be limited by space, let’s say 3 cars. So, total WIP is 5 (a car at each window and three waiting in the space).

In this case the average Lead Time is WIP * CT = 5 * 50s = 250s.

What this illustrates is that, unless we do things to improve Throughput (by reducing Cycle Time) on our system, the effect of taking more work into the system (WIP) will have a direct impact on how long we have to wait (Lead Time).