Lean Software Management: BBC Worldwide Case Study

EECS811: IT Project ManagementCase StudyCody MockFebruary 8, 2016

2

Lean Software Management: BBC Worldwide Case Study Middleton, P., and D. Joyce. "Lean Software Management: BBC Worldwide Case Study." IEEE Transactions on Engineering Management IEEE Trans. Eng. Manage. 59.1 (2012): 20-32. Web.

I chose this case study because I wanted to learn more about the lean software approach and how it compares to agile processes. I have also studied Toyota's manufacturing practices in the past and wanted to see how these practices can be used with the software development process.

3

Organization

• Introduction• Research Methodology• Reliability of the Data Collected• Digital Hub Team • Results• Analysis• Conclusion

4

Introduction: Case study

• Nine-person software from BBC Worldwide.• Observed between April 2008 and October

2009.

5

Introduction: What is lean?

• Does anyone know what lean is/work in it on a regular basis?

• Has its roots in Toyota Production System (TPS).

• The basis of lean is the continuous elimination of waste.

• Focus on the flow of work through the system.

6

Introduction: Lean Software Process

In general, a lean software process can offer three benefits:

1. The process control in lean software allows for quantification of the software development process. CMMI level 4: DoD contracts.

2. Using lean for both manufacturing and software development, a common language and "creation" process can be used.

3. Lower risk and more productivity leading to increased profits.

7

Research Methodology

• Hypothesis: applying the ideas normally found in lean manufacturing would improve the capability of a software development process.

• Limited scope of lean implementation. Only software development team was lean. The rest of the organization remained the same.

8

Research Methodology

Because of this, only half of Liker's 14 lean principles were used--a few of which are:– Principle 3: Use 'pull' systems to avoid

overproduction.– Principle 5: Build a culture of stopping to fix

problems, to get quality right the first time.– Principle 7: Use visual controls so no problems are

hidden.

9

Reliability of Data Collected

• Underlying work did not change.• But, different management approach used: – Focus on most valuable feature (from customer

viewpoint) – Keep each software unit as small as possible

• This allowed the team to focus on the Minimum Marketable Features (MMFs) which delivers maximum value as quickly as possible.

10

Composition of Team

• Same team members.• Same project manager.• Data collected encompasses all team

members--not just high performers.• All types of work incorporated into the

dataset.

11

Digital Hub Team: Office Layout and Work Flow

12

Digital Hub Team: Office Layout and Work Flow

• Clearer idea of their capacity and current WIP.• Deliverables are pulled when team has

capacity to work on them.• Problems become quickly evident because of

visual nature of bottlenecks.

13

Digital Hub Team: Daily Standup

• Vital for operation of the lean system.• 15 minutes every morning.

14

Digital Hub Team: Daily Standup

• First, everyone verifies work status.• Second, blockages are reported.• Third, bottlenecks are identified.• Fourth, work is reviewed to see if priorities

have changed or if work flow can be improved.

15

Digital Hub Team: Daily Standup

Types of blockages:– Slow or poor-quality delivery from a customer or

supplier.– Unable to obtain passwords or technical data for a

needed system.

16

Results: Lead Time

17

Results: Development Time

18

Results: Continuous Improvement Per Month

19

Analysis: Digital Hub's ThoughtsGreater value because:– Only the work of highest value to customers was

being processed.– This work was being delivered and deployed

quickly so delivering value sooner.– The risk of waste by working on misunderstood or

incorrect requirements was minimized.– Customers were reported to be happier and prefer

this approach.

20

Analysis: Work Cycle• Cycle time was improved the daily standup and by

minimizing size of software units.• The drop in variance of development time allowed

clients and developers to evaluate the product produced more quickly therefore reducing both technical and market risks.

• A short work cycle made it "easy to identify problems, define improvement opportunities, and implement improved processes" (29).

21

Analysis: Daily Standup• "The social value of the daily standup also cannot be

underestimated. The requirement to daily share the progress of your work with your peers was a powerful motivator and source of discipline" (29).

• At the same time, "focus on the progress of the work, rather than the performance of individuals, fueled continuous improvement" (29).

22

Analysis: Agile Versus LeanA. Push Verses Pull– Deadlines were avoided, as they can lead to game playing

and poor quality.

B. Reliance On Data– "In the lean approach adopted, data was seen primarily as

a source of empowerment for the team, not as a control tool for management" (30).

23

Analysis: Agile Versus LeanC. Continuous Improvement

– Lead time is used as a quantitative and objective measure of how efficient the software process was performed.

D. Multiskilling/Collaboration– "[B]ecause of the WIP limits and the visibility due to the kanban

boards, the staff could not 'cherry pick' what they would like to work on if they were blocked. They all had to help with the bottlenecks and items blocking the work" (30).

24

Analysis: Other Thoughts• "Lean is not a substitute for professional software engineering

practice. Effective tools for source control, bug tracking, testing, release, and deployment were all critical enablers of the lean software process" (29, 30).

• "The tension with the existing standards and processes is why lean is about culture change rather than simply implementing tools" (29).

• "Lean does not work well with targets, milestones, Gantt charts, and traffic light reporting methods" (29).

25

Conclusion

• The hypothesis of this case study that "application of lean ideas would improve the capability of a software development process" (22) is both quantitatively and qualitatively supported by the results of the study.

• All the members of Digital Hub reported their skills had improved over the observation period.

• "The significance of this work is showing that the use of lean methods including visual management, team-based problem solving, smaller batch sizes, and statistical process control can improve software development" (20).