© 2009 Leffingwell, LLC. Appropriate graphic goes here A Lean|Agile Learning Journey for Nokia...
-
Upload
dwain-shields -
Category
Documents
-
view
216 -
download
0
Transcript of © 2009 Leffingwell, LLC. Appropriate graphic goes here A Lean|Agile Learning Journey for Nokia...
© 2009 Leffingwell, LLC.
Appropriate graphic
goes hereA Lean|Agile Learning Journey for Nokia S30/40
Managers
Module 2: Lean Software Development
(Rev 2 22.9.09)
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Things Change
2
-- Taiichi Ohno, Toyota Production System. (the father of lean)
“Plans change very easily. Worldly affairs do not always go according to a plan and orders have to change rapidly in response to a change in circumstances. If one sticks to the idea that once set, a plan should not be changed, a business cannot exist for long.”
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Practices Must Change Too
3
-- Geoffrey MooreDealing with Darwin
Inertia is the residue of past innovation efforts. Left unmanaged it consumes the resources required to fund next-generation innovation.
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Lean Thinking House
4
Development Practices long-term great engineers mentoring mgr-eng-
teacher cadence cross-functional team room + visual mgmt entrepreneurial
chief/product manager set based concurrent dev. create more knowledge
14 Lean Principles
Long-term philosophy, master norms, visual controls, tested tech, leaders-teachers from within, develop exceptional people, help partners be lean, go see, consensus and action, learning/ reflection/kaizen
Derived from: Toyota Production System (2004)Larman and Vodde (2009) Adapted by Leffingwell, LLC. (2009)
Flow Pull
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
5
Lean Principles Applicability to Software Development
Focus on value Focus on value delivery to the customer or end user. Understand and
optimize the entire value chain
Reduced work in process and inventory
Reduced investment in too-early requirements and documentation Minimize work in process Minimize multiplexing amongst projects and tasks Increase delivery throughput Reduced process overhead, compliance checks Last Responsible Moment decision making
Reduced cycle times Deliver solutions in smaller lots (tasks, user stories, use cases) Smaller and more frequent releases put working solutions in the hands of
customers more quickly
Cell-based teamwork, empowerment, responsibility and accountability
Self-organizing, self-managing software teams Increase cross-training with pairing and shared knowledge and assets Collocate all team members to extent practical Entire team commits to delivering iterations and releases
Build quality in
Teams are responsible for quality All work (solution increments) is tested work Apply test automation wherever possible
Continuous process improvement
Teams responsible for continually improving their performance with regular reflection and adaption
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
6
The Goal: Sustainably Deliver Value Fast
“All we are doing is looking at the timeline, from the moment the customer gives us an order to the point where we collect the cash. And we are reducing the time line by reducing the non-value added wastes.” -- Taiichi Ohno
“We need to figure out a way to deliver software so fast that our customers don’t have time to change their minds.” --Poppendieck
“Focus on the baton, not the runners”. -- Larman and Vodde
1) Focus on customer requirements as they move through the system, not the people and organizations who manage them
2) Minimize delays, handoffs and non-value added activities
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Managers are teachers, not directors
Mentor people closely for years, in engineering and problem solving
Teach people to analyze root causes and make problems visible; they discover how to improve
Managers understand and act on the goal of "eliminating waste" and "continuous improvement" in their own actions and decisions -employees see this
Pillar 1: Respect for People
7
Don’t Trouble Your Customer
Teams & Individuals Evolve Their Own Practices & Improvements
Develop People, then Build products
Your customer is anyone who consumes your work or decisions
Relentlessly analyze and change to stop troubling them
Don't force people to do wasteful work Don't give them defects Don't make them wait Don't impose wishful thinking on them Don't overload them
Build Partners
Management challenges people to change and may ask what to improve, but ...
Workers learn problem solving and reflection skills and then decide how to improve
Form long-term relationships based on trust
Help partners improve and stay profitable
Source: Larman and Vodde, 2009
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Pillar 2: Continuous Improvement
Principle 11. Respect your extended network of partners.
– Treat your partners as an extension of your business.
– Challenge them to grow and develop.
– Set challenging targets and assist your partners in achieving them.
Principle 12. Go and See to thoroughly understand the situation
– Solve problems and improve processes by going to the source and personally observing and verifying data
Principle 13. Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly
– Do not go down one path until you have thoroughly considered alternatives. When you have picked, move quickly but cautiously down the path.
Principle 14. Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen).
– Once you have established a process, use continuous improvement tools to determine the root cause of inefficiencies and apply effective countermeasures.
– Protect the organizational knowledge base by developing stable personnel, slow promotion, and careful succession systems.
– REFLECT (hansei) at key milestones and after you finish a project to openly identify all the shortcomings of the project.
8Source: The Toyota Way, 2004
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Foundation: Lean-Thinking Manager-Teachers
Management is trained in lean thinking - bases decisions on this long term philosophy
Management is trained in the practices and tools of continuous improvement (kaizen)
– Applies them routinely … teaches employees how to use them
Go See - managers are expected to “go see with their own eyes”
– “You can’t come up with a useful improvement sitting at your desk”
– “Go see what’s happening in the workplace”
– “Don’t look with your eyes, look with your feet….people who only look at the numbers are the worst of all” -- quotes from Toyota Lean leaders
9
Kaizen Mind – your job is to do your job and to improve your job. Improve endlessly.
Source: Larman and Vodde, 2009
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Principle: Flow - Implement Continuous, One Piece Flow
Minimize waste
– Overproduction, inventory, work in process, handoffs
Provide incremental value delivery
Brings problems to the surface
– Stop the line if quality issues surface
– Defect mindset – find (now) – fix (now) - forget
– Match capacity to demand
– Level the workload
– Efficiency and productivity
– No projects10
Source: Corey Ladas
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
11
Principle: Use Pull Systems
Build in response to a signal (kanban) from the customer A downstream team is the customer of an upstream team Small batches increase throughput Work naturally matches capacity Delays decisions until the Last
Responsible Moment
The more inventory a company has, the less likely they are to have what they need.
--Taiichi Ohno
A simple, WIP-limited Kanban board-- Corey Ladis
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Exercise: Batch Size, Flow & Pull
12
1. CREATE A 4-PERSON PROCESS2. EACH PERSON FLIPS ALL
PENNIES ONE AT A TIME AND RECORDS RESULTS
3. PASS ALL PENNIES AT ONCE TO THE NEXT PERSON
4. RECORD TIME FROM START TO END
Batch push system
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Exercise: Batch Size, Flow and Pull
13
Small lot pull system
1. SAME 4-PERSON PROCESS2. EACH PERSON FLIPS EACH PENNIES
AND RECORDS RESULT3. PASS EACH PENNY AS FLIPPED4. TIME FROM START TO FIRST PENNY
AND ALL PENNIES END
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here• A defect is discovered on the third penny at station 4.
• It requires 10 sec. of rework at station 3• How much rework is required in push vs. pull?
Processed
Unprocessed
1 2 3 4
Bad penny discovered
Bad penny discovered
Push
Pull
Exercise: Rework
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Development Practices Example: Scrum
* Everything is time boxed *
Code, build, test cycle
Meeting:Iteration planning
Meeting:Daily Scrum
Meeting: Iteration Demo
15
Note: Other Lean/Agile development practices include XP, OpenUP, DSDM, FDD, Kanban
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
The Roots of Scrum
The New, New Product Development
Game(Toyota-Harvard
Business Review 1987)
Lean and the Toyota
Way
Iterative, Incremental
Development, Time-boxes
Smalltalk Engineering Tools
Scrum
16
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Scrum – Guiding Principle
If a process is unpredictable or too complicated for the planned, (predictive) approach, then the empirical approach (measure and adapt) is the method of choice.
ProcessInput Output
Measure
Adjust
17
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Scrum Philosophy
Based, in part, on Toyota’s product development Process– Concurrent Engineering
– The New, New Product Development Game
Based on empirical process control Harnesses the power (Ba) of the team Lightweight process, just 3 roles
18
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Three Roles in Scrum
Product Owner Assure team is pursuing a common vision Establish priorities to track business value Act as ‘the customer’ for developer questions Work with product management to plan releases Accept user stories and iteration
Scrum Master Run team meetings, enforce scrum Remove impediments Attend integration scrum meetings Protect the team from outside influence
Team Create user stories from product backlog Commit to iteration plan Define/Build/Test/Deliver stories (fully accepted)
SCRUM
Product Owner
Scrum MasterTeam
19
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
The Power of “ba”
The energy that drives a self-organizing team Dynamic interaction of individuals and organization creates synthesis in the form of
a self-organizing team
The fuel of ba is its self-organizing nature a shared context in which individuals can interact
Team members create new points of view and resolve contradictions through dialogue
New knowledge as a stream of meaning emerges
This emergent knowledge codifies into working software
Ba must be energized with its own intentions, vision, interest, or mission to be directed effectively
Leaders provide autonomy, creative chaos, redundancy, requisite variety, love, care, trust, and commitment
Creative chaos can be created by implementing demanding performance goals. The team is challenged to question every norm of development
Time pressures will drive extreme use of simultaneous engineering
Equal access to information at all levels is critical
20
The New, New Product Development Game, ToyotaHarvard Business Review, 1986 (the Roots of Scrum)
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Scrum in the House of Lean
21
Development Practices cross-functional team room + visual mgmt entrepreneurial
chief/product owner create more knowledge
Lean PrinciplesLong-term philosophy, flow, pull, level workload, stop and fix, master norms, visual controls, leaders-teachers from within, consensus and action, learning/ reflection/kaizen
Derived from: Toyota Production System (2004)Larman and Vodde (2009) © Leffingwell, LLC. (2009)
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
VALUE STREAM ANALYSIS – A THINKING TOOL FOR ANALYZING AND OPTIMIZING THE TIME FROM CONCEPT TO CASH
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Steps in Value Stream Mapping
1. Produce “current state” map
– Identify all processes, value added times and delays between receipt of customer request and delivery for a typical project
2. Critique current state
– Identify the major sources of delays and handoffs
3. Map future state
– Draw an ideal state
4. Create and implement action plan
– What are the largest sources? What are the easiest sources to improve first?
5. Measure and improve23
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Value Stream Map Example 1 - Small, high priority feature change request. Organization A.
5 hours.
24
E-mail Supervisor
E-mail Tech Lead
Assign Developer
To Verification
To Operations
Of course there is a developer available
Value
Waste
5 min _____
2 hours
2 min _____
2 hours
15 min _____
1 hour
2 hours _____
15 min
15 min _____
10 min
3 min 160 min
325 min
33% Efficiency
Adapted from Poppendieck:Implementing Lean Software Development: Form Concept to Cash. 2007.
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Example 2 - Small priority feature change request, Organization B: 6 weeks
25
Form Sent to Queue
Form Sent to Queue
Form Sent to Queue
To Verification
To Operations
Biweekly releases means a wait of an average of 1 week
for verification
Value
Waste
5 min
15 min
_____
½ week
2 min _____
2 weeks
15 min _____
2 weeks
2 hours _____
1 week
15 min
3 hr 45min
_____
½ week
3 min 2 hours 40 min
6 weeks + 4 hrs
1% Efficiency
Wait an average of 2 weeks for
developers
Wait an average of 2 weeks for an
architect
Weekly review of requests means an
average wait of ½ week
20 Min Total
4 Hours Total
Extra 15 minutes to fill out request form
Only 15 minutes of 4 hours should be needed to verify
Adapted from Poppendieck:Implementing Lean Software Development: Form Concept to Cash. 2007.
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Example 3 – Fast track project split into multiple branches: 3 months
26
23-33% Efficiency
123 Hours Value
500-660 Hours Total Cycle Time
1 hour
1 week
1 hour
1 day
2 weeks working together
1 week
How much is value?
2-3 months to merge
½ week
1 hour
Adapted from Poppendieck:Implementing Lean Software Development: Form Concept to Cash. 2007.
Value
Waste
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Example 4 – medium-sized project in overloaded department:21 months
27
Queue 4 Years work
2X25% of these requirements are dropped during analysis
50% of these requirements eventually change
Value
Total Time
1 week work
1 month total
Cumulative Time 1 month
1 day work
1 week total
1.25 months
1 hour work
1 week total
1.5 months
3X (5min work)
2½ months total
4 months
8 weeks work
16 weeks total
6 months
5 min work
2 weeks wait
6.5 months
2 months + 3X (1week fix)
Takes 6 months total
14.5 months
1 week
Average 3 months
17.5 months
1 day
2 weeks wait
20 months
2 weeks work
20.5 months
1 hour work
2 weeks wait
21 months
5 min work
Takes 2 months
8.5 months
8 weeks total
19.5 months
3X
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Exercise – Value Stream Mapping
28
1) Gather the right stakeholders and spend an hour to draw a map - and a half hour to discuss what you’ve learned
2) Later - Take a half day to gather any missing data, and involve any other key stakeholders
3) Take two more hours to draw the map and an hour to discuss implications
4) Envision the future state5) Create an action plan for addressing the
biggest waste (delays)
Adapted from Poppendieck:Implementing Lean Software Development: Form Concept to Cash. 2007.
© 2009 Leffingwell, LLC.
Appropriate graphic
goes here
Suggested Readings
Primary
– Implementing Lean Software Development: From Concept to Cash. Poppendieck, Mary and Tom. Addison-Wesley. 2007
Other
– The Toyota Way. Liker, Jeffrey. McGraw-Hill. 2004.
– Lean Primer. Larman, Craig and Bas Vodde. www.leanprimer.org
29
Proj
ect
Portf
olio
Prog
ram
Rel
ease
(F
eatu
re)
Bac
klog
Re
lea
se
In
cre
me
nt
Product Owner
Ite
rati
on
B
ack
log
Ite
rati
on
Bac
klo
g
Stories fit in iterations
(Implemented by) Tasks
Features fit in
releases
Epics span
releases
Iterations Iterations
Release theme and objectives
Architectureevolves
continuously
Spikes are research, design, refactor Stories
Systems, applications, products
The Agile Enterprise Big Picture
Agile Teams(3-10 typical)
Architectural Runway
Epic 3
Epic 4
Portfolio Vision
H
HH
H
Stories
Components and Features
AgileMaster
Rel
ea
se P
lan
nin
g
Rel
ea
se P
lan
nin
g
Pla
n
Dem
o
Feature 3
Feature 4
System TeamIt
era
tio
n
Bac
klo
g
Release Planning
Feature 2
Feature 1
Epic 1
Epic 2
Pla
n
Dem
o
For discussion, see www.scalingsoftwareagility.wordpress.com
Backlog Constraints
(NFRs)(
NFRs
Epi
c B
ackl
og
Stories
RoadmapVision
Arch 1
©2009 Leffingwell, LLC.
Re
lea
se
In
cre
me
nt
Investment Themes
Release Planning