Becoming Lean
-
Upload
corecom-consulting -
Category
Technology
-
view
37 -
download
1
Transcript of Becoming Lean
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
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
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