Q&A on the Book SAFe Distilled

The book SAFe Distilled breaks down the complexity of the framework into easily understood explanations and actionable guidance. It’s a resource for acquiring a deep understanding of the Scaled Agile Framework, and how to implement it successfully.

InfoQ readers can download a sample of SAFe Distilled.

InfoQ interviewed Richard Knaster and Dean Leffingwell about SAFe's view on scaling agile, how enterprises apply SAFe, how the agile manifesto looks when applied at scale, what can be done to empower teams and support local decision making, how you can estimate and forecast large complex systems, how to achieve success with an agile transformation, and what can be done to support continuous improvement in enterprises.

InfoQ: What made you decide to write this book?

Richard Knaster: Ben, that’s a great question and interestingly enough, one that we hear more, and more often. We wrote this book to help people and companies succeed in a world that is changing more rapidly than ever. Things are moving so fast that people don’t have time to reflect, improve and respond rapidly to advances in technology to be a real player in today’s digital economy. And even if they did, they often don’t know how and what needs to be changed. The SAFe website is great, however, it was designed for as-needed, random access, for those who need just-in-time information to do their job. You have to read many articles and jump around from one article to another to understand SAFe from our knowledge base. The book breaks down the complexity of the framework and weaves into an integrated story with easily understood explanations and practical guidance. But we all know that organizational change is hard. It requires adopting new behaviors, leadership styles, practices, and culture. SAFe accelerates lean-agile transformation with the new implementation roadmap, introduced in SAFe Distilled, which guides enterprises every step of the way. And because SAFe is a big framework, we dedicate an entire chapter to outline the ten essential elements needed to achieve the majority of its benefits.

Dean Leffingwell: SAFe is an extensive on-line knowledge base for people building the world’s most important systems. It isn’t a trivial framework, because the systems people build with SAFe aren’t trivial either. But a knowledge base is just that - a knowledge base - and as such, it doesn’t tell a story or summarize itself. In order to get a better understanding of the full scope and depth of SAFe, we wanted to provide a shorter, readable guide that summarized that knowledge so that practitioners could have a better understanding of what SAFe is, what principles it is built on, what practices it provides, and finally, how to implement it.

InfoQ: For whom is this book intended?

Leffingwell: Technical executives, leaders, managers and practitioners who want to build bigger and better systems, more quickly, and who want to apply the latest and most contemporary approaches for solution development, — which today is applying lean and agile practices at enterprise scale.

Knaster: This book is intended for several audiences. It helps leaders and executives understand the business case for SAFe: its benefits, the problems it solves, and how to drive a lean-agile transformation at scale. It helps managers understand their new role as lean-agile leaders, empowering teams to build better systems by learning, exhibiting, and coaching SAFe’s lean-agile principles, mindset and systems thinking. It helps agile teams learn how to deliver value faster, build quality in, and improve the flow of work to achieve better business outcomes. Most importantly, it helps all readers understand what is SAFe, why business needed it, and how to apply its principles, practices and values.

InfoQ: What is SAFe's view on scaling agile?

Knaster:  SAFe scales by combining the power of agile with lean product development, and systems thinking. It creates alignment between strategy and execution from the portfolio to agile teams and vice versa. The basic building block for SAFe’s scalability are Agile Release Trains (ARTs). An ART is essentially an agile program, which contains between five to twelve agile teams that are all collaborating together, as one team, via a common mission, vision, and program backlog.

If you are building a solution that requires the contributions of hundreds—or even thousands—of people, you simply launch more trains and coordinate them following the same patterns and similar roles used to coordinate multiple Agile teams. Face-to-face planning and integrated system demos helps assure collaboration, alignment, and rapid adaptation. ARTs build and maintain a continuous delivery pipeline, which is used to regularly develop and release small increments of value. ARTs provide common and consistent approaches to user experience through lean UX principles and practices. Using a build-measure-learn hypothesis driven approach for developing new features—ARTs are designed to be a continuous engine of innovation. Another aspect of scalability is SAFe’s CALMR (Culture, Automation, Lean Flow, Measurement and Recovery) approach to DevOps. After all, value is only achieved when the solution has been released to the market or the production environment. DevOps is a key enabler of achieving scalability and a faster flow of value.

Leffingwell: As agilists, we firmly believe that ‘nothing beats an agile team’, except a ‘team-of-agile-teams’ working towards a common and unifying mission. SAFe was launched on the back of the basic paradigm of self-organizing and cross-functional agile teams. Everyone who has ever been on one knows those benefits. But team agile doesn’t scale itself. We didn’t start out to ‘scale agile’ or to ‘build a framework’, rather we simply wanted to help people building bigger systems enjoy the benefits of agile development. That evolved into a full-fledged framework.

InfoQ: What levels does SAFe have, and how do agile enterprises typically apply them?

Leffingwell: Well, three or four, depending on how you count them! The team and program level are really just one level, a team-of-agile teams, known as an ‘Agile Release Train. But we still structure them as two levels, Team and Program, because the concerns are somewhat different and it’s easier to organize and understand guidance that way. Those levels constitute what we call ‘Essential SAFe’, one of the four out-of-the box configurations.

• +1 adds Portfolio level concerns of strategy and investment funding, portfolio flow and lean startup thinking, agile program guidance and lean governance.
• +1 more adds the Large Solution level, which provides guidance for people building really big systems.

Knaster:  SAFe provides guidance for all the levels of the enterprise that are actively engaged in solution development— team, program, value stream, and portfolio— along with a supporting foundation element and spanning palette. SAFe’s configurable framework provides just enough guidance to meet the needs of a product, service or organization. Enterprise can start simply with Essential SAFe, and yet have the ability to grow as needs evolve over time, such as adding the portfolio and large solution levels as Dean describes above.

InfoQ: How does the agile manifesto look when applied at scale?

Knaster: The ‘Manifesto for Agile Software Development’ unleashed a dramatic and entirely new way of thinking and working for software developers. However, the majority of these principles can also apply to developing a large, integrated solution that contains both hardware and software. What we have learned from our implementations of SAFe and from our students in our SAFe classes is that the manifesto does indeed scale. Let’s take an example: Principle #11 of the manifesto states, “The best architectures, requirements, and designs emerge from self-organizing teams.” While most people would agree with this principle, it depends on how you define a team and how you define the subject and scope of the decisions. Local decisions are generally best. After all, that’s part of SAFe principle #9— decentralize decision-making. However, that principle also provides the economic rationale for when some decisions are most efficient when they’re centralized. The bottom line is that the manifesto remains as relevant today as it was when it was written. We’re fortunate to have it, and it plays a critical role in scaling with SAFe.

Leffingwell: That’s always a fun exercise that we do in every class. Most every team determines that the values and principles of the manifesto are even more important when building big systems. For example, who can argue that ‘working software’, ‘sustainable pace’, ‘face-to-face communication’, ‘simplicity’, ‘good design’, etc.  doesn’t apply when building large and mission critical systems? Indeed, they are even more critical. And yes, there are always some nuances around “welcome changing requirements” (imagine a few days before a satellite launch, for example), and perhaps “... over documentation” (imagine that it’s you who goes to jail if the appropriate regulatory docs aren’t submitted). But SAFe depends on agile, and the manifesto, for a significant amount of its practices and benefits. Put us down of as huge fans of that 2001 document. You can’t implement SAFe without believing in the value system of the manifesto.

InfoQ: What can be done to empower teams and support local decision making?

Leffingwell: It all comes down to a new lean-agile leadership mindset. This includes an understanding of lean and product development flow, as well as a commitment to the agile manifesto.  There’s no pill a leader can take for that, and it’s a journey, not a destination. Educating oneself in lean and agile development, and committing to life-long learning, is the only answer to that. SAFe always starts with leadership training because, as Deming notes, “only management can change the system”.

Knaster: Delivering value in the shortest sustainable lead time requires decentralized decision-making. Any decision that must be escalated to higher levels of authority introduces a delay in delivery. In addition, escalated decisions can decrease the effectiveness of decisions because of the lack of local information, plus changes to facts that may occur during the waiting period. SAFe’s principles #9 is a key enabler for supporting decentralized decision making. Its approach is to centralize decisions that are infrequent, long lasting and provide significant economies of scale. All other decisions should generally be decentralized. Another aspect is that everyone should be a leader to get the best out of people. David Marquet, retired submarine captain and author, sums it up well in his book ‘Turn the Ship Around.’ He says, “Leadership isn't for the select few at the top. In highly effective organizations, there are leaders at every level” and my favorite, “Take control and create followers. Give control and create leaders.”

InfoQ: How can you estimate and forecast large complex systems?

Leffingwell: Agile estimating and planning is based on history, not work breakdown structure. And yet, large systems have to be decomposed into larger parts so the work can be estimated. Teams do that in SAFe, using epics, features and stories, all using story points as the only currency. It isn't very precise; it’s just more accurate overall! It’s quite a finding when people learn how they can estimate and plan better in scaled agile, then they could with traditional methods.

Knaster: There is no crystal ball for estimating large-scale complex systems. Estimating is guessing and we shouldn’t get bogged down with creating overly detailed plans, fooling ourselves that if the plan is more precise, then it follows that it’s more accurate. As Dean mentions above, SAFe provides mechanisms for estimating and planning which have shown themselves to be more reliable than those historically applied with traditional methods.

InfoQ: What's your advice to achieve success with an agile transformation?

Leffingwell: Transformations like this succeed only when the leaders truly lead. As Deming notes “they must know what it is they must do.”

Knaster: I couldn’t agree more with Dean’s statement on the role of leaders for agile transformations. In my experience, leaders are the single most important determinant of success. Implementing transformative change, such as moving to a new lean-agile way of working, is a significant effort for any enterprise and carries substantial risk. We have a simple mantra, that if followed usually results in success: “Train everyone and launch trains.” While that phrase may be overly distilled, it’s memorable and is the basis for the ‘Implementation Roadmap’ that was first introduced in our book. This roadmap describes a series of twelve steps, or ‘critical moves,’ an enterprise can take to ensure an orderly, reliable, and successful SAFe rollout. This roadmap compliments the seminal work of John P. Kotter and addresses each of his eight steps to leading change.

InfoQ: What can be done to support continuous improvement in enterprises?

Knaster: Continuous improvement begins with a mindset change, where every person in the organization is dedicated to relentless improvement and better outcomes. Relentless improvement is a pillar of the SAFe House of Lean, where lean-agile leaders provide a continuous sense of urgency for change and improvement, and exhibit the same by their own behavior and actions. Individual team retrospectives and inspect and adapt events for ARTs and value streams are the cornerstone of relentless improvement. In addition, SAFe provides a variety of possible lean metrics, as well as self-assessment worksheets for each of the SAFe levels. There are many other ways that SAFe supports relentless improvement. For example: Advanced training for Scrum masters and release train engineers, adopting built-in quality practices, implementing a lean-agile center of excellence and communities of practice establishing lean-agile portfolio management and agile HR, value stream mapping and so on.

Leffingwell: ‘Relentless improvement’ is a pillar of the SAFe House of Lean and is thereby integral to everyone's mindset. Specific practices help instantiate this. For example, in addition to the team’s iteration retrospectives, we do SAFe’s large-scale Inspect and Adapt workshops after every program increment. It is a significant and planned event where teams and managers get together and do true root cause analysis and corrective actions planning for whatever issues they are currently facing. They leave each meeting with a list of actions that they build directly into the program backlog for the next day’s planning event. That way relentless improvement is somewhat programmatic. Inspect and adapt is like a team sprint retro on steroids.

About the Book Authors

Richard Knaster is an author, SAFe Fellow and Principal Consultant at Scaled Agile, Inc. He has more than 30 years’ experience in software development in roles ranging from developer to executive and has been involved in lean-agile development for almost two decades.

Dean Leffingwell is an author, serial entrepreneur, and software development methodologist, who is widely recognized as a leading authority on software development. He is the creator of the Scaled Agile Framework, and author of numerous books on software development