Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to What's New in SAFe 4.0
Similar to What's New in SAFe 4.0 (20)
Recently uploaded
Recently uploaded (20)
What's New in SAFe 4.0
- 1. 1© 2016 Scaled Agile, Inc. All Rights Reserved. 1 Presented By:
- 2. 2© 2016 Scaled Agile, Inc. All Rights Reserved. 2 A Few Logistics Before We Start…
- 3. 3© 2016 Scaled Agile, Inc. All Rights Reserved.V4.0.0© 2016 Scaled Agile, Inc. All Rights Reserved. What’s New in SAFe® 4.0? An Overview
- 4. 4© 2016 Scaled Agile, Inc. All Rights Reserved. Agenda 1. Overview 2. Program and Team Level changes 3. Expand for large Value Streams 4. Get results
- 5. 5© 2016 Scaled Agile, Inc. All Rights Reserved. 5 1. Overview
- 6. 6© 2016 Scaled Agile, Inc. All Rights Reserved. 6© 2016 Scaled Agile, Inc. All Rights Reserved. SAFe is a freely revealed knowledge base of proven success patterns for implementing Lean-Agile development at enterprise scale Knowledge for people building the world’s most important systems
- 7. 7© 2016 Scaled Agile, Inc. All Rights Reserved. 2011 Field experience at enterprise scale Now… Agile development | Lean product development | Systems thinking 1.0 2.0 3.0 LSE The evolution continues 4.0
- 8. 8© 2016 Scaled Agile, Inc. All Rights Reserved. 81. PRESENTING SAFe® 4.0 for Lean Software and Systems Engineering
- 9. 9© 2016 Scaled Agile, Inc. All Rights Reserved. SAFe 4.0 Synchronizes alignment, collaboration, and delivery for large numbers of teams 1. Built-In Quality 2. Program execution 3. Alignment 4. Transparency Core Values
- 10. 10© 2016 Scaled Agile, Inc. All Rights Reserved. Three-level SAFe
- 11. 11© 2016 Scaled Agile, Inc. All Rights Reserved. Three-level SAFe 4.0 is backwards compatible with V3 SAFe 3.0 Three-level SAFe 4.0 4.0 is a superset: all the features of SAFe 3.0 are in 3-level SAFe 4.0 Well suited for small to medium-sized, independent programs Migrate existing SAFe implementations to 4.0 as, and when, needed Note: SAFe 3.0 website and courseware will be fully supported through 2016.
- 12. 12© 2016 Scaled Agile, Inc. All Rights Reserved. New foundation layer Easy access to the Values, Mindset, Principles, Practices, and Implementation guidance Lean-Agile Leaders Communities of Practice Core Values, Lean-Agile Mindset, and SAFe® Principles Implementing 1,2,3
- 13. 13© 2016 Scaled Agile, Inc. All Rights Reserved. 13© 2016 Scaled Agile, Inc. All Rights Reserved. Integral SAFe principles #1-Take an economic view #2-Apply systems thinking #3-Assume variability; preserve options #4-Build incrementally with fast, integrated learning cycles #5-Base milestones on objective evaluation of working systems #6-Visualize and limit WIP, reduce batch sizes, and manage queue lengths #7-Apply cadence, synchronize with cross-domain planning #8-Unlock the intrinsic motivation of knowledge workers #9-Decentralize decision-making
- 14. 14© 2016 Scaled Agile, Inc. All Rights Reserved. 14 2. Program and Team Level changes
- 15. 15© 2016 Scaled Agile, Inc. All Rights Reserved. New Program Level Manage the flow of work through the Program Kanban system Apply objective Milestones to plan, manage, and measure progress Have enhanced guidance for program execution Have enhanced communication with new Vision and Roadmap updates Customize to your context with Value Stream Level constructs
- 16. 16© 2016 Scaled Agile, Inc. All Rights Reserved. Enablers support value at all levels Enablers are technical initiatives that support the development of upcoming business initiatives Enablers exist on all four levels of SAFe: Portfolio – Enabler Epics Value Stream Level – Enabler Capabilities Program Level – Enabler Features Team Level – Enabler Stories Enablers usually fall into one of three categories: 1. Exploration 2. Architecture 3. Infrastructure Enablers
- 17. 17© 2016 Scaled Agile, Inc. All Rights Reserved. Program Kanban for flow and Feature readiness BacklogAnalysisFunnel Implementing AnalysisReviewFunnel WIP limit Program Epics Features Breakdown of epics Done WIP limit WIP limit ✓ ✓ ✓ ✓ ✓ Individual Features
- 18. 18© 2016 Scaled Agile, Inc. All Rights Reserved. Enhanced Team Level Support Agile Teams with software, firmware, hardware Apply Kanban for flow Built-In Quality covers software and hardware XP software guidance
- 19. 19© 2016 Scaled Agile, Inc. All Rights Reserved. SAFe teams have a choice of methods Most teams use Scrum, but Scrum is not exclusive Some teams—especially maintenance teams, DevOps, and System Teams—often apply Kanban as their base practice Scrum teams can apply Kanban to visualize work, establish WIP limits, and illustrate bottlenecks Scrum
- 20. 20© 2016 Scaled Agile, Inc. All Rights Reserved. 20 3. Expand for large Value Streams
- 21. 21© 2016 Scaled Agile, Inc. All Rights Reserved. Expand SAFe for large Value Streams
- 22. 22© 2016 Scaled Agile, Inc. All Rights Reserved. New Value Stream Level For people building the world’s largest and most critical systems: Establish governance with an Economic Framework and Value Stream roles Build integrated Solutions for Customers Manage fixed and variable Solution Intent Manage the flow of Capabilities with the Value Stream Kanban Apply cadence and synchronization
- 23. 23© 2016 Scaled Agile, Inc. All Rights Reserved. Solution and Solution Context A Solution is uniquely associated with one Value Stream. It is defined by Solution Intent. The Solution Context defines the environment in which the solution operates: - System of systems (e.g., avionics system as part of the aircraft), product suite (word processor as part of an office suite) - Production infrastructure (e.g., cloud environment where solution is deployed) - Other applications or systems the target solution is integrated with Solution Context
- 24. 24© 2016 Scaled Agile, Inc. All Rights Reserved. Capabilities describe Solution behaviors A Capability describes the higher-level behaviors of a Solution They are maintained in the Value Stream backlog and are prioritized using WSJF They are written using a phrase, statement of benefits, and acceptance criteria They must be structured to fit within a single PI Capabilities are split into Features for implementation Capability Value Stream Backlog A G I L E R E L E A S E T R A I N A G I L E R E L E A S E T R A I N A G I L E R E L E A S E T R A I N
- 25. 25© 2016 Scaled Agile, Inc. All Rights Reserved. Capture knowledge in Solution Intent Record and communicate requirements and design decisions Facilitate continuous exploration and analysis activities Align the Customer, system builders, and Suppliers to a common purpose Support compliance, contractual issues, traceability, high assurance Solution Intent: Single source of truth as to the intended and actual behavior of the Solution Traceability
- 26. 26© 2016 Scaled Agile, Inc. All Rights Reserved. Customers have Agile responsibilities Engaging the Customer in the Agile process—depends on type of Solution and Customer impact Direct - Customer represents self - Defines fixed/variable solution intent - Directly validates product assumptions; attends planning and Solution Demos - Collaborative scope and schedule management; managed investment funding model Indirect - Solution builder content authorities proxy the Customer - Solution Intent reflects facts and hypotheses - Frequently validates product assumptions - Scope, schedule, and budget at solution builders’ discretion Example: Government purchaser of a defense system Custom built-solutions Example: End-user purchaser of a CRM system General solutions
- 27. 27© 2016 Scaled Agile, Inc. All Rights Reserved. Suppliers may or may not be Agile Suppliers often play a key role in Solution development. The overall Value Stream’s agility is dependent on Suppliers’ agility. Lean-Agile Suppliers are treated as another Agile Release Train, participating in all value stream ceremonies. Suppliers working in traditional methodologies work against Milestones but are expected to attend Pre- and Post-PI Planning, Solution Demo, and Value Stream Inspect and Adapt. SAFe® Enterprises help Suppliers improve their processes and become more Lean and Agile, to the economic benefit of both organizations.
- 28. 28© 2016 Scaled Agile, Inc. All Rights Reserved. Coordinating with Pre- and Post-PI Planning Typically attended by: Customers, VSE, Solution Mgmt, Solution Architects/Eng, Value Stream stakeholders, and select representatives from ARTs and Supplier Pre-meeting helps build an aligned plan for the next PI and match Solution demand to ART capacities Post-meeting reviews, recaps, communicates, and provides feedback Pre Post ART PI Planning Value Stream ARTs ART PI Planning ART PI Planning
- 29. 29© 2016 Scaled Agile, Inc. All Rights Reserved. Solution Demo provides objective evidence The Solution Demo is a major event in the life of the Solution The entire Value Stream demos a fully integrated solution, showing accomplishments of the previous Program Increment Senior managers and high-profile stakeholders review the progress Action and investment decisions are based on this objective evidence Solution Demo
- 30. 30© 2016 Scaled Agile, Inc. All Rights Reserved. 30 4. Get results
- 31. 31© 2016 Scaled Agile, Inc. All Rights Reserved. 311. Train Everyone. Launch Trains.
- 32. 32© 2016 Scaled Agile, Inc. All Rights Reserved. Implementing SAFe 1-2-3
- 33. 33© 2016 Scaled Agile, Inc. All Rights Reserved. Achieve business results Happier, more motivated employees 20 – 50% increase in productivity 30 – 75% faster time to market 50%+ defect reduction See ScaledAgileFramework.com/case-studies
- 34. 34© 2016 Scaled Agile, Inc. All Rights Reserved. 34© 2016 Scaled Agile, Inc. All Rights Reserved. Gain the knowledge Explore the SAFe knowledge base and find free resources at: ScaledAgileFramework.com Leading SAFe® with SA Certification Implementing SAFe® with SPC4 Certification Find SAFe training worldwide at: ScaledAgile.com
- 35. 35© 2016 Scaled Agile, Inc. All Rights Reserved. 35© 2016 Scaled Agile, Inc. All Rights Reserved. Questions?
Editor's Notes
- Welcome to What’s New in SAFe 4.0! In this presentation we’ll provide a brief overview of the changes in the latest version of SAFe. This presentation usually takes about 45 minutes.
- Some things haven’t changed. SAFe is a knowledge base for people building the world’s most important systems. It is freely revealed, so everyone can apply the knowledge in their context. Our mission is still solely and exclusively to help software- and system-dependent enterprises achieve better outcomes, higher quality, faster time to market, increased employee engagement, and overall improved economics through Lean-Agile principles and practices based on the Scaled Agile Framework.
- The Framework is based on a set of disparate but compatible bodies of knowledge – Agile development, Lean thinking and Lean product development, systems thinking, and systems engineering. The knowledge of the Framework isn’t a one-time learning event…. It’s an ongoing process. The first public release of SAFe, in its current web-accessible form, was in 2011. But its history goes back even earlier than that. So you can see that the pace of innovation is relentless and constant; we are always updating the site and its corresponding courseware with what we learn. Articles can be updated and republished at any time. Previously we’d release more frequent updates to the “Big Picture” itself, but now there is about a once-a-year release cycle on the BP. We make an effort to be backwards compatible wherever possible, so the specific practices and roles you’ve adopted can remain largely unchanged while you avail yourself of the new features in each new release. “Behind the BP,” the pace of innovation continues, as we are continuously updating new articles and adding guidance articles as well. With SAFe 4.0, we have merged the practices of SAFe for Lean Systems Engineering and SAFe 3.0 into a new release. As such, SAFe 4.0 handles the needs of small to medium-size software and systems builders, but it also scales to the needs of those building some of the world’s biggest, most complex, and most impactful software solutions and cyber-physical systems. Let’s look further into this major new release.
- No longer simply the Scaled Agile Framework, it’s now SAFe 4.0 for Lean Software and Systems Engineering, to better reflect its broader applicability. If you’re building really big software systems, you can do it in a Lean-Agile manner with SAFe. If you’re building a big and complex cyber-physical system, like a satellite, industrial machine, or medical equipment that requires software and hardware and communication between different subsystems, SAFe addresses that too. But if you’re building a more modest application or system that requires maybe a hundred or so people to build, or even fewer, the enhanced modularity of SAFe also handles that.
- The Core Values that we treasure and base the framework on are unchanged: With its built-in-quality focus, SAFe helps teams create good code and components quality, which is important, because “You can’t scale crappy code” (or hardware or anything else). There is a primary focus on program execution, which is the ability to build large systems incrementally, in a predictable and reliable manner. If you can’t do that, not much else really matters. Global alignment trumps local optimization. Everyone needs to understand and agree on what it is they are building, and what problems the system needs to address. Teams are empowered, for certain, but they work together to accomplish the larger program and enterprise mission. Lean and Agile require trust to be effective. The framework helps build trust via transparency. Lean doesn’t work if an organization hides behind its politics, because “you can’t manage a secret.”
- We’ll talk about 3-level SAFe first. Three-level SAFe is a configuration of SAFe 4.0 that is largely SAFe 3.0, but with some significant new enhancements: The ability to have Kanban at the Team Level. Incorporation of specific XP practices and HW/SW/FW quality guidance. Kanban at the Program Level, and connected Kanbans among levels for Enterprise value flow and visibility. The addition of the Solution and Customer elements. Strategic Themes connection to the new Enterprise object. Enablers as a richer surface for exploration, architecture, and infrastructure work. These must have visibility to manage WIP and help assure flow. A floating tool palette to enhance modularity and configurability. A new foundation layer to hold Lean-Agile Leaders, new Communities of Practice, Core Values, the Lean-Agile Mindset, SAFe Principles, and Implementing 1,2,3. And much more. But all the familiar features of Version 3 are still here, so you can use this level now as is, and add the new features to your implementation over time.
- If you’re comfortable with Version 3, you don’t have to worry about Version 4 just yet, but you can start using the new website right away. Every feature of Version 3 exists in Version 4. You don’t have to adopt what’s new in Version 4 until you’re ready. And by the way, Version 3 is still supported at v3.scaledagileframework.com. It will be there throughout 2016. Also, we still support all the Version 3 courses, so your SPCs and partners can continue with a Version 3 rollout. “3-level” SAFe 4.0 implies that there’s a fourth level, and of course there is, but you don’t have to use it right away. We’ll get into that a little bit later in this presentation.
- So what has changed? One of the most critical new features is the foundation layer. It gives us a chance to talk about things we’ve always wanted to discuss but that weren’t bound to the actual Big Picture. They’re foundational to our values and understanding, even though they’re not part of the development process per se. It holds Lean-Agile Leaders, new Communities of Practice, Core Values, Lean-Agile Mindset, SAFe Principles, and Implementing 1,2,3. It’s also great placeholder for future background and supportive elements as well. These concepts were always part of SAFe, but now they’re also visible and integral to the Big Picture. You can access them easily – click on any one of them, directly from the BP, to learn more.
- The SAFe Principles haven’t changed in this release, but it’s worth looking at them again here. Why? Because SAFe is a PRINCIPLE-BASED set of practices. We don’t add any practice unless it’s based on, and supported by, a fundamental truth that exists for all companies, not just an individual company situation. So these are the 9 principles that underlie the SAFe practices. Principles trump practices. We always start with principles in our discussions, and even more importantly in our trainings. If you head down a SAFe path, they will all become familiar to you, and they will influence your way of working every day. It would be fun to go through them now, but we don’t have time in this forum. Read them at your leisure, or better yet, come to class!
- Let’s see what new things we can find at the Program and Team Levels.
- New elements at the Program Level include: Solution and Customer now as primary objects Managing the flow of work through the Program Kanban system Applying objective Milestones to plan, manage, and measure progress Enhanced guidance for program execution Enhanced communication with new Vision and Roadmap updates Customizing to your context with Value Stream Level constructs And you’ll get an overview of some enhancements we’ve made to our guidance for effective program execution and communication with vision and roadmap updates. At the top you can see what we call the new “spanning palette,” which means that these capabilities can apply at several different levels of SAFe. For example, Vision used to appear at the program level only — but actually it can appear there, at the Team Level, or elsewhere.
- “Enablers” is new and broader term, replacing architectural features. Enablers can occur at all levels of the framework. This is the work of exploration, architecture, infrastructure, and other aspects that enable future value. It’s not just enabling actual code — but, say, a research spike for a new idea to see if there’s a market for it. You would think of that as an “exploration” type of enabler, or set of enablers. We call this out because it’s real work. It must happen, so it must be made visible. It it isn’t visible, it either doesn’t happen, or flow is heavily impeded, or both. Many of these might not appear to contribute DIRECTLY to the user experience, but if we don’t do this work, we can’t carry on providing value to the users.
- We’ve also described Kanban at all levels. The new Program Kanban system facilitates the flow and readiness of Program Epics and Features. While all Kanban systems are purpose-built, a typical structure is illustrated on this slide. Notice that the Kanban system has two sections: Program epic section The purpose of the program epic section of the program Kanban is to analyze and approve program epics and split them into features that will be further explored and implemented in the “downstream” feature section of the program. This section is not always present in the program Kanban; it depends on how frequently program epics occur in the local context of the program. Feature section The feature section facilitates readiness, prioritization, and implementation of features. Features may originate locally (either from program epics or introduced as individual features that don’t have a parent program epic). Or they can come from upstream Kanbans (Portfolio or Value Stream). In either case, features enter the Feature Funnel to be elaborated before commitment to a PI goal.
- The Team Level has been updated, too. SAFe now supports Kanban for teams, with the team’s local Kanban feeding the Team Backlog. Scrum is directly supported and described, as has always been the case. We’ve also selectively harvested and described some XP practices: collective ownership, Continuous Integration, Test-First, pair work (not necessarily pair programming). Calling out these elements of Scrum, Kanban, and XP enables teams to apply the best of all of them, and ignore the external method wars. Built-In Quality guidance has been expanded to cover software and hardware.
- The team may or may not need all the practices of, say, Scrum — which we fully support — though that is the general default for Agile Teams. But they might choose Kanban as their base practice. Or perhaps they have good experience with XP. In other words, in SAFe it’s the case that Scrum, Kanban, and XP are all “first-class citizens.” It’s all good. Teams can choose how they want to approach their Agile work. These methods ALL have value for just about any team. What’s truly important is that teams focus on doing a couple of things well: Integrate at every increment (worst case) Make sure every increment delivers system-level value Plan together, demo together, and improve together
- What we’ve discussed so far is largely 3-level SAFe. But now we will see the biggest change in Version 4.0.
- To look at the history a bit, last year we developed a public branch called SAFe for Lean Systems Engineering. We worked directly with some of the world’s largest systems builders to understand and codify a set of Lean and Agile principles and practices that worked in all contexts in that branch. That meant we had to think about certain things that work differently when you’re building a really big system. But it turns out that the principles are the same, though some of the practices vary a bit. Over time, it became obvious that we needed to incorporate all that content into a single framework — thus SAFe 4.0 for Lean Software and Systems Engineering. Furthermore, those same clients came to us and said they also need to think about these things at the Portfolio Level. People in classes came up with the idea of an “accordion” — sometimes they needed that fourth level and sometimes they didn’t, but it had to be there somehow to support either case. That was the genesis of the new Value Stream Level, and the expand/collapse feature of the 4.0 Big Picture.
- As we said, that was the evolution of the new, optional Value Stream Level. If you’re building big, complex systems, systems that take multiple ARTs to deliver, you probably need this level. Here we have room for Solution Intent, Solution, and Solution Context. It incorporates all the things we see here — and especially the last bullet point, the principle of keeping to cadence and synchronization — that remains critical here as well. But if you don’t need it, don’t use it. However, many programs find some of the elements useful, even if they don’t require multiple ARTs. Let’s look at some of these new capabilities.
- Here we come to the big question: What are we building? The whole point is that we do work in order to build Solutions, and the Solutions appear in a context. So you can click on these to read more about Solutions, what they mean, how they have to happen in a context. This is what helps us really take a systems view.
- We realized when we added that new level that we needed vocabulary that both Customers and Solution builders could relate to, when thinking about large-scale systems. We needed another element — and that was “Capabilities.” People told us that just talking about Features wasn’t enough. It could take 300, 400 features to deliver a single capability in a really big system. So capabilities are in this level — but the entire level is optional. If you’re not building such a big system, you’re fine with Stories and features and Epics. But this Value Stream Level needs this new artifact type, the capability. It’s a lot like a feature. And it has to be done in the increment — if your capability is too big, you split it. The same rules apply.
- When we’re building these really big systems, or high-assurance systems, systems that have an unacceptable cost of failure, then the reality is that you do have to know what the Solution actually does now, and what it is intended to do in the future. You can’t just approach it as one small Story at a time and throw the story away when you’re done. And we may need to model a complete system before committing to implementation. We may even be accountable to the client or an auditor for design decisions, and so on. We may have to record things for our quality management systems, and for compliance to a regulatory standard. Maybe traceability isn’t optional. The fact is, we can play by all these rules and still be Agile. The trick is in the DOING, and SAFe can help with that.
- The Customer was always implied before, but now we’re discussing Customers directly. As you can see from the above, Customers in Agile are part of the process, they are integral to the Value Stream and have some specific responsibilities. You can’t be Agile unless the Customer is “part of the Solution” (play on words). So now you can click on the Customer article and get good information about their role. And so can they!
- The same thing holds for Suppliers, whether they’re internal or external to the system-building organization. Our Suppliers may or may not be Agile. But they have some roles to play in delivering to an Agile shop. So now we have a good amount of guidance about how to work with Suppliers in Agile, even if they themselves are not fully (or even partly) Agile.
- We didn’t invent Pre- and Post-PI Planning as part of multiple ART coordination — we observed that people were doing it. So we added these new elements to the Value Stream Level. Benefits: Face-to-face alignment of ARTs and Suppliers in a Value Stream Cross-ART coordination Providing “just enough” Solution-level architectural and User Experience guidance Matching solution-level demand to ART capacities
- What’s our major Milestone at the Value Stream Level? Obvious answer: the Solution-level demo. It’s obviously just as critical, if not more so, at the full, integrated system level. That means that all those System Demos that happened at the ART Level have to be integrated for this level. All the cross-cutting Capabilities have to be demonstrated. We need to demo that thread throughout the entire system. So that makes the Solution Demo a critical element. And we have to be able to integrate frequently in order to get to this point.
- What we’ve discussed so far is largely 3-level SAFe. But now we will see the biggest change in Version 4.0.
- So how do we get started? It’s “simple,” conceptually: Train everyone and launch trains. Everyone needs to understand the new way of working, and all teams become Agile Teams in an Agile Release Train.
- And here’s the “how” in 1, 2, 3 steps: Develop and train the internal or partner SPCs, the change agents who understand the new way of working. They in turn, will train the leadership in Leading SAFe, thereby giving the leaders the knowledge they need to lead, rather than follow, the transformation. They will also train the new Agile Teams in SAFe for Teams, and together with that new muscle, launch Agile Release Trains that deliver the value. One train at a time, and you’ll be on your way to building the Lean-Agile Enterprise and achieving the business and personal benefits that these new methods can deliver.
- SAFe can help you achieve these business benefits. Check out the case studies for more. We are also confident that if you follow the 1-2-3 plan, you’ll achieve similar benefits. We think you deserve that.
- What’s your next step? Gain the knowledge. There is no substitute for knowing what you are doing. Great leaders have that knowledge. Educate yourself first. Attend “Leading SAFe® 4” (a two-day class for managers and executives) or “Implementing SAFe® 4 with SPC Certification,” a four-day class for the change agents who will drive and implement the transformation. After all, you can never be too knowledgeable about this stuff.