SAFe 101

Editor's Notes

• #14: A Nexus consists of multiple cross-functional Scrum Teams working together to deliver a potentially releasable Integrated Increment at least by the end of each Sprint. Based on dependencies, the teams may self-organize and select the most appropriate members to do specific work. Refine the Product Backlog: The Product Backlog needs to be decomposed so that dependencies are identified and removed or minimized. Product Backlog items are refined into thinly sliced pieces of functionality and the team likely to do the work should be identified. Nexus Sprint Planning: Appropriate representatives from each Scrum Team meet to discuss and review the refined Product Backlog. They select Product Backlog items for each team. Each Scrum Team then plans its own Sprint, interacting with other teams as appropriate. The outcome is a set of Sprint Goals that align with the overarching Nexus Sprint Goal, each Scrum Team's Sprint Backlog and a single Nexus Sprint Backlog. The Nexus Sprint Backlog makes the work of all Scrum Team's selected Product Backlog items and any dependencies transparent. Development work: All teams frequently integrate their work into a common environment that can be tested to ensure that the integration is done. Nexus Daily Scrum: Appropriate representatives from each Development Team meet daily to identify if any integration issues exist. If identified, this information is transferred back to each Scrum Team’s Daily Scrum. Scrum Teams then use their Daily Scrum to create a plan for the day, being sure to address the integration issues raised during the Nexus Daily Scrum. •Was the previous day’s work successfully integrated? If not, why not?•What new dependencies or impacts have been identified?•What information needs to be shared across teams in the Nexus? Nexus Sprint Review: The Nexus Sprint Review is held at the end of the Sprint to provide feedback on the Integrated Increment that a Nexus has built over the Sprint. All individual Scrum Teams meet with stakeholders to review the Integrated Increment. Adjustments may be made to the Product Backlog.
• #24: As an organizational researcher and author John Kotter illustrates in his recent book, Accelerate: Building Strategic Agility for a Faster-Moving World [1], successful enterprises don’t start as large and cumbersome. Rather, they typically began as a fast-moving, adaptive network of motivated individuals aligned to a common vision and focused on the needs of their customers. Roles and reporting relationships are fluid, and people collaborate organically to identify customer needs, explore potential solutions, and deliver value in any way they can. In other words, it’s an adaptive ‘entrepreneurial network’ of people working towards a shared, customer-centric purpose
• #25: As the enterprise succeeds, it naturally wants to expand on its success and grow. This means that individual responsibilities must become clearer to ensure that critical details are carried out. To add expertise, specialists are hired. Departments are created. Policies and procedures are established to ensure legality and compliance and to drive repeatable, cost-efficient operations. The business starts to organize by function. Silos begin to form. Meanwhile, operating in parallel, the network continues to seek new opportunities to deliver value.
• #26: To achieve increasing economies of scale, the hierarchy continues to grow. And grow. However, by assuming the practices and responsibilities incumbent on large business, it begins to conflict with the entrepreneurial network. With the authority of current revenue and profitability needs behind it, the hierarchical organization collides with the faster-moving, more adaptive network. The result? The network gets crushed in the process. Customer centricity is one of the casualties.
• #28: The organizational hierarchies that we’ve built over the last fifty years have done a great job of providing time-tested structures, practices, and policies. They support the recruiting, retention, and growth of thousands of employees across the globe. Simply put, they are still needed. But the question becomes, how to organize and reintroduce the entrepreneurial network? In addressing the dilemma, Kotter points out, “The solution is not to trash what we know and start over but instead to reintroduce a second system.” This model, which Kotter calls a ‘dual operating system’, restores the speed and innovation of the entrepreneurial network while leveraging the benefits and stability of the hierarchical system.
• #29: By organizing the second operating system around value streams instead of departments, SAFe offers a way for enterprises to focus on customers, products, innovation, and growth, SAFe is that second organizational operating system Moreover, this operating system is flexible. It is built on time tested Lean, Agile, and SAFe practices, and it can organize and quickly reorganize without completely disrupting the existing hierarchy. That’s what Business Agility demands.
• #34: The practices of SAFe are freely available of the framework website. These have been proven to work in an integrated fashion in many organizations.
• #35: These are aggregate results. See case studies for individual results.
• #36: …. except that these numbers and results come from the companies themselves, both private and public enterprises We don’t influence them. We simply gather the data from the enterprises and publish them. Go to the website and you’ll see over 40 documented case studies on SAFe right now. scaledagileframework.com/case-studies
• #42: Trainer Guidance: House of Lean is a classic metaphor describing the values that are essential for Lean thinking based on the Toyota Production System. Taiichi Ohno is considered the father of the Toyota Production System, which became Lean manufacturing in the U.S. Derived from Lean manufacturing, the principles and practices of Lean thinking, as applied to software, product, and systems development are now deep and extensive. For example, Ward, Reinertsen, Poppendieck, Leffingwell, and others have all described aspects of Lean thinking, placing many of the core principles and practices in a product development context. Along with these, we present the SAFe House of Lean.
• #43: Trainer Guidance: Responding to challenges of the waterfall processes in the 1990’s, some lighter-weight and more iterative development methods arose. In 2001, many of the leaders of these frameworks came together in Snowbird, Utah. While there were differences of opinion on the specific merits of one method over another, the attendees agreed that their shared values and beliefs dwarfed the differences. The result was a Manifesto for Agile Software Development. It was a turning point that clarified the new approach and started to bring the benefits of these innovative methods to the whole development industry. That was the Lean part, now let’s look at Agile part. The Agile Manifesto kick-started this. It’s absolutely imperative that the organization understands and embraces all of this. If they don’t, we simply can’t go forward with anything until they do. Tips: Open up a brief discussion on whether the Manifesto still holds a great deal of value. You can talk through each of the values and relate them to something in the SAFe Framework. For example, do we need to forecast as an enterprise? We need visibility, but also need to be able to adapt.
• #44: The goal of SAFe is to synthesize this body of knowledge, along with the lessons learned from hundreds of deployments. This creates a system of integrated, proven practices that have improved employee engagement, time to market, solution quality, and team productivity. Given the complexities discussed earlier, however, there’s no off-the-shelf solution for the unique challenges each enterprise faces. Some tailoring and customization may be required. Not every SAFe recommended practice will apply equally in every circumstance. This is why we work hard to ensure that SAFe practices are grounded in fundamentally stable principles. That way we can be confident they’ll apply in most situations. Although the principles are numbered in order to identify them, they are not prioritized in that order.
• #46: Agile teams are the cornerstone of business agility. The Team and Technical Agility competency, which describes the Lean-Agile skills, principles, and practices that high-performing Agile teams use to create high-quality solutions for their customers, consists of three dimensions, shown here.
• #51: Discover: Market and User Research to identify unmet needs.  Fresh perspective that drives innovation. Switch from “how the user should work” to “how the user does work” Define: Use insights from Discover for new product development. Epics and Features capture the perceived changes needed for existing products and solutions. Develop: design potential solutions to problems quickly and cost-effectively – Assume Variability; Preserve Options Deliver: produces artifacts that are suitable for creating the solution (varies based on context) Often start with prototypes that convert to validated Features in the Program Backlog for ongoing delivery via the CD-Pipeline
• #53: Trainer Guidance: Cover the 3 key train features 5-12 teams, synchronized, aligned. Key Message: The Continuous Delivery (CD) Pipeline (also referred to as ‘pipeline’) represents the workflows, activities, and automation needed to provide a continuous release of value to the end user. The pipeline consists of four elements: Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment, and Release on Demand. Each Agile Release Train (ART) builds and maintains (or shares) a pipeline with the assets and technologies needed to deliver solution value as independently as possible. The first three elements of the pipeline work together to support delivery of small batches of new functionality, which are then released in accordance with market demand. References: Read more at: http://www.scaledagileframework.com/continuous-delivery-pipeline/
• #54: The ART synchronizes its work with PI Planning. Typically PI Planning is face to face, but, if it's a large organization, you may not be able to have everybody face to face every time. Management sets the mission, with minimal possible constraints—that's a key philosophy of Lean Thinking. Requirements and design emerge. We talk about emergent design as one of the key aspects of Agile, and it emerges here. We call this PI Planning, but there's far more than planning that happens. People collaborate, they determine new requirements, they negotiate teams and dependencies. Business owners add features and take out features to manage scope. Important stakeholder decisions are accelerated in a day—not after six weeks of emails banging around, trying to find the right person to make the decision, but right now. Ultimately, teams create and take responsibility for the plans, and that's a big difference from our traditional command-and-control, centralized program-planning model. In this case, management sets the vision, but the teams create the plans.
• #56: Building and evolving large, cyberphysical systems and enterprise class software solutions is a significant undertaking. Many such systems require hundreds or thousands of engineers, demanding sophisticated, rigorous practices for engineering, operations, and support. That calls for continuously delivering new capabilities, along with technology upgrades, security patches, and other enhancements. The Enterprise Solution Delivery competency describes how to apply Lean-Agile principles and practices to specify, develop, deploy, operate, and evolve the world’s largest and most sophisticated software applications, networks, and cyber-physical systems. This competency consists of three dimensions.
• #70: Trainer Guidance: Dr. W. Edwards Deming taught that by adopting appropriate principles of management, organizations can increase quality and simultaneously reduce costs by reducing waste, rework, staff attrition and litigation while increasing customer loyalty. The key is to practice continual improvement and think of manufacturing as a system, not as bits and pieces. Tips: Engage the learners by asking why is it so important for leaders to lead rather than just support this type of change. You may use the the following anecdote: Deming was once advising a large company and had invited an executive to a plant where that mastered many of these practices. In his invitation, he told the executive, “If you can’t come. Send nobody.” The key message here is that this work can’t be delegated. The leadership team has to be trained and have buy-in first. We have to prepare the executives and teach them the actions they need to take, not just the principles.
• #71: While no two SAFe adoptions are identical, and they rarely follow a perfectly sequential step-by-step process, businesses typically get the best results when they follow a path similar to that shown in the SAFe Implementation Roadmap, which includes 12 steps. Each of the 12 steps is supported by a dedicated guidance article in the SAFe knowledgebase.
• #72: The road to business agility is a journey, not a destination. Measure and Grow is the way portfolios evaluate their progress towards business agility and determine their next improvement steps. Measure and grow describes how to measure the state of Business Agility and how to grow to improve overall economic outcomes.
• #73: The SAFe business agility assessment provided on the SAFe website helps enterprises understand where they are on their journey, identify next steps, and remember to celebrate successes along the way. Periodically applying the assessment, contemplating the results, and following the recommendations will help ensure the best possible business outcomes.
• #75: Essential SAFe is the heart of the Framework and is the simplest starting point for Implementation. It's the basic building block for all other SAFe configurations and brings the core competencies of Lean-Agile Leadership, Team and Technical Agility, DevOps and Release on Demand to the enterprise. Large Solution SAFe brings the Business Solutions and Lean Systems Engineering competency to those building the largest and most complex solutions. This configuration supports multiple Agile Release Trains (ARTs) and suppliers, but does not include portfolio-level considerations. Portfolio SAFe applies the Lean Portfolio Management competency to align portfolio execution to the enterprise strategy, and organizes development around the flow of value through one or more value streams. Full SAFe, the most comprehensive version, supports enterprises that build and maintain a portfolio of large, integrated solutions, and includes all five core competencies.
• #76: Scaled Agile’s role-based curriculum helps enterprises unlock business results with SAFe. Each course is designed to help individuals maximize the value of their role within a SAFe organization, and help them advance throughout their career as they practice, consult, or train others in SAFe. The result is higher-quality implementations, and greater stability for the organization.