The Scaled Agile Framework: Applying Lean-Agile to the Enterprise (presented at Agile Knowledge Hub webinar series)

The Scaled Agile Framework: Applying Lean-Agile to the Enterprise Presented November 22nd, 2011 Drew Jemilo Agile Knowledge Hub webinar series Fast Frontier, Inc. Twitter: #AgileKnowledgeHub drew@fastfrontier.com http://fastfrontier.com Sponsored by© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission.

Agenda The Scaled Agile Framework Vision Common Problems Scaling Agile Agile Practices at Scale Overview of the Scaled Agile Framework Scaling the Team Scaling the Backlog Scaling the Iteration Questions© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 2

Reaching Agile at Scale Team-based Agile methods have matured, but applying Agile at scale is still in its infancy ?© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 4

The Need for the Scaled Agile Framework The Scaled Agile Framework fills a vital gap in the industry. Position Statement FOR software developers, practitioners, managers, executives, coaches, consultants, trainers, and agile working group team members WHO are involved in planning and implementing Agile software development philosophies, principles, and practices at enterprise scale The Scaled Agile Framework (SAF) is a proven, publicly available framework for applying Lean-Agile practices at enterprise scale, presented in a structured and interactive web format. UNLIKE proprietary methods promoted by product and consulting firms, or practices described in dozens of books SAF is a synthesized, holistic, integrated, and summarized framework available to everyone in a readily accessible public-facing web site, including supporting resources© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 5

The Need for the Scaled Agile Framework Purpose Roadmap Through collaboration, the Scaled PSI 2.1 (Dec 21st, 2011) Agile Framework (SAF) will:  Soft Launch (Beta) 1. Enhance the competitiveness,  Release sufficient content productivity, and delivered to have a meaningful software quality of the software offering industry worldwide 2. Provide the business benefits of software agility to all PSI 2.2 (Feb 21st, 2012) software enterprises  Have all base content 3. Increase motivation,  Release to the general empowerment, and humanity to public software development  Gather feedback for PSI practitioners everywhere 3 release planning 4. To build good business value along the way!© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 6

Find Out More Find out more at www.ScaledAgileFramework.com and sign up for email notifications© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 7

Team-Level Agile At the team level, Agile is a proven process Daily Scrum  Task 1  Task 2  Task 3 2  ... week Sprint iteration Sprint Backlog Sprint Sprint Planning Meeting of tasks : Review Meeting Retro- spective  Verify that...  Verify that... Working  Verify that... increment Backlog ofThe Team of software requirements Acceptance Criteria The Sprint © 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission.

But.. What happens when a large number of teams must synchronize to plan and deliver a larger, valuable increment of software? Technical Teams Backlogs Iterations Practices : : : : .... : : : :© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 10

Problems Scaling the Teams At scale, Agile teams are distributed and cannot be self-sufficient Problems Scaling the Teams  Teams are often highly distributed  Communication via conversation and direct interaction breaks down  Teams are not self-sufficient. External teams are needed to prioritize, define, manage, and deliver larger systems  Team practices can vary widely, making it difficult to integrate and scale  System architecture matters at scale . .  User experience must be governed at . scale© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 11

Problems Scaling the Backlog The backlog at scale must provide alignment at multiple levels Problems Scaling the Backlog  Team-level backlog items become unmanageable (thousands of items).  Hard to gain alignment – Are we building the right Stories for the wrong product?!  Stories are small and independent. What end to end experience will our users encounter?  No clear decision-making process or governance structure. Who makes what decisions at what level (portfolio, . . program, team)? .© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 12

Problems Scaling the Iteration The iteration at scale must be synchronized across all internal and external teams involved in a release Problems Scaling the Iteration  Managing dependencies, risks, and issues is more complex.  If one team misses its date, it can have significant cascading effects. ...  Longer time-boxes (> 2 - 4 weeks) are ... usually needed to define, build, and test larger systems. ... . . . . . . . . .© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 13

Achieving Enterprise Agility Dean Leffingwell articulated seven Agile team practices that natively scale and seven enterprise practices which must be added1 Team Practices that Scale: Enterprise Practices: 1. The Define/Build/Test 1. Intentional Architecture Team 2. Lean Requirements at Scale 2. Mastering the Iteration 3. The Agile Release Train 3. Two-levels of Planning 4. Managing Distributed and Tracking Development 4. Smaller, More Frequent 5. Agile Portfolio Management Releases 6. Managing Organizational 5. Concurrent Testing Change 6. Continuous Integration 7. Measuring Business 7. Regular Reflection and Performance Adaptation1Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprise. Boston, MA: Addison-Wesley, 2007.© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 15

The Scaled Agile Framework (SAF) The Scaled Agile Framework is a proven framework for applying Lean and Agile practices at enterprise scale More on SAF:  Synchronizes the vision, planning, interdependencies, and delivery of many teams  Created by Dean Leffingwell - further developed with industry scaling experts  Proven to scale to hundreds of teams and thousands of people  Web version available to public in February 2012  For more info, see ScaledAgileFramework.comSee also www.scalingsoftwareagility.wordpress.com andLeffingwell, D. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Addison-Wesley (Pub. 2011)© 2008- 2011, Fast Frontier, Inc. All rights reserved. DoAll rights reserved. Dowithout written permission. permission.© 2007- 2011, Fast Frontier, Inc. and Leffingwell, LLC. not copy or distribute not copy or distribute without 17

The Portfolio Management Team The Portfolio Management Team has responsibility for Strategy and Investment Funding, Program Management and Governance. Portfolio Level Portfolio Management Team  Strategy and Investment funding: Allocates budget from Investment Themes; prioritizes business and architecture Epics  Program Management: Helping keep programs on track.  Governance and Oversight: Agile Lifecycle milestones; release governance, management reporting.  Typically facilitated by Agile Portfolio and Program Management Office (APPMO)© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 20

The Product Management Team The Product Management Team has solution content authority and drives the implementation activities of the Product Owners Program Level Product Management Team  Responsible for the vision and end-to-end solution  Strategic in nature. Owns program vision, roadmap, and ROI.  Responsibilities include not just software content, but positioning, messaging, pricing and licensing, release governance, etc.  Oversees Product Owners, who are responsible for the implementation© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 21

The Release Management Team The Release Management Team provides the governance and support to release the solution Program Level Release Management Team  Provides governance for when and how the product is delivered to the end user  May consist of senior line-of-business managers, senior product managers, system architects, senior QA personnel, production deployment resources, etc.  Usually meets weekly to maintain alignment between the vision and execution, address impediments, and adjust scope to meet release dates  Known by other names (e.g., Steering Committee)© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 22

The System Team The System Team provides program-level capabilities to fully integrate, test, and deploy a full solution Program Level System Team  Has capabilities to integrate, test, and deploy a full solution  Enables capabilities for system-level continuous integration and other development infrastructure  Can fully test system-level end to end use cases and non-functional requirements  May be multiple teams - often known by other names (e.g., System Integration, QA and Deployment, Release Team, etc.)© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 23

Scrum has a generic “Product Backlog,” but for enterprise scaling, we need multiple levels of planning.© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 25

The Enterprise Backlog Model • The Enterprise Backlog Model translates the allocation of strategic investments to the portfolio, program, and team levels • Remember: Detail is defined just-in- time and progressively elaborated!© 2008- 2011, Fast Frontier, Inc. All rights reserved. DoAll rights reserved. Dowithout written permission. permission.© 2007- 2011, Fast Frontier, Inc. and Leffingwell, LLC. not copy or distribute not copy or distribute without 26

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. Managed by a Portfolio Management Team Not managed as a backlog in priority order. rather managed as a percentage of available resources (class of service). “Testable” by tracking actual time to planned investment© 2008- 2011, Fast Frontier, Inc. All rights reserved. DoAll rights reserved. Dowithout written permission. permission.© 2007- 2011, Fast Frontier, Inc. and Leffingwell, LLC. not copy or distribute not copy or distribute without 27

Program Vision and Roadmap The Vision communicates the strategic intent of the program and the Roadmap guides the delivery of Features The Program Vision  May be done through traditional forms like a Vision Documents, Advanced Data Sheet, etc.  Rolling Wave Vision Briefings are becoming more common. They are routine presentations of the short and longer-term solution goals The Roadmap  Consists of a series of prioritized Features and planned release dates  Commitment is made only to the next release.  Subsequent releases are “best estimates” due to the likelihood of changes in customer needs and the impact on development© 2008- 2011, Fast Frontier, Inc. All rights reserved. DoAll rights reserved. Dowithout written permission. permission.© 2007- 2011, Fast Frontier, Inc. and Leffingwell, LLC. not copy or distribute not copy or distribute without 28

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 systems, programs, releases, and teams  Epics can be expressed in any form to communicate the intent of the initiative (a business case, prototype, etc.)© 2008- 2011, Fast Frontier, Inc. All rights reserved. DoAll rights reserved. Dowithout written permission. permission.© 2007- 2011, Fast Frontier, Inc. and Leffingwell, LLC. not copy or distribute not copy or distribute without 29

Features and the Program Backlog A Feature is a clear statement of functionality which fulfills the need stated in an Epic The term “Feature” is an industry-standard term familiar to Marketing and Product Management to define and communicate functionality. Features can be expressed as a statement or in User Story form. In addition to the value provided to the end user, they should also state the value to the business. Features are identified, prioritized, estimated, and maintained in the Program Backlog. Architecture Features fulfill the needs of Architecture Epics, similar to how Business Features fulfill the needs of Business Epics.© 2008- 2011, Fast Frontier, Inc. All rights reserved. DoAll rights reserved. Dowithout written permission. permission.© 2007- 2011, Fast Frontier, Inc. and Leffingwell, LLC. not copy or distribute not copy or distribute without 30

Stories and the Team Backlog Though the Team Backlog consists mostly of User Stories, it contains other work items as well The Team Backlog consists of the simplest artifacts to express the needs of the stakeholders In addition to customer-facing User Stories, it contains technical work such as bug fixes, enhancements, research spikes, maintenance, and refactors As a… I can… so that… We saw details of the User Story earlier in this presentation© 2008- 2011, Fast Frontier, Inc. All rights reserved. DoAll rights reserved. Dowithout written permission. permission.© 2007- 2011, Fast Frontier, Inc. and Leffingwell, LLC. not copy or distribute not copy or distribute without 31

Non-Functional Requirements (NFRs) Non-Functional Requirements are system qualities which support end user functionality, business objectives, and system goals Typically known as the “ities” – reliability, usability, scalability, maintainability, etc. They always exist and become constraints which are considered before the software is released Program-level NFRs apply to the system as a whole Team-level NFRs apply to a feature or component in a team’s domain. If the need is a transient technical requirements, it can be put on the backlog of architecture/tech Features and Stories (e.g., upgrade the Java Virtual Machine)© 2008- 2011, Fast Frontier, Inc. All rights reserved. DoAll rights reserved. Dowithout written permission. permission.© 2007- 2011, Fast Frontier, Inc. and Leffingwell, LLC. not copy or distribute not copy or distribute without 32

Scaled Agile Framework: Iterations Quarterly PortfolioAdjustments6 – 10 week Releases 2 week Iterations Scaling © 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 34

What is an Agile Release Train (ART)? Set of teams that synchronously put their cargo (fractals of value) on the train Common vision, common mission© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 36

What Is a Release Train, Really? One sprint (2 weeks) Team Plan Execute Commit One PSI (10 weeks)Program:5-10 teams Plan Execute Commit© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 37

Value Streams and ART Trains consist of one or more value streams – Example: Online booking system- train organized around a single value stream Hosted on line booking solution – Example: Image editing suite: Train organized around a suite of products that can be purchased individually or bundled Editing Validation Extraction Trains are optimal at around 60-125 people (8-12 teams) © 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 38

Rules of the Agile Release Train Release (PSI) dates for the solution are fixed Intermediate, global integration milestones are enforced Therefore, component functionality must flex Teams evolve to a flexible model: – Design spectrum for new functionality – Backup plan to ship existing assets if necessary Lease Minimum Moderate Best ─ The New, New Product Development Game Imaginable Credible Harvard Business Review, 1986 © 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 39

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 © 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 40

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 PSISystem Integration Team Release docs Iterate Iterate Iterate Iterate Iterate Iterate PSI Ports certs Continuous External Release DevTeams 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 © 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 41

The Pacemaker: the Release Planning Meeting Two days every 8-12 weeks Everyone attends in person if at all possible Product Management owns feature priorities Development team owns story planning and high-level estimates Architects, UX folks work as intermediaries for governance, interfaces and dependencies Result: A committed set of program objectives for the next PSI © 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 42

Update the Release RoadmapAfter planning, the product managers update the roadmap Mar 15, ‘11 May 22, ’11 July ‘11 Features Features Features  Road Rage Ported  Road Rage Completed  Multiuser Road Rage first (part I)  (single user) release  Brickyard port started  Brickyard Ported (single  Brickyard Ported multiuser (stretch goal to complete) user) demo  Distributed platform demo  Road Rage multiuser  New features for both  ALL GUIs for both games demonstrable games (see prioritized list) demonstrable  First multiuser game  Beemer game to E3  -----Stretch----- feature for Road Rage Tradeshow?  New features (see  -----Stretch----- prioritized list)  New features (see  Demo of Beemer game prioritized list)  Beemer game in Alpha © 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 43

Release Retrospective In depth with Corrective Action (2-3 hrs) When you need it, haul out the big gun – run an Inspect and Adapt Workshop When big problems seem irresolvable, or at critical junctures…..© 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 44

Inspect and Adapt Workshop The Inspect and Adapt Workshop goes into more depth than a typical Retrospective. It utilizes Root Cause Analysis and Corrective Action tools.  Establish accountability  Create new stories  Specify measurable results  Set achievable deadlines  Monitor progressSee the AWG for a Problem Solving Workshop Toolkit and Potential Facilitation © 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 45

Questions?Learn More: Contact me:• http://ScaledAgileFramework.com Drew Jemilo• http://ScalingSoftwareAgility.Wordpress.com Fast Frontier, Inc.• Scaling Software Agility: Best Practices for Large drew@fastfrontier.com Enterprise by Dean Leffingwell. Boston, MA: Addison- Wesley, 2007. http://fastfrontier.com• Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise by Dean Leffingell. Boston, MA: Addison-Wesley, 2011 © 2008- 2011, Fast Frontier, Inc. All rights reserved. Do not copy or distribute without written permission. 46

http://www.scoop.it	621
http://www.scrumdesk.com	93
http://scrum.sk	5
http://paper.li	1
http://webcache.googleusercontent.com	1

The Scaled Agile Framework: Applying Lean-Agile to the Enterprise (presented at Agile Knowledge Hub webinar series)

by Drew Jemilo on Nov 22, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

Embed Views

Statistics

The Scaled Agile Framework: Applying Lean-Agile to the Enterprise (presented at Agile Knowledge Hub webinar series) — Presentation Transcript