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

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)

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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)

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

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

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 E-mail Supervisor Approve E-mail 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. 2007.

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

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 500-660 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. 2007.

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

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

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. 2004. Lean Primer. Larman, Craig and Bas Vodde. www.leanprimer.org

Systems, applications, products Components and Features The Agile Enterprise Big Picture For discussion, see www.scalingsoftwareagility.wordpress.com 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