Scaling Lean Agile Development

Transcription

1 Scaling Lean Agile Development Myths and Ideologies Meet the Scaled Agile Framework Dean Leffingwell DeanLeffingwell.com ScalingSoftwareAgilityblog.com Leffingwell, LLC. and Scaled Agile, Inc. 1 Myths and Ideologies 1. Scaling Value: Not everything is a User Story 2. Scaling Team and Timebox: No team is an island Agile: Myths Ideologies Misperceptions Legacy Mindsets 3. Scaling Design: Emergent design meets intentional architecture 4. Scaling Portfolio Management: Addressing legacy mindsets 5. Scaling Leadership: Your enterprise can be no leaner than your executives thinking Leffingwell, LLC. and Scaled Agile, Inc. 2

2 Context for Scaling Lean and Agile Respect for People Product Development Flow Continuous Improvement Leffingwell, LLC. and Scaled Agile, Inc. 3 Lean Goal: Speed, Value, Quality 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 Minimize delays, handoffs and nonvalue added activities The Goal of Lean: Sustainably shortest lead time Best quality and value to people and society Most customer delight, lowest cost, high morale, safety Leffingwell, LLC. and Scaled Agile, Inc. 4

3 Lean Goal: Speed, Value, Quality Take an economic view Actively manage queues Understand and exploit variability Reduce batch sizes Apply WIP constraints Control flow under uncertainty: cadence and synchronization Get feedback as fast as possible Decentralize control Leffingwell, LLC. and Scaled Agile, Inc. 5 The Scaled Agile Framework The Scaled Agile Framework ( SAFe ) is a proven, publicly-facing framework for applying Lean and Agile practices at enterprise scale More on SAFe: Synchronizes the vision, planning, interdependencies, and delivery of many teams Web version available to public since February 2012 Works well for teams of Has been scaled to hundreds of teams and thousands of people Browse the framework at ScaledAgileFramework.com Leffingwell, LLC. and Scaled Agile, Inc. 6

4 Leffingwell, LLC. and Scaled Agile, Inc. 7 #1 Scaling Value Not Everything is a User Story Leffingwell, LLC. and Scaled Agile, Inc. 8

5 Agile Teams Know User Stories A great invention, User Stories replace traditional requirements expression The Team Backlog consists primarily of the user stories that express the needs of the stakeholders User stories are negotiable, expressions of intent Expressed in user-voice form: Leffingwell, LLC. and Scaled Agile, Inc. 9 User Story Scaling Problems If a large program requires And Billions and billions of stories 10 teams that plan two PSIs at a time, about 10 weeks apart If each team averages 10 stories per two week iteration, then 1,000 stories must be elaborated How can an enterprise reason about 1,000 things? (On just the one program!) And if we are about half done (500 stories), what do we actually have working, and how would we describe that to our customer? Even if I know 500 things that as a <role> I can <activity> so that <business value>, can do What Features does the system offer and what Benefits does each provide? What is the larger purpose here? Leffingwell, LLC. and Scaled Agile, Inc. 10

6 Features Fill the Program Backlog A Feature is a service that fulfills a user need The term Feature is an industry-standard term familiar to Marketing and Product Management. Features are identified, prioritized, estimated, and maintained in the Program Backlog. Features can be expressed as a short phrase describing the feature, along with its benefits Leffingwell, LLC. and Scaled Agile, Inc. 11 Actively Manage Backlogs (Queues) Backlogs are a form of queue (If items are committed, then it is a queue) The longer the queue, the slower the delivery (Little s Law) Operating at high levels of utilization increases variability For fast, and predictable results: Keep the backlogs short and uncommitted Limit WIP to keep planned utilizations at 80% or below Reinertsen, Principles of Product Development Flow, Leffingwell, LLC. and Scaled Agile, Inc. 12

7 Epics and the Portfolio Backlog Epics describe large-scale development initiatives which are the highest level expression of a business or technology need Business Epics are customer-facing solutions Architecture Epics are technology solutions which enable the business needs, improve operational efficiencies, or drive innovation Epics are identified, prioritized, estimated, and maintained in the Portfolio Backlog Work-in-progress limits are set to minimize the number of unfinished Epics at any given time. They are managed through a Kanban system. Epics often cut across teams, releases, programs, and systems Epics can be expressed in any form to communicate the intent of the initiative (a business case, prototype, etc.) Leffingwell, LLC. and Scaled Agile, Inc. 13 Cover your eyes Enterprise Backlog Technical View Constrained by 0..* 0..* Is one of Compliant when passes 1..* 0..* Realized by 0, 1 1..* Realized by Realized by 0,1 1..* 0,1 1..* 1 Is one of 1..* Done when passes Is one of 1 1 Done when passes 1..* 0..* Source: 2011, Leffingwell, D. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Pearson Education Leffingwell, LLC. and Scaled Agile, Inc. 14

8 #2 Scaling Team and Timebox No Team is an island Leffingwell, LLC. and Scaled Agile, Inc. 15 The Problem with Pockets of Agility There is more value created with overall alignment than with local excellence. Don Reinertsen. The Agile, Twelve Tribes of Israel Problem: Tis far better to have agile teams than non-agile teams, BUT How do we know what they are doing? How do we know how well they are performing? How do we manage interdependencies? How do we know if they are working to a common mission? How do we know we are getting the benefits for the enterprise? How can we harness all that new found energy and entropy? Leffingwell, LLC. and Scaled Agile, Inc. 16

9 Everybody Must Be on the Agile Train What do we integrate here? Planned release Waterfall Doesn t Work MRD PRD SRS Dev Drop 1 to QA Drop 2 to QA Release docs delay Test drop 1 Test drop 2 Mixing doesn t work Ports, certs Agile Works Better Iterate Iterate Iterate PSI Iterate Iterate Iterate Actual release Release docs Ports, certs Leffingwell, LLC. and Scaled Agile, Inc. 17 But Cadence Alone is Not Enough...time spent thinking you are on track. System PSI External Release Release docs Planned system release date Integrate and slip! Iterate Iterate Iterate Iterate Iterate Iterate Port and certs PSI External Release Release docs Iterate Iterate Iterate Iterate Iterate Iterate PSI Port and certs Release docs External Release Iterate Iterate Iterate Iterate Leffingwell, LLC. and Scaled Agile, Inc. 18

10 Synchronize to Assure Delivery First PSI Second System PSI or Release System Iterations Sys 1 Sys 2 Sys 3 Sys 4 Sys 5 Sys 6 Sys 7 Sys 8 System Team Continuous Integration PSI Release docs External Release Iterate Iterate Iterate Iterate Iterate Iterate Dev Teams Continuous Integration PSI Ports certs Release Docs External Release Iterate Iterate Iterate Iterate Iterate Iterate Ports certs Continuous Integration PSI Release Docs External Release Iterate Iterate Iterate Iterate Iterate Iterate Ports certs Leffingwell, LLC. and Scaled Agile, Inc. 19 Solution: The Agile Release Train Organize agile release trains wherever you have a number of teams provding continuous value delivery Align teams to a common mission Agile Release Train delivers solutions Standardize iteration lengths; normalize estimating units Use cadence and synchronization to manage R&D variability A fractal above the agile team. Same shape; similar behavior; different parameters Agile Teams Developers & Testers Product Owner Scum/Agile Master D B T Team Backlog Team Backlog Features and components Stories NFRs Stories Plan Plan Demo & Retro Demo & Retro NFRs Iterations Iterations NFRs Iterations Iterations Stories fit in iterations Implemented by Tasks Spikes are research and design Stories Team Leffingwell, LLC. and Scaled Agile, Inc. 20

11 The Agile Release Train Organized around enterprise value streams Create self-planning, self-organizing, self-managing agile programs Self-manages interdependencies amongst teams Full, system-level solutions available every 8-10 weeks Agile Teams Developers & Testers Product Owner Scum/Agile Master D B T Team Backlog Team Backlog NFRs NFRs Features and components Stories Stories Plan Demo & Retro Plan Demo & Retro Iterations H H Iterations H H Stories fit in iterations Implemented by Tasks Spikes are research and design Stories Team Leffingwell, LLC. and Scaled Agile, Inc. 21 Separation of Concerns Scenario A: Release less frequently than cadence Agile Release to Market Process Asynchronous Release Collaborative Key Customer upgrade Release General Availability Firewall Customer preview PSI1 Docs and certs PSI 3 Docs and certs PSI PSI 5 Possible New product 7/1/ /1/2011 1/1/2011 4/1/2011 7/1/2011 Agile Development Train Process Leffingwell, LLC. and Scaled Agile, Inc. 22

12 Release Whenever You Like Scenario B: Release on cadence Scenario C: Release more frequently than cadence Leffingwell, LLC. and Scaled Agile, Inc. 23 What Is a Release Train, Really? A Fractal. One sprint (2 weeks) Team Product Owner Scum/Agile Master Plan Commit Execute One PSI (8-10 weeks) Team 5-10 teams Execute Leffingwell, LLC. and Scaled Agile, Inc. 24

13 What is a PSI, Really? A strategic quantum of value and timebox Value Accumulates small increments into newsworthy value Releasable, or released, or not, announced or not Value that can be planned, measured and assessed with strategic feedback Timebox Makes planning routine; lowers planning transaction costs Limits deviation from plan to a single interval Suitable for internal roadmapping and external commitments Leffingwell, LLC. and Scaled Agile, Inc. 25 Scaling Fast Feedback with a System Team The System Team brings system assets together early and often, allowing fast feedback with objective evaluation Roadmap Vision Product Management Release Management Agile Teams Program Backlog Developers & Testers NFRs Shared Release Planning System Team Nonfunctional Requirement Product Owner Scum/Agile Master D B T Team Backlog Team Backlog Team Backlog NFRs NFRs NFRs Feature Stories Stories Stories Plan Demo & Retro Plan Demo & Retro Iterations Build/supports development infrastructure Full system integration and end to end testing Integration with third party components Program demos Interface to deployment Leffingwell, LLC. and Scaled Agile, Inc. 26

14 Scaling Tracking: Features, Not Just Stories Understand completeness of each feature compared to plan at any point in time Feature Plan PLAN Actual - if within 15% Feature 9 ACTUAL 28 Actual - if >15% behind 26 Feature Feature Feature Feature Feature Feature Feature Feature Percent Complete 100 " Automatically compiled from number of stories completed/stories remaining in agile project management tooling " Facilitates decisions of what changes might be necessary to successfully deliver the PSI Leffingwell, LLC. and Scaled Agile, Inc. 27 Scaling Improvement: Inspect and Adapt Program-level Root Cause Analysis/ Improvement Story Workshop. Every PSI I&A PSI Release Establish accountability Create new stories Specify measurable results Set achievable deadlines Monitor progress Leffingwell, LLC. and Scaled Agile, Inc. 28

15 Some things that simply emerge, may turn out to be very ugly creatures indeed #3 Scaling Design: Emergent design meets intentional architecture Leffingwell, LLC. and Scaled Agile, Inc. 29 Intentional Architecture For systems of scale, some intentional Architecture is necessary Excessive redesign and refactoring of big systems drives bad economics and slows time-to-market Drives rework for large numbers of teams Potential impact on deployed systems/users Some use cases can and should be anticipated Plus: Many drivers for system and enterprise architectures arise outside the purview of individual agile programs Mergers and acquisitions New, cross-cutting user patterns Common architectural constructs for usability, extensibility, performance and maintenance Leffingwell, LLC. and Scaled Agile, Inc. 30

16 Change, Challenge and Opportunity Drive Architecture Epics Large technology initiatives, that cut across: Time affecting multiple releases Scope affecting multiple products, systems, services, or solutions Organizations affecting multiple teams, programs, business units Where do they come from? New product or service opportunities. Mergers/acquisitions Changes in technologies Problems within the existing solution set, cost. Architectural governance: usability, extensibility, performance, etc. Common infrastructure; avoid duplication of effort UI framework for porting existing apps to mobile devices Industry security standard to lower data purchasing costs Support 64 bit back office servers Leffingwell, LLC. and Scaled Agile, Inc. 31 Intentional Architecture V Leffingwell, LLC. and Scaled Agile, Inc. 32

17 Principles of Agile Architecture Principle # 1 The teams that code the system design the system Principle # 2 Build the simplest architecture that can possibly work Principle # 3 When in doubt, code it (or model it) out Principle # 4 They build it, they test it Principle # 5 The bigger the system, the longer the runway Principle # 6 System architecture is a role collaboration Principle # 7 There is no monopoly on innovation Principle # 8 Implement architectural flow Leffingwell, LLC. and Scaled Agile, Inc. 33 # 8 Implement Architectural Flow Provide an agile framework for system architects. They must be agile, too. Drive incrementalism in architectural refactoring Make architectural work in process visible Establish WIP limits to control queue sizes, avoid overload and assure product development flow Drive an effective collaboration with the development teams Leffingwell, LLC. and Scaled Agile, Inc. 34

18 Architectural Epic Kanban System Problem/Solu8on Needs Iden8fica8on Evalua8on Architecture Team Ownership Implementa8on Development Team Ownership 1. Funnel Technology roadmap Disrup8ve technology Solu8on problem: compa8bility speed, size, security, usability, Common infrastructure/duplicate investment 2. Backlog Refine understanding Est. cost of delay Refine effort est. Rela8ve ranking 3.Analysis Design alterna8ves Modeling System Architect Development collabora8on Solu8on/product management collabora8on Business case Design Spike Tech lead/ architect 4. Implementa,on Ownership transi8ons Teams begin implemen8ng at release planning boundaries Teams break epics into features Architect support on pull basis WIP Limit WIP Limit Innova,on feedback Release planning boundary PSI 1 PSI 2 PSI 3 PSI 4 WIP Limit Ac8vi8es: Effort size es8mate Value size es8mate Investment theme alignment Authority approves epic Meets threshold criteria Architect Team Pulls Epic Lead architect assigned Product/ Technology Council Approval Agile Release Trains PSI 1 PSI 2 PSI 3 PSI 4 WIP Limit Leffingwell, LLC. and Scaled Agile, Inc. 35 Portfolio Vision #4 Scaling Portfolio Management Addressing legacy mindsets Leffingwell, LLC. and Scaled Agile, Inc. 36

19 The Problem with Legacy Mindsets Changing Legacy Mindsets: From: widget engineering order taker mentality Maximize utilization Get it done Control through milestones/data plan out a full year of projects To: Epic based portfolio planning Intense development collaboration Time boxing WIP Limits Fix resources short term only Control through empirical release increments Rolling wave release planning Baker and Thomas, Establishing an Agile Portfolio to Align IT Investments with Business Needs. DTE Energy Case Study, Agile, Leffingwell, LLC. and Scaled Agile, Inc. 37 Eight Transformational Patterns We need a transformation roadmap, one that builds an Agile PPMO on Lean-Agile Principles Legacy Mindset Lean-Agile Pattern #1 Too Many Projects Limiting WIP with Kanban #2 Detailed Project Plans Lightweight Business Cases #3 Annual Funding Incremental Funding #4 Centralized Annual Planning #5 Work Breakdown Structure Decentralized Rolling-Wave Planning Agile Estimating and Planning #6 Projects Agile Release Trains #7 PMBOK Agile Project Management #8 Waterfall Milestones Fact-Based Governance Legacy PPMO Agile PPMO Leffingwell, LLC. and Scaled Agile, Inc. 38

20 A Portfolio Kanban System 1. Funnel Product roadmap New business opportunity Cost savings Solution problem 2. Backlog Refine understanding Est. cost of delay Refine effort est. Relative ranking 3.Analysis Solution alternatives Collaboration - Solution management - Architects - Market/sales/business - Development Weighted rank Business case 4. Implementation Ownership transitions Teams begin implementing at release planning boundaries Teams break epics into features Analyst support on pull basis WIP Limit WIP Limit Innovation feedback Release planning boundary PSI 1 PSI 2 PSI 3 PSI 4 WIP Limit Activities: Effort size estimate Value size estimate Investment theme alignment Authority approves epic Meets threshold criteria Business analyst pulls Epic Lead analyst assigned Portfolio Management Team/ Product Council Approval Agile Release Trains PSI 1 PSI 2 PSI 3 PSI 4 WIP Limit Leffingwell, LLC. and Scaled Agile, Inc. 39 The Agile PPMO The Agile PPMO enables and fosters lean and agile practices for business results Limiting Work in Process Lightweight business cases Incremental funding Decentralized rolling wave planning Fact-based assessment Agile milestones Agile estimating and planning Agile Release Trains Agile Project Management Leffingwell, LLC. and Scaled Agile, Inc. 40

21 Investment Themes Investment Themes represent the budget allocations within a portfolio to systems, products, applications, and services Can be at the enterprise or business unit level Done as part of the budgeting process with a lifespan of 6-12 months Governed by a Portfolio Management Team Not managed as a backlog in priority order. Rather, investment themes are managed as a percentage of available resources. Not testable ROI is not measured at this level Leffingwell, LLC. and Scaled Agile, Inc. 41 Managing Budgets and Investment Themes Program Investment Themes Budgets Program Level Por\olio Level Portfolio Backlog Portfolio Vision Architectural Runway Agile Release Trains (con8nuous flow programs) Requirements Requirements Design Design Implementa,on Implementa,on Verifica,on Verifica,on Program Waterfall programs Leffingwell, LLC. and Scaled Agile, Inc. 42

22 #5 Scaling Leadership Your enterprise can be no leaner than your executives thinking Leffingwell, LLC. and Scaled Agile, Inc. 43 The Problem: Let s Get Real Managers, directors, and executives are not chickens in the enterprise. They are pigs. (And really big ones at that.) To be successful, our expectation must not be that they: a) simply don t interfere, or b) simply understand, or c) are even simply supportive Instead, they must LEAD. After all, that s what leaders do Our job Inform, Educate, and Inspire them to their new Lean Agile leadership mission Leffingwell, LLC. and Scaled Agile, Inc. 44

23 Lean Thinking Foundation Product Development Flow 1. Take an economic view 2. Actively manage queues 3. Understand/exploit variability 4. Reduce batch size 5. Apply WIP Constraints 6. Flow with uncertainty Cadence and Synchronization 7. Apply fast feedback 8. Decentralize control Derived from: Toyota Production System (2004) Larman and Vodde (2009) Reinertsen (2009) Leffingwell, LLC. and Scaled Agile, Inc. 45 Lean-thinking Manager-teachers Management is trained in lean thinking - bases decisions on this long term philosophy Management understands and teaches lean and agile behaviors Management is trained in the practices and tools of continuous improvement Source: Larman and Vodde, Leffingwell, LLC. and Scaled Agile, Inc. 46

24 Your Job: Inform, Educate, Inspire Inform Make sure the agile working group executes an effective communication plan Educate Management Suggested Readings Principles of Product Development Flow. Reinertsen Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise. Leffingwell. Lean Software Development: An Agile Toolkit. Poppendieck. Have them attend a lean leadership workshop you hold Inspire Expect and challenge them to lead, not follow Leffingwell, LLC. and Scaled Agile, Inc. 47 Questions? Book: Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley SAFe Certification: Chicago. October 23-27, (see ScaledAgileAcademy.com) Blog: ScalingSoftwareAgilityBlog.com Framework: ScaledAgileFramework.com Website: see DeanLeffingwell.com Leffingwell, LLC. and Scaled Agile, Inc. 48