1. A Lean|Agile Learning Journey for Nokia S30/40 Managers
Module 2: Lean Software Development
(Rev )

2. Things Change
“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.”
-- Taiichi Ohno, Toyota Production System.
(the father of lean)

3. Practices Must Change Too
Inertia is the residue of past innovation efforts. Left unmanaged it consumes the resources required to fund next-generation innovation.
-- Geoffrey Moore
Dealing with Darwin

4. Development Practices Pillar 2: Continuous Improvement
The Goal: Value
Sustainable shortest lead time. Best quality and value (to people and society). Most customer delight, lowest cost, high morale, safety.
Lean Thinking House
Pillar 1: Respect for People
don’t trouble your customer
develop people-then build products
no wasteful work
teams and individuals evolve their own practices and improvements
build partners with stable relationships, trust and coaching lean thinking
develop teams
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
Pillar 2: Continuous Improvement
Go See
kaizen
spread knowledge
small, relentless,
retrospectives
5 whys
eyes for waste variability, overburden, NVA, (handoff, WIP, info scatter delay, multitasking, defects, wishful thinking…)
perfection challenge
Work to flow (smaller batch sizes, low cycle time)
Flow
Pull
Foundation: Management Support
Management applies and teaches lean thinking, and bases decisions on this long-term philosophy
Derived from: Toyota Production System (2004)
Larman and Vodde (2009)
Adapted by Leffingwell, LLC. (2009)

5. Applicability to Software Development
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

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
Focus on customer requirements as they move through the system, not the people and organizations who manage them
Minimize delays, handoffs and non-value added activities

7. Pillar 1: Respect for People
Don’t Trouble Your Customer
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
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
Teams & Individuals Evolve Their Own Practices & Improvements
Build Partners
Form long-term relationships based on trust
Help partners improve and stay profitable
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
Source: Larman and Vodde, 2009

8. 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.  
Source: The Toyota Way, 2004

9. 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
Kaizen Mind – your job is to do your job and to improve your job. Improve endlessly.
Source: Larman and Vodde, 2009

10. Principle: Flow - Implement Continuous, One Piece Flow
Source: Corey Ladas
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 projects

11. Principle: Use Pull Systems
The more inventory a company has, the less likely they are to have what they need.
--Taiichi Ohno
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
A simple, WIP-limited Kanban board
-- Corey Ladis

12. Exercise: Batch Size, Flow & Pull
Scrum Team Training
Exercise: Batch Size, Flow & Pull
Batch push system
1. CREATE A 4-PERSON PROCESS
2. 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
© 2008 Trail Ridge Consulting, LLC

13. Exercise: Batch Size, Flow and Pull
Scrum Team Training
Exercise: Batch Size, Flow and Pull
Small lot pull system
1. SAME 4-PERSON PROCESS
2. EACH PERSON FLIPS EACH PENNIES AND RECORDS RESULT
3. PASS EACH PENNY AS FLIPPED
4. TIME FROM START TO FIRST PENNY AND ALL PENNIES END
© 2008 Trail Ridge Consulting, LLC

14. Exercise: Rework Push Pull
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?
Bad penny discovered
Unprocessed
Processed
Push
Bad penny discovered
Pull 1 2 3 4

15. Development Practices Example: Scrum
Meeting: Iteration planning
Meeting:
Daily Scrum
Code, build, test cycle
Meeting: Iteration Demo
* Everything is time boxed *
Note: Other Lean/Agile development practices include XP, OpenUP, DSDM, FDD, Kanban

16. The Roots of Scrum Scrum The New, New Product Development Game
Scrum Team Training
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
© 2008 Trail Ridge Consulting, LLC

17. 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.
Adjust
Process
Input
Output
Measure

18. 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

19. Three Roles in Scrum Team Product Owner Scrum Master
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
Scrum Master
Run team meetings, enforce scrum
Remove impediments
Attend integration scrum meetings
Protect the team from outside influence
Scrum Master
Team
Create user stories from product backlog
Commit to iteration plan
Define/Build/Test/Deliver stories (fully accepted)
Team

20. 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
The New, New Product Development Game, Toyota
Harvard Business Review, 1986
(the Roots of Scrum)

21. Scrum in the House of Lean
The Goal: Value
Build and deploy software rapidly in small releases.
Single backlog.
Scrum in the House of Lean
Pillar 1: Respect for People
constant customer feedback
empowered, self organizing teams
single backlog
teams and individuals evolve their own practices and improvements
respect for the individual
Development Practices
cross-functional
team room + visual mgmt
entrepreneurial chief/product owner
create more knowledge
Lean Principles
Long-term philosophy, flow, pull, level workload, stop and fix, master norms, visual controls, leaders-teachers from within, consensus and action, learning/ reflection/kaizen
Pillar 2: Continuous Improvement
daily feedback
weekly feedback
monthly feedback
sprint retrospectives
small, relentless
perfection challenge
Work to flow (smaller batch sizes, low cycle time)
Foundation: Management Support
Self-managing teams. ScrumMaster mentors.
Derived from: Toyota Production System (2004)
Larman and Vodde (2009)
© Leffingwell, LLC. (2009)

22. Value stream Analysis – A Thinking Tool for analyzing and Optimizing the time from Concept to cash

23. Steps in Value Stream Mapping
Produce “current state” map
Identify all processes, value added times and delays between receipt of customer request and delivery for a typical project
Critique current state
Identify the major sources of delays and handoffs
Map future state
Draw an ideal state
Create and implement action plan
What are the largest sources? What are the easiest sources to improve first?
Measure and improve

24. Of course there is a developer available
Value Stream Map Example 1 - Small, high priority feature change request. Organization A. 5 hours.
Of course there is a developer available
Request
Supervisor
Approve
Tech Lead
Technical Assessment
Assign Developer
Code & Test
To Verification
Verify
To Operations
Deploy
33% Efficiency
Value
Waste
5 min
_____
2 hours
2 min
15 min
1 hour
10 min
3 min
160 min
325 min
Adapted from Poppendieck: Implementing Lean Software Development: Form Concept to Cash

25. Example 2 - Small priority feature change request, Organization B: 6 weeks
Approve & Prioritize
Technical Assessment
Code & Test
Verify & Fix
Deploy
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
2 hours
1 week
3 hr 45min
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

26. Example 3 – Fast track project split into multiple branches: 3 months
Marketing Requests New Feature
Approval
Requirements
Develop
Test QA
Deploy
23-33% Efficiency
123 Hours Value
Hours Total Cycle Time
1 hour
1 week
1 day
2 weeks working together
How much is value?
2-3 months to merge
½ week
Value
Waste
Adapted from Poppendieck: Implementing Lean Software Development: Form Concept to Cash

27. Example 4 – medium-sized project in overloaded department: 21 months
Feature Request
Require-ments
Costing
Impact Analysis
Monthly review Meeting
Detailed Require-ments
Department Review & Approval
Queue 4 Years work 2X
25% 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.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
Assign Develop-ment Team
Code
Test
Wait for Release (every 6 months)
Show to Users
Change to what they really want
Deploy
Integrate Re-Test and Fix
2 months + 3X (1week fix)
Takes 6 months total
14.5 months
1 week
Average 3 months
17.5 months
1 day
20 months
2 weeks work
20.5 months
21 months
Takes 2 months
8.5 months
8 weeks total
19.5 months 3X

28. Exercise – Value Stream Mapping
Gather the right stakeholders and spend an hour to draw a map - and a half hour to discuss what you’ve learned
Later - Take a half day to gather any missing data, and involve any other key stakeholders
Take two more hours to draw the map and an hour to discuss implications
Envision the future state
Create an action plan for addressing the biggest waste (delays)
Adapted from Poppendieck: Implementing Lean Software Development: Form Concept to Cash

29. Suggested Readings Primary Other
Implementing Lean Software Development: From Concept to Cash. Poppendieck, Mary and Tom. Addison-Wesley. 2007
Other
The Toyota Way. Liker, Jeffrey. McGraw-Hill
Lean Primer. Larman, Craig and Bas Vodde.

30. Systems, applications, products Components and Features
The Agile Enterprise Big Picture
For discussion, see
Portfolio
Portfolio Vision
Epic 1
Epic 2
Epics span releases
Investment Themes
Epic Backlog
Portfolio Managers
Architectural Runway
Epic 3
Epic 4
Architecture
evolves continuously
Program
Roadmap
Systems, applications, products
©2009 Leffingwell, LLC.
Release Planning
Release Planning
Vision
Product Managers
Release theme and objectives
Release (Feature) Backlog
System Team
Feature 1
Feature 3
Iteration Backlog
Release Increment
Release Increment
Features fit in releases
Arch 1
Backlog Constraints (NFRs)
Release Planning
Release Planning
Release Mgt Team
Feature 2
Feature 4 (
Project
Components and Features
Iteration Backlog
Product Owner
Stories
Stories fit in iterations
(Implemented by) Tasks H H
Agile
Master
Plan
Demo
Agile Teams
(3-10 typical)
Iteration Backlog
Stories
Spikes are research, design, refactor Stories H H
Plan
Demo
NFRs
Iterations
Iterations