Lean Software Management: BBC Worldwide Case Study submitted to Professor Shervin Shirmohammadi in partial fulfillment of the requirements for the course ELG 5100 submitted by Taiyan Yu ( ) & Menglan Liu ( )

Outline Introduction of Lean thinking Research Methodology Reliability of The Data Collected Digital Hub Team Performance Data and Analysis Additional Tips Future Works Conclusion

Lean Thinking Seven principles [3] [4] : Eliminate waste Amplify learning Decide as late as possible Deliver as fast as possible Empower the team Build integrity in See the whole

Toyota Production System (TPS) [1] Space Manpower Materials time

Research Methodology Hypothesis Implementing lean practices Reduce: lead times error rates variability Method Observation + Phone calls + s

Research Methodology(…) Data were collected from: 1) Digital Hub (Digi-Hub) Team 2) Semi-structured interviews 3) Kanban boards 4) Recording the operation of lean system 5) Daily “stand-up” meeting 6) Review the outputs

Reliability of The Data Collected Time Line Implementation: April 2008 Data: August 2008 (collected) October 2008 (used)

Reliability of The Data Collected(…) Size and Volume of Work Started Minimum Marketable Features (MMFs)

Reliability of The Data Collected(…) Complexity of Work Governance Arrangements Composition of Team Engineering Practices

Digital Hub Team Office Layout and Work Flow: two kanban boards (A,B) and four information radiators (C,D,E,F)

Digital Hub Team(…)

Daily Standup

Digital Hub Team(…) Release notification and daily support process tasks Record decisions Vote

Performance Data and Analysis An integral part of any lean manufacturing implementation is a variability reduction effort, to enable a process to achieve the same (or greater) throughput with less WIP Throughput = WIP/cycletime average output the inventory between the start and finish points of a production process the time a unit spends as WIP

Performance Data and Analysis 1. Lead Time: the total elapsed time from when a customer requests software to when the finished software is released to the customer. kanban board A: “decomposed engineering ready” to kanban board B: “release ready”. results show software is being delivered with 47% less variance and on average 37% quicker.

Performance Data and Analysis 2. Development Time: is recorded in working days, from kanban board B stages: Dev. Ready to Dev. Complete. The variance of development time fell by 78% from 30.5 days to 6.8 days. The mean development time was reduced 73% from 9.2 to 2.5 working days over the nine months.

3. Release Frequency Per Month: the number of items released to customers. Performance Data and Analysis a blanket release freeze to ensure complete priority was given to the production of year-end financial data

4. Live Defects Per Week: the bugs reported by customers during a week plus the bugs still open. recorded on red kanban cards and added to the Dev. (Development) stage of kanban board B. Performance Data and Analysis Variance fell by 33% as the upper control limit reduced from 7.6 to 5.1 open bugs per week. Defects still open and reported each week fell by 24% from 2.9 to 2.2

Performance Data and Analysis 5. Continuous Improvement : issues identified and time to resolve. The outlier in 2008 was a result of waiting for a third party to complete their work (a special cause). Over the 12 months, the mean number of working days items were blocked was reduced by 81% from a mean of 25.8 days to 4.9 days per month.

Additional Tips 1. A master kanban board can be used to record and summarize the progress of all the smaller projects. 2. Lean requires a stable, experienced team with low staff turnover and a project manager who knows the skills and abilities of their team. 3. Lean is not a substitute for professional software engineering practice.

Future Works The time taken to move on kanban board A from “proposed ideas” to “decomposed engineering ready” is currently not recorded, and this time could be significant. Lead time could potentially be further reduced by make UAT easier for customers.

Conclusion The volume of work that was allowed to enter the process The reduced cycle time Continuous improvement carried out by the team on a daily basis Statistical process control

Reference [1] J. M. Morgan and J. K. Liker. The Toyota Product Development System: Integrating People, Process and Technology. New York: Productivity Press,2006. [2] Er. Kirtesh. Jailia, Mrs. Sujata, Mrs. Manisha. Jailia, Mrs. Manisha. Agarwal, Lean Software Development(“As a Survival Tool in Recession”), International Journal of Software Engineering andItsApplicationsVol.5No.3,July,2011 [3] M. Poppendieck and T. Poppendieck, Lean Software Development: An Agile Toolkit. Boston, MA:Addison-Wesley,2003. [4] Mary Poppendieck, MichaelA. Cusumano, Lean Software Development: A Tutorial, IEEE Software,Sep/Oct,2012. [5] Scrum-ban: Thank you:)