BBC Case Study of Lean Software Development

This is an insightful case study, analyzing the intricate details of initial applying of a Kanban system to a software development. The case study was focused on a 9-people team, working for BBC Worldwide, over a 12 month period. The study encompasses every aspect of the Kanban-associated change, analyzing the boards, the daily meetings and the accompanying analysis. There is also a look at the importance of the office set-up, the display of information radiators, the right approach to work and of cooperation.

What was new in what they were doing?

The team was surrounded by 2 Kanban boards and 4 other information radiators to boost. Of course, all work was recorded on sticky notes and placed right onto an appropriate board, there was also a rule of not working nor mentioning any jobs unrecorded on a board. They also implemented daily stand-up meetings, discussing three questions: what items have been started since yesterday, which are being progressed today and which of them have come upon any impediments. Very quickly, the application of WIP limits diametrically changed the way the team gained awareness of any bottlenecks and the actual work being progressed at any time.

The BBC team was monitoring their work with regards to a detailed lead time (the time from when a task was waiting for being worked on to the moment it's been completed) and comparing this to the development time (the time actually spent working). They were also examining the release times from one month to another, also respecting the time the tasks were present on a board to the time during which they were being processed. Regarding this analysis, the expectation was always for releasing more than before.

There was also room for recording so called Live Defects (support tickets coming in regardless of what the team was working on otherwise. The vital part of the way the team has worked was taking the time to sum up the analytical data each month and basing on this - draw conclusions. This way with each month the team was able to smooth out some imperfections, tweak something they do and all in all, with time create a change.

What were the effects?

By analysis of the way the BBC team has been performing, and comparing it to Little's Law (stating that all throughput equals WIP divided by the cycle time), and keeping in mind that the overall goal of Lean management is to decrease variability within a system, Middleton and Joyce were able to conclude, that because of the fact, that the team was only grabbing new work, when there was enough capacity to do this, and because the Cycle Time was being kept on a correct level thanks to continuous improvement and sticking to the WIP limit - the system was working.

The team's take on why were they doing better had lied in the following observations: they were processing the highest valued (by customers) items only, and doing it quickly; they have minimized waste by allowing full transparency regarding the task details and also, they felt that the customers preferred the new approach too. Therefore the numbers started to rise. Soon, the team was delivering software improved within a lead time bettered by 37%, the consistency of their delivery rose by 47% and any defects reported by customers fell by 24%.

The importance of this study

The authors of the study are quite right to underline the importance of the data collected, particularly in the light of a considerable lack of any alternative data speaking for (or against) the implementation of Agile management methods. However, they don't fail to point out, that the way the BBC team has operated during this study has significant lean traces to it (rather than Agile). What they have in mind specifically?

• Push vs. pull method - whereas Scrum has a tendency to remain a push model, the team here has doubtlessly been sticking to a pull model;
• Relying on data, not job descriptions - when you view the Scrum stand-up, you notice, that focus is on what a team member has been doing and has in store; meanwhile, this Lean team's stand-ups were concentrated on the items' progress through stages, more than on the people themselves.
• Kaizen (continuous improvement) - while doing Scrum, there is a tendency to retrospect - by summing up the numbers of items delivered, but without the ability to draw conclusions, as item sizes can differ and there is no clear way to measure progress comprehensively. Now, with the way the case team was working and measuring the Lead and Cycle Time, they have been able to monitor any improvement, learn and possibly set goals for themselves.
• Another alteration, from typical Agile ways in what the team had been doing, was the lack of a Scrum Master or someone of a similar function. All of the team members were contributing and working on clearing any bottlenecks, so there was no danger of people picking and choosing the tasks they liked, it was more a case of combined effort.

Conclusion

Taking into consideration that the hypothesis of the study was that lean management can improve a software development process, there is no doubt that it has been proven correct. By reducing the permitted workload, allowing continuous improvement, through providing and monitoring statistic measurements the team was able to cut down waste and lead time, reduce variability and largely improve on their teamwork capabilities.

Read more Case Studies »