Becoming Lean

17
Becoming Lean Remo Biagioni June 2015

Transcript of Becoming Lean

Becoming Lean

Remo BiagioniJune 2015

Offshore Fog

• Operating expenses have doubled in 15 years

• A fifth of the increase is because of increased activity

• Poor planning wastes the time of highly paid staff

• Reliability is awful• Use of bespoke parts rather than

standard• Repeatedly predicted falling costs as

they have soared

2

3

Japanese Clarity

• The answer – pushed for by the British Government – is to copy lean production techniques

• Aera Energy in California treats well drilling as a manufacturing process – managed by a single team from design to implementation• Just in time planning• Cut waste• Decentralised decision making• Standardisation• Visual communication tools

The Economist, pg. 62, May 30th 2015

A new role

• Core issues• Productivity• Stakeholder

Engagement• Predictability of

Delivery

• Motivate & Engage

4

5

Sharpen The Bullet

• Focus on quality• QAT & UAT => Test Driven Development• Peer Reviews• Shared deliverables

• Fixed term iterations• Continuous Deployment• Measuring Output• Iteration planning and review

6

Xanpan

• Allan Kelly’s adaption of XP and Kanban• Idea is to move away from projects • Strong correlation between maintained

projects and downloads on Source Forge

• Establish the team• Feed the team with work• Prioritise development for the team• Not a project … a production line

7

Getting Started

Requirements Change• Moved from a waiting – doing – done whiteboard to a more explicit process

• Focus on quality• Different process for reports and ETL• Two types of backlog

• Prioritised – ready to go• Holding area

• Just in time• Detailed requirements• Planning• Design

• Work In Progress (WIP) limits

• Requirements change at an average of 2% each month

• Over 12 months this is a change of 26.8%

Capers Jones, The Economics of Software Development

8

David J Anderson’s Kanban Recipe

1. Focus on quality2. Reduce work in progress3. Deliver often4. Balance demand against throughput5. Prioritise6. Attack sources of variability to improve predictability

9

Our process10

Push vs Pull11

Theory Of Constraints

• The argument by reductio ad absurdum is as follows: If there was nothing preventing a system from achieving higher throughput (i.e., more goal units in a unit of time), its throughput would be infinite — which is impossible in a real-life system.

• Only by increasing flow through the constraint can overall throughput be increased.[1]

• Assuming the goal of a system has been articulated and its measurements defined, the steps are:

1. Identify the system's constraint(s).2. Decide how to exploit the system's constraint(s).3. Subordinate everything else to the above decision(s).4. Elevate the system's constraint(s).5. Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not

allow inertia to cause a system's constraint

http://en.wikipedia.org/wiki/Theory_of_constraints, June 2015

12

With a Kanban system most or all of the stations in the workflow have WIP limits. … The local WIP limit … will stop the line quickly, keeping the system from clogging and becoming overloaded

David J Anderson, Kanban

Drum – Buffer - Rope13

Where We Are

• Initial constraint was deployment• Looked at our process and optimised it with the Change Approval Board and

deployment teams

• Next came test• We have one QA resource – his role became one of coordination and guidance• Golden rule is a developers don’t mark their own homework

• Currently• Bottleneck is user story and acceptance criteria• Highlighted a lack of skill creating stories• Symptom is that developers start working on lower priority work because major work

is not ready for development• WIP limit is often broken

14

Prioritisation15

Daily• Remove blocked work• Manage flow

Weekly – as needed• Senior users• Prioritise user stories

within subject areas

Six weeks• Senior stakeholders• Ensure alignment with

business strategy• Agree proportion of time

spent on each subject area• Size and shape of team

Metrics

• Report to the board on function points deployed each month• Function points are standard and objective

• Cycle time for each subject area• How long user stories wait before being elaborated

• Time to deploy• From when elaboration starts to “ready to deploy”• ETL, Reports and Defects reported separately

• Bottlenecks• How longs jobs wait in each queue• Time taken in different parts of the process

16

Conclusions

• Cultural difference• Process and flow• Pull vs Push• WIP• Still no silver bullets

17