10.29.15 sa fe in-8 pictures-with speaker-notes-v3.0.4
•Download as PPTX, PDF•
0 likes•169 views
Wondering what Scaled Agile is? Hearing about SAFe but not sure how to apply it in your companies situation? Come to our SAFe® in 8 Webinar on Thursday October 29, 2015! We will discuss the shared understanding of the overarching approaches and principles at play in SAFe and understand how it allows large organizations to achieve enterprise agility.
Recommended
More Related Content
Viewers also liked
Viewers also liked (12)
Similar to 10.29.15 sa fe in-8 pictures-with speaker-notes-v3.0.4
Similar to 10.29.15 sa fe in-8 pictures-with speaker-notes-v3.0.4 (20)
Recently uploaded
Recently uploaded (20)
10.29.15 sa fe in-8 pictures-with speaker-notes-v3.0.4
- 1. 1Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved SAFe® in 8 Pictures A Walkthrough of the Scaled Agile Framework® www.scaledAgile.com V3.0.4
- 2. 2Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved Important Notice: Please Read Usage Restrictions This material is the property of Scaled Agile, Inc. and is protected by U.S. and International copyright laws. It is provided solely to promote adoption and use of the Scaled Agile Framework® (SAFe®) for the benefit of the enterprises and individuals who apply it. You may reproduce, distribute, and use this material for informational purposes only, and always free of charge. You may not modify any slides, or use anything from the slides to create derivative works, or remove any trademark or copyright notice. You may add slides unique to your specific context, but such content shall not change the meaning, purpose, or intent of the original material.
- 3. 3Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved PROVEN
- 4. 4Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved
- 5. 5Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved THE LEVELS
- 6. 6Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved
- 7. 7Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved THE PEOPLE
- 8. 8Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved
- 9. 9Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved THE BACKLOGS
- 10. 10Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved
- 11. 11Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved THE CADENCE
- 12. 12Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved
- 13. 13Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved CODE QUALITY
- 14. 14Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved
- 15. 15Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved RELENTLESS IMPROVEMENT
- 16. 16Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved
- 17. 17Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved ECONOMIC PRIORITIZATION
- 18. 18Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved
- 19. 19Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved
- 20. 20Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved QUESTIONS?
Editor's Notes
- SPEAKER NOTES: Welcome to SAFe in 8 Pictures. My name is Tonya McCaulley, Director of Training and SPC for ROME Agile. We’re here for an introduction to the Scaled Agile Framework. In today’s webinar, we want to create a shared understanding of the overarching approaches and principles at play in SAFe and understand how it allows large organizations to achieve enterprise agility
- Read slide
- OVERVIEW: With this slide, talk in general about the speed at which SAFe has been adopted, or adapt your voice-over to highlight its adoption in a specific market. See the case studies on the Scaled Agile Framework website. SPEAKER NOTES: SAFe is an online, freely revealed knowledge base of proven, integrated success patterns for implementing Lean-Agile development at enterprise scale. Companies like John Deere, Intel and Telstra have published case studies citing the business benefits. The list is growing every day. You can find those by navigating to ScaledAgileFramework.com and clicking on the “Case Studies” menu. ROME Agile is a Gold Member of the SAFe community, with 5 SPC’s on staff.
- OVERVIEW: In this slide, explain that, at first glance, the Framework may appear complicated. However, I will take them through it in a logical manner. SPEAKER NOTES: This is what is referred to as the “SAFe Big Picture”. At first, it may look complicated, but as we will see, it is actually a very straight-forward and logical representation. We will see that roles, artifacts, and activities are clearly defined based on proven principles and practices. Decomposing the SAFe Big Picture into it’s constituent parts, we’ll discover that it’s a simple, powerful and easily understood framework for managing complex software and systems development.
- OVERVIEW: Introduce the levels of the Framework. The levels of SAFe are built on decentralized decisions because sometimes centralized decisions become a bottleneck. If you leave the decision every day decisions to the people who do the actual work, they will get the job done much faster. SPEAKER NOTES: The levels in SAFe are not structured for control; rather, they are for centralizing strategy and decentralizing execution based on the principles of Product Development Flow
- OVERVIEW: Introduce the Portfolio, Program, and Team levels. Explain that without teams, there are no programs. The people at the Team and Program Levels make up the virtual organization known as the Agile Release Train. It is based on time-proven principles, as represented by the House of Lean. SPEAKER NOTES: Here we see the three levels of SAFe: Portfolio, Program, and Team. The people at the Team and Program Levels make up the virtual organization known as the Agile Release Train. Without teams, there can be no program. You’ll notice the House of Lean in the upper left. It represents the time-proven principles which include respect for people and culture, flow, innovation, and relentless improvement. The goal is value and the foundation is leadership.
- OVERVIEW: Discuss the concept of the knowledge worker. SPEAKER NOTES: In knowledge-based work the people are truly the assets of the organization. It is the people who have the knowledge and skills to define and build a quality system which executes the business strategy.
- SPEAKER NOTES: You’ll see Lean-Agile Leaders next to the House of Lean. These are not specific people filling a specific role. Rather, they represents the leadership required across the organization, as guided by the House of Lean, to support a Lean-Agile enterprise. Let’s now move to the Team level where we have small cross-functional teams that are empowered to make localized decisions to get work done. Each team has a Scrum Master, Product Owner, Developers, Testers, and other needed team roles. The System Team supports the Agile teams by building and maintaining tools for continuous integration, automated testing, and other infrastructure to support development and quality. They also conduct the testing which cannot be done by the individual teams. Business Owners set priorities and negotiate trade-offs. A User Experience engineer and a System Architect at the Program level provide guidance for the teams. The Release Train Engineer facilitates the activities of the Agile Release Train, much like the Scrum Master facilitates the activities of the team. Moving up to the Portfolio level, we have the Program Portfolio Management team responsible for strategy and investment funding, program execution, and governance. They have the highest level fiduciary responsibility in the Framework. An Enterprise Architect provides strategy and architectural guidance for the portfolio. Are there any other roles of interest I didn’t mention?
- SPEAKER NOTES: In Agile, requirements are managed in a construct known as a backlog which is comprised of prioritized functionality and other work to be done, such as architecture, spikes, refactors, and maintenance. Backlog items are elaborated at a level of detail appropriate to the phase of development. They are not commitments. Rather, they represent opportunities.
- SAMPLE SPEAKER NOTES: There are three levels of backlogs which comprise the Enterprise Backlog Model: the Portfolio Backlog which contains Epics, the Program Backlog which contains Features, and the Team Backlog which contains Stories The backlog items that the teams work on align the enterprise strategy and the program vision. Epics are identified, either business or architectural, and are progressively elaborated as they flow through the Portfolio Kanban System. The Kanban System makes the strategic business initiatives visible and brings a structured analysis process driven by economics. Epics are broken down into Features. Prioritization is guided by the Program Vision and Roadmap. We’ll take about prioritization later. Features are then broken down into Stories which are executed by the Agile teams. However, this isn’t a strict hierarchy. A Feature may emerge within the context of the Program and not have a parent Epic. Likewise, a Story may emerge within the content of the Team.
- SPEAKER NOTES: The cadence is the division of time (or timebox) that provides a “heartbeat.” Cadence is critical for synchronizing teams on the Agile Release Train. All teams work on the same cadence (2 week sprints) to synchronize and align.
- SPEAKER NOTES: At the Team Level, the teams work in two week increments called Sprints. They begin each Sprint with detailed planning and end with a demo and a retrospective At the Program Level, the teams on the Agile Release Train works in 8 – 12 week increments, called Programs Increments, or PIs. A PI, begins with a higher level planning event, called Release Planning, and ends with a demo and retrospective known as “Inspect and Adapt.” The teams on the Agile Release Train develop on cadence, but can release on demand based on business needs.
- SPEAKER NOTES: Poor quality doesn’t scale. This speaks to the heart of agility. Many teams give the illusion of “going fast” but if they don’t build in quality, then speed and the ability to adapt to change degrades over time. The result: Agile teams that don’t apply code quality practices end up creating “technical debt” that, sooner or later, will prevent them from completing work. Lack of automation, lack of a testable design, poor attention to design patterns create tangled code. They cease being “agile.”
- OVERVIEW: Here, you can explain code quality in the level of detail required by your audience: The practices (Agile Architecture, continuous integration, and test-first development) Architecture as a first-class citizen, with architecture at the highest level in the form of Architectural Epics Demonstrations of tested code at the Team and Program Levels (Team Demo, System Demo, and PI Demo) Key roles (the Enterprise Architect and System Architect, as well as Release Management, DevOps, and the System Team) The construction of the Architectural Runway by teams under the guidance of the System Architect SPEAKER NOTES: Ron Jeffries, one of the original signatories of the Agile Manifesto has this to say about what he’s learned over the years: “looking back over all of my successful (and not so successful) projects, I’d apply XP (Extreme Programming) techniques to all of them, if I had them to do over”. That’s a strong statement but an important one. However, Extreme Programming isn’t that extreme. It has influenced the code quality practices emphasized in the Framework. SAFe focuses on three Code Quality practices: Agile Architecture, continuous integration, and test-first development. Agile Architecture brings together architectural guidance provided by the Enterprise and System Architects which is then validated by the teams with short feedback loops as they build the Architectural Runway. Architectural Runway is the code needed to support near-term functionality. We rely heavily on continuous integration. This gives the teams fast feedback if code is broken, as well as reduces risk when code is integrated. Teams use test-first approaches, such as test-driven development, acceptance test-driven development, and automated testing, to test early and often. These techniques help us “build the right software” while “building it right,” advocated by Andrew Dassing.
- SPEAKER NOTES: There is a Japanese word in Lean called “kaizen” which means the art of practicing continuous improvement with a sense of urgency and danger. This term is often translated into “continuous improvement.” SAFe takes this a step further by calling it “relentless improvement” to create a sense of urgency. Events are built into SAFe to ensure this happens.
- SPEAKER NOTES: One of the pillars of the House of Lean is relentless improvement. An enterprise is never agile; it is always becoming more agile. There are multiple events which serve as forcing functions for relentless improvement. Each cross-functional team conducts a retrospective at the end of every sprint. In this retrospective, the team reflects on the good and the bad and collaborates on ways to improve. Collectively, the entire Agile Release Train has a retrospective at the end of every Program Increment called the Inspect and Adapt Workshop. During this workshop, root cause analysis is used to identify Program Level problems and ways to improve. Though everyone is responsible for relentless improvement, there are several key roles: the Release Train Engineer and the Business Owners. The Release Train Engineer facilitates the processes. The Business Owners and other Lean-Agile Leaders remove impediments which the teams themselves cannot remove. During the Innovation and Planning (IP) sprint, teams may have continuing education opportunities and “hackathons” where new approaches, tools, techniques, and prototypes are explored and demonstrated. Fact-based metrics are used as feedback loops to measure the rapid progress towards working, high quality software which satisfies the needs of the business.
- SPEAKER NOTES: As a SAFe principle, we want to make sound economic decisions at all time. An economic decision-making framework is in place to facilitate this. As Donald Reinertsen in his seminal work “The Principles of Product Development Flow” says, “You can ignore economics, but they won’t ignore you”. It is critical that we understand and apply principles, like ignoring sunk costs, understanding the cost of delay, and decentralizing decision-making, in order to prioritize by economics.
- SPEAKER NOTES: The connection between the enterprise business strategy and the Portfolio is through Strategic Themes. This brief list guides budgeting and prioritization, and facilitates decision-making. Epics are progressively analyzed as they move through the Portfolio Kanban System to determine the most important initiatives to do at that given point in time, knowing market conditions may change. It also assures capacity matching. Budgets are also allocated to Agile Release Trains in order to decentralize decisions which can be made quickly and efficiently at the Program Level. Would you like to hear more about Lean-Agile Budgeting? Sequencing of Epics and Features is driven by a Lean approach called Weighted Shortest Job First (WSJF) which looks at the cost of delaying one item in order to do another. It looks at both the cost of delay and the effort to complete it. Would you like to hear more about WSJF? The business value delivered at the end of each Program Increment is assessed by the Business Owners to measure planned vs. actual. The business is responsible for prioritizing and the teams are responsible for delivering. Finally, the business determines when a working increment of software needs to be released, rather than the more rigid waterfall approach of delivering everything at the end.
- SAMPLE SPEAKER NOTES: We’re back where we started. We saw that roles, artifacts, and activities are clearly defined based on proven principles and practices. After decomposing the SAFe Big Picture into it’s constituent parts, I hope we’ve learned that it’s a simple, powerful and easily understood framework for managing complex software and systems development.