• Like
Agile2012 rev4.pptx
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Agile2012 rev4.pptx

  • 371 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
371
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
40
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Scaling Lean|Agile Development Myths and Ideologies Meet the Scaled Agile Framework Dean Leffingwell deanleffingwell@gmail.com DeanLeffingwell.com ScalingSoftwareAgilityblog.com © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 1 Myths and Ideologies1.  Scaling Value: Not everything is a Agile: User Story •  Myths2.  Scaling Team and Timebox: No team •  Ideologies •  Misperceptions is an island •  Legacy Mindsets3.  Scaling Design: Emergent design meets intentional architecture4.  Scaling Portfolio Management: Addressing legacy mindsets5.  Scaling Leadership: Your enterprise can be no leaner than your executives thinking © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 2
  • 2. Context for Scaling Lean and Agile Respect for Product Continuous People Development Improvement Flow © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 3 Lean Goal: Speed, Value, Quality The Goal of Lean: Sustainably shortest lead time •  Best quality and value  All we are doing is looking at the timeline, from the moment the customer gives us an order to the point where we to people and society collect the cash. And we are reducing the time line by reducing the non-value added wastes. •  Most customer delight,   ̶    Taiichi  Ohno   We need to figure out a way to deliver lowest cost, high software so fast that our customers don’t have time to change their minds. morale, safety ̶ Poppendieck  Minimize delays, handoffs and non- value added activities © 2009 - 2012 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 © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 5The Scaled Agile Framework™ The Scaled Agile Framework (“SAFe”) is a proven, publicly-facingframework 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 50-100   Has been scaled to hundreds of teams and thousands of people   Browse the framework at ScaledAgileFramework.com © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 6
  • 4. © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 7#1 Scaling ValueNot Everything is a User Story © 2009 - 2012 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: © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 9User Story Scaling Problems Billions and billions of stories  If a large program requires –  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?  And –  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? © 2009 - 2012 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. © 2009 - 2012 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 belowReinertsen, Principles of Product Development Flow, 2009. © 2009 - 2012 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.) © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 13 “Cover your eyes”…Enterprise Backlog Technical View Constrained by 0..* 0..* 1..* Compliant when passes 0..* Is one of Realized by Realized by Realized by 0, 1 1..* 0,1 1..* 0,1 1..* 1 Is one of Is one of Done when passes 1..* 1 1 Done when passes 1..* 0..*Source: 2011, Leffingwell, D. Agile Software Requirements: LeanRequirements Practices for Teams, Programs, and the Enterprise.© Pearson Education © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 14
  • 8. #2−Scaling Team and TimeboxNo Team is an island © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 15The 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? © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 16
  • 9. Everybody Must Be on the Agile Train What do we integrate here? Planned releaseWaterfall Doesn’t Work Release docs Drop 1 Drop 2 delay MRD PRD SRS Dev to QA to QA Test Test drop 1 drop 2 Ports, certsMixing doesn’t work PSI Actual release Agile Works Better Release docs Iterate Iterate Iterate Iterate Iterate Iterate Ports, certs © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 17 But Cadence Alone is Not Enough Planned system release date …....time spent thinking you are on track……. System Integrate PSI External Release and slip! Release docs Iterate Iterate Iterate Iterate Iterate Iterate Port and certs PSI External Release Release docs Iterate Iterate Iterate Iterate Iterate Iterate Port and certs PSI External Release Release docs Iterate Iterate Iterate Iterate © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 18
  • 10. Synchronize to Assure Delivery Second System First PSI PSI or Release System Iterations Sys 1 Sys 2 Sys 3 Sys 4 Sys 5 Sys 6 Sys 7 Sys 8 External Release Continuous PSI System Integration Team Release docs Iterate Iterate Iterate Iterate Iterate Iterate PSI Ports certs Continuous External Release Dev Teams Integration Release Docs Iterate Iterate Iterate Iterate Iterate Iterate Ports certs Continuous PSI Integration External Release Release Docs Iterate Iterate Iterate Iterate Iterate Iterate Ports certs © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 19 Solution: The Agile Release Train Agile Release Train delivers solutions Organize “agile release trains” wherever you have a number of teams provding continuous value delivery  Align teams to a common mission  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 Features and components Product Owner Team Backlog Stories Stories fit in Demo & Retro Scum/Agile iterations Master Plan Implemented by Tasks Team NFRsAgile Teams Stories Spikes are Team Backlog D B research and Demo & Retro T design Stories Plan NFRs Iterations Iterations Developers & Testers NFRs Iterations Iterations © 2009 - 2012 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 Features and components Product Owner Team Backlog Stories Stories fit in Demo & Retro Scum/Agile iterations Master H H Plan Implemented by Tasks Team NFRsAgile Teams Stories Spikes are Team Backlog D B research and Demo & Retro design Stories T H H Plan Developers & Testers NFRs Iterations Iterations © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 21 Separation of Concerns Scenario A: Release less frequently than cadence Agile Release to Market Process Asynchronous Collaborative Release Release General Availability Key Customer upgrade Firewall Docs and Docs and Customer preview certs certs Possible New product PSI1 PSI 3 PSI PSI 5 7/1/2011 10/1/2011 1/1/2011 4/1/2011 7/1/2011 Agile Development Train Process © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 22
  • 12. Release Whenever You Like Scenario B: Release on cadence Scenario C: Release more frequently than cadence © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 23What Is a Release Train, Really? A Fractal. One sprint (2 weeks) Product Plan Owner Execute Scum/Agile Master Commit Team One PSI (8-10 weeks) Execute Team5-10 teams © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 24
  • 13. What is a PSI, Really? A strategic quantum of value and timebox Value Timebox   Accumulates small   Makes planning increments into routine; lowers newsworthy value planning transaction   Releasable, or costs released, or not,   Limits deviation from announced or not plan to a single   Value that can be interval planned, measured   Suitable for internal and assessed with roadmapping and strategic feedback external commitments © 2009 - 2012 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 Shared Roadmap   Build/supports development Program Backlog Vision Release Planning System Feature infrastructure Team Backlog Product TeamManagement Release   Full system integration NonfunctionalManagement NFRs Requirement NFRs and end to end testing Product Owner   Integration with third party Team Backlog Stories components Stories Demo & Retro Plan Scum/Agile Master NFRs   Program demosAgile Teams Stories   Interface to deployment Team Backlog D B Demo & Retro T Plan Developers & Testers NFRs Iterations © 2009 - 2012 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 30 Plan Feature 10 20 PLAN Actual - if within 15% " Automatically ACTUAL Feature 9 26 28 Actual - if >15% behind compiled from 33 number of stories Feature 8 30 completed/stories Feature 7 20 40 remaining in agile 62 project Feature 6 60 management 40 Feature 5 30 tooling Feature 4 20 40 " Facilitates Feature 3 40 decisions of what 45 changes might be 30 Feature 2 50 necessary to Feature 1 70 80 successfully 0 10 20 30 40 50 60 70 80 90 100 deliver the PSI Percent Complete © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 27 Scaling Improvement: Inspect and Adapt Program-level Root Cause Analysis/ Improvement Story Workshop. Every PSI I&ARelease Planning PSI | Release   Establish accountability   Create new stories   Specify measurable results   Set achievable deadlines   Monitor progress © 2009 - 2012 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 intentionalarchitecture © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 29Intentional 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 © 2009 - 2012 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. •  UI framework for porting existing –  Common infrastructure; •  apps to mobile devices Industry security standard to lower avoid duplication of effort data purchasing costs •  Support 64 bit back office servers © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 31Intentional ArchitectureV0.81 © 2009 - 2012 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 © 2009 - 2012 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 © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 34
  • 18. Architectural Epic Kanban System Problem/Solu8on  Needs   Evalua8on   Implementa8on   Iden8fica8on   Architecture  Team  Ownership   Development  Team  Ownership   1.  Funnel   2.  Backlog   3.Analysis   4.  Implementa,on     Technology  roadmap     Refine     Design  alterna8ves     Ownership  transi8ons     Disrup8ve  technology   understanding     Modeling   System Tech lead/   Teams  begin  implemen8ng  at   Architect Design architect   Solu8on  problem:  compa8bility     Est.  cost  of  delay     Development     Spike release  planning  boundaries   speed,  size,  security,  usability,     Refine  effort  est.   collabora8on     Teams  break  epics  into     Solu8on/product  management   features     Common  infrastructure/duplicate     Rela8ve  ranking   collabora8on   investment     Architect  support    on  “pull”     Business  case   basis   Innova,on  feedback   WIP   Release   Limit   planning   boundary   WIP   Limit   PSI  1   PSI  2   PSI  3   PSI  4   WIP   Limit   Agile  Release  Trains  Ac8vi8es:       Authority   Architect  Team  Pulls   Product/    Effort  size  es8mate   approves  epic   Epic   Technology     PSI  1   PSI  2   PSI  3   PSI  4    Value  size    es8mate     Meets     Lead  architect     Council      Investment  theme   threshold   assigned   criteria   Approval   alignment   WIP   Limit   © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 35 Portfolio Vision #4−Scaling Portfolio Management Addressing legacy mindsets © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 36
  • 19. The Problem with Legacy Mindsets Changing Legacy Mindsets: “Control through “widget engineering” “Maximize utilization” milestones/data” From: “order taker mentality” “Get it done” “plan out a full year of projects” Time boxing Control through Epic based portfolio empirical release To: planning WIP Limits increments Intense development Fix resources short Rolling wave release collaboration term only planningBaker and Thomas, Establishing an Agile Portfolio to Align IT Investments with Business Needs. DTE Energy Case Study, Agile, 2009 © 2009 - 2012 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 Decentralized Rolling-Wave Planning Planning #5 Work Breakdown Agile Estimating and Planning Structure #6 Projects Agile Release Trains #7 PMBOK Agile Project Management #8 Waterfall Milestones Fact-Based Governance Legacy PPMO Agile PPMO © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 38
  • 20. A Portfolio Kanban System 1. Funnel 2. Backlog 3.Analysis 4. Implementation   Product roadmap   Refine   Solution alternatives   Ownership transitions   New business opportunity understanding   Collaboration   Teams begin implementing at   Est. cost of delay -  Solution management release planning boundaries   Cost savings   Refine effort est. -  Architects   Teams break epics into features   Solution problem -  Market/sales/business   Relative ranking   Analyst support on “pull” basis -  Development   Weighted rank   Business case Innovation feedback WIP Release Limit planning boundary WIP Limit PSI 1 PSI 2 PSI 3 PSI 4 WIP Limit Agile Release Trains Activities: Authority Business analyst Portfolio   Effort size estimate approves epic pulls Epic Management PSI 1 PSI 2 PSI 3 PSI 4   Value size estimate   Meets   Lead analyst Team/   Investment theme threshold assigned alignment criteria Product WIP Council Limit Approval © 2009 - 2012 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 •  Agile estimating and planning•  Fact-based assessment •  Agile Release Trains•  Agile milestones •  Agile Project Management © 2009 - 2012 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 © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 41 Managing Budgets and Investment ThemesProgram   Porolio  LLevel   Porolio   evel   Portfolio Vision Portfolio Backlog Investment     Themes   Architectural Runway Budgets   Program  Level   Agile  Release  Trains  (con8nuous  flow  programs)   Requirements   Requirements   Design   Program   Design   Implementa,on   Implementa,on   Verifica,on   Verifica,on   Waterfall  programs   © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 42
  • 22. #5−Scaling LeadershipYour enterprise can be no leanerthan your executives thinking © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 43The 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 © 2009 - 2012 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) Reinertsen (2009) Larman and Vodde (2009) © 2009 - 2012 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 improvementSource: Larman and Vodde, 2009 © 2009 - 2012 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 © 2009 - 2012 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. 2011  SAFe Certification: Chicago. October 23-27, 2012. (see ScaledAgileAcademy.com)  Blog: ScalingSoftwareAgilityBlog.com  Framework: ScaledAgileFramework.com  Website: see DeanLeffingwell.com © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 48