1. © 2009 Leffingwell, LLC. Appropriate graphic goes here A Lean|Agile Learning Journey for Nokia S30/40 Managers Module 6: Implementing the Agile Release Train (Rev 1 22.9.09) 1

2. © 2009 Leffingwell, LLC. Appropriate graphic goes here The Agile Release Train: A software development operating mode for accelerating value delivery

3. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here What Drives the Agile Release Train?  Fixed vs. variable parameters  Two levels of planning and tracking  Smaller and more frequent releases  Principles of the Agile Release Train 3

4. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Fixed: Cost, Quality, Schedule 4 Variable: Scope

5. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here What Paradigms Are We Breaking? 5

6. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Two-Level Agile Planning and Tracking “There have been countless ambitious but doomed attempts to plan large software projects from start to finish in minute detail, as you would plan the construction of a skyscraper.... In an iterative process, development is based on two kinds of plans. – A coarse-grained plan: the phase (release) plan – A series of fine-grained plans: the iteration plans So, in agile methods, the investment in long-range, speculative plans is reduced, and the lack of precision and accuracy in such plans is acknowledged. Release plans, therefore, are intentionally coarse- grained, less comprehensive, and less precise” Kruchten, 2004 6

7. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Two Level Planning and Tracking Iteration Cycle Drives Feedback - Adjust Product & Release Cycle Release Vision Release Planning Release Scope and Boundaries 7 Iteration Planning Develop & Test Review & Adapt

8. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Two Levels of Planning  Plan Releases at the System Level – Three to six months planning horizon – Release theme sets overall objective – Prioritized feature sets define proposed/estimated content – High visibility and confidence near term (Release “next” and “next+1”). Lower visibility longer term  Plan Iterations at the component/module/feature Level – 4-6 weeks planning horizon – Define story cards and tasks for next 1-2 iterations – Adapt and adjust at each iteration 8

9. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Iteration Pattern Story A Story B Story C Story D Story E Story F Story … Story A Story B Story C Story D Story E Story F Story … 9

10. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Release Pattern Stories Release timebox 10

11. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Smaller, More Frequent Releases  Shorter release dates – 60-120 days  Releases defined by – Date, theme, planned feature set, quality  Scope is the variable – Release date and quality are fixed 11 We have to figure out a way to deliver software so fast that our customers won’t have time to change their minds. ─Poppendiecks - Implementing Lean Software Development

12. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Benefits  Rapid customer feedback reduces waste  Earlier value delivery against customer’s highest needs  Frequent, forced system integration improves quality and lowers risk  Low cost to change – Accepts new, important customer features  Reprioritize backlog at every iteration & release – Reduced patching headaches  “It’s only X days the next release, that feature can wait”  Or easy, high-confidence patching  Smaller increments for higher productivity – Leaner flow through the entire organization to customer 12

13. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Fix the Dates - Float the Features  Teams learn that dates MATTER  Product owners learn that priorities MATTER  Agile teams MEET their commitments 10/1/200711/1/200712/1/2006 1/1/2008 2/1/2008 3/1/2008 3/25/20089/24/2007 13 “ “Time pressures will drive extreme use of simultaneous engineering” -- The New, New Product Development Game, Toyota Harvard Business Review, 1986

14. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Managing Large-Scale Development Requires Intense Cooperation  Scaling agile requires managing interdependencies amongst distributed agile teams  This requires coordinated planning and synchronized development activities  Teams themselves must understand and manage their dependencies  This is facilitated by an “agile release train” delivery model 14

15. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Principles of the Agile Release Train  Release dates for the solution are fixed  Intermediate, global integration milestones are established and enforced  Constraining these means that component functionality must flex  Teams evolve to a flexible model: – Design spectrum for new functionality – Backup plan to ship the existing assets if necessary 15 Lease Imaginable Minimum Credible ModerateBest

16. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Hardening Iterations  The iteration goal is to have tested and accepted software at the end of every iteration – But automation of testing may lag by one or more iterations  Over time: – the set of accumulated functional test cases – + system level and performance test cases serve as full regression tests for iteration and release  The release goal is to execute a full suite of release level acceptance testing, full regression and system and performance testing in less than one iteration  Often, a typical release pattern develops 16

17. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Synchronize to Assure Delivery 17 What do we integrate here??

18. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Even Team Agile isn't System Agile 18 Time when you discover you are not …....time spent thinking you are on track……. The slowest component drags the train

19. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Answer: Synchronized Release Train 19 S H I P ! System level testing and CI points Assure PSI Second PSI

20. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here With Separation of Concerns

21. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Release Train Systems Engineering Benefits  Continuous, Objective Status – Status (working code) and quality measures at iteration and release boundaries  Availability – Forces availability of Potentially Shippable Increment at least at (internal) release cadence  Quality – Continuous integration at each iteration boundary – Platform for concurrent system level feature/epic testing – Forces holistic, feature maturity at release boundaries – Hardening iterations provide “guard band” for full validation and reduction of technical debt 21

22. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Release Planning -The “Pacemaker” of the Agile Enterprise  A full day or two for every release (every 90 days typical)  Most everyone attends in person if at all possible  Product Manager owns the feature priorities  The team builds the plan from the vision  Development team owns story planning and high-level estimates  Adequate logistics and facilitation – Big room with lots of whiteboard space – Break-out rooms for multiple teams.  Architects work as intermediaries for technical governance, interfaces and dependencies 22 A visible, tangible, and practical best practice, based on the actual physics of agile software development

23. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here The Planning Calendar Can be Set a Year in Advance 2008-9 Release and Iteration Schedule Release Planning dates in Red

24. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here  State of the business  Objectives for upcoming periods  Objectives for release  Prioritized feature set  Each team presents plans to group  Issues/impediments noted  Scope discussed  Teams plan stories for iterations  Work out dependencies  Architects and PMs, POs circulate |1 |2 |3 |4 architects Product managers/ Product Owners PMs Executives Agenda for Day 1 24  Architecture initiatives, security, performance reqs  Infrastructure and process Initiatives Arch, eng mgrs

25. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Agenda for Day 2  Objectives for release  Prioritized feature set  All Issues/impediments assigned  Release commitment vote  What did we learn?  Update Product Roadmap 25 Dev teams Eng mgrs Eng mgrs/PMs Product Managers |1 |2 |3 |4

26. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Result - the “Commitment” 26 “Let’s not succumb to the myth that planning is the same thing as making a commitment. We should plan thoughtfully and commit sparingly.” --Poppendieck. Implementing Lean Software Development After dependencies were resolved and risks were addressed, individuals voted on their confidence level for hitting our release goals. 1 = extremely skeptical, 5 = complete buy-in.

27. Copyright © 2009 Leffingwell, LLC. All rights reserved. Appropriate graphic goes here Update the Release Roadmap 27 Mar 15, ‘09 May 22, ’09 July ‘09 A themed, and prioritized “plan of intent”- high visibility and high confidence commitment for next release, less visibility thereafter

28. H HH H For discussion, see www.scalingsoftwareagility.wordpress.comwww.scalingsoftwareagility.wordpress.com ©2009 Leffingwell, LLC.

29. Appropriate graphic goes here Exercise: Agile Release Train 29 1. What are the largest challenges you see in implementing the Agile Release Train? 2. What recommendations do you have for addressing the biggest one you identified?

30. Suggested Readings Primary – Scaling Software Agility: Best Practices for Large Enterprises. Leffingwell, Dean. Addison-Wesley. 2009. Other 30