Tips & Tricks
Like this document? Why not share!
Webinar On Scaled Agile Framework (...
by Saket Bansal
Email sent successfully!
Show related SlideShares at end
, Software Engineer
Oct 07, 2012
Comment goes here.
12 hours ago
Are you sure you want to
Your message goes here
Be the first to comment
Be the first to like this
Number of Embeds
No notes for slide
1. Scaling Lean|Agile Development Myths and Ideologies Meet the Scaled Agile Framework Dean Leffingwell firstname.lastname@example.org 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
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
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
© 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
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
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
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
#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
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
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
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
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
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
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
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
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
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
Architectural Epic Kanban System Problem/Solu8on Needs Evalua8on Implementa8on Iden8ﬁca8on Architecture Team Ownership Development Team Ownership 1. Funnel 2. Backlog 3.Analysis 4. Implementa,on Technology roadmap Reﬁne 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, Reﬁne eﬀort 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/ Eﬀort 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
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
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
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 ﬂow programs) Requirements Requirements Design Program Design Implementa,on Implementa,on Veriﬁca,on Veriﬁca,on Waterfall programs © 2009 - 2012 Leffingwell, LLC. and Scaled Agile, Inc. 42
#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
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
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
Email sent successfully..