The Scaled Agile Framework (SAFe®) is an important and valuable advance in helping achieve agile at scale. Net Objectives is a gold partner with the Scaled Agile Institute and one of the champions of SAFe. We work with companies large and small companies all over the world and have helped them deploy SAFe successfully.
SAFe is not right for every organization.. Some are too small, some are already invested in their own approach, some can benefit more from lean thinking. Following SAFe is not as important as it is to apply lean and agile thinking to software development to realize value across the organization. We have been doing that for years in our coaching practice. SAFe has done a good job of integrating this thinking into its framework – and that is part of what drew us to SAFe.
We come across many people who are considering SAFe and many folks who know they don't want to do it. But the question - "should I do SAFe?" - often confuses the issue. The real question is what should one be doing. We have found it useful to use the insights of SAFe as a baseline for adopting whatever works best for your organization. You will find that its Lean and Agile mindset, provides insights into essential practices. See Not Doing SAFe? No Problem. Not Doing These? Big Problem.
After touching on these mindsets, I want to look at the outcomes you should expect and the practices you should use when following these mindsets. The approaches that work, such as SAFe, will have all of these.
For 15 years, we have been helping companies adopt Agile practices at all degrees of scale. In this work, we have found three mindsets to be essential to success:
Systems thinking tells us to take a holistic view of our work. Starting at the team level and trying to scale up does not work. Starting at the top and implementing Agile through a command-and-control structure does not work. Using one approach, such as managing queues alone does not work. In fact, it is never sufficient to focus on only part of the value stream or one technique. Doing so produces sub-optimal results that do not scale. You must focus on culture, structure, leadership, and technical practices.
Lean thinking complements systems thinking. It is the long term focus on applying lean principles to software development. Lean thinking focuses on reducing waste all along the value stream, creating processes that need less human effort, less time, and deliver product and services at less cost with fewer defects. The goal of Lean thinking is delivering business value more quickly all across the value stream (system).
Having high-quality code is important. Essential. It must be a fundamental value. It can never be acceptable to deliver code that doesn’t meet quality criteria in order to meet delivery dates. This is summed up in a common saying in SAFe: “You cannot scale crappy code.”
These mindsets should result in several important outcomes. While SAFe is designed to achieve these outcomes, whether you are using SAFe or another Lean-Agile approach, these are the outcomes you need to achieve expect.
Focus on delivering business value quickly. Agile should be about incremental business delivery not team iterations. The cornerstone for this is to have product portfolio management drive programs which drive the delivery of Minimum Business Increments (MBIs) which drive the teams’ work. This is a fundamental structure of SAFe and the most readily identifiable characteristics of the SAFe big picture.
Driving from business value requires release planning to be done from the perspective of the business value to be delivered (MBIs) not on stories completed. This avoids many of the problems many Agile teams have of trying to align stories to achieve business value. Instead, the focus is on the business value throughout the process.
One of the best approaches to improving the effectiveness of a software development or IT software organization is to stop overloading the teams. Working on too many projects and on projects that are too large always overwhelms teams, making them much less efficient and therefore tends to keep the pressure to overload high. Having development/IT organizations work on the right amount of work, where they have the right people to work on the projects, can vastly improve the organizations effectiveness.
Using Kanban to manage WIP at the front of the value stream is an effective way of avoiding overloading the development teams. It forces business stakeholders to truly sequence the work items they are requesting as well as encouraging them to look at the truly important aspects of those requirements.
It reminds me of something Eli Goldratt, the creator of the Theory of Constraints, said: “Often reducing batch size is all it takes to bring a system back into control." -
Lean suggests we must manage our work-in-process (WIP) in order to be effective. To manage WIP, it must be visible. Visibility is not merely how much WIP we have but where did it come from and what value will it deliver when it is completed. SAFe creates visibility in process and workflow. First, the framework itself spells out how work is to proceed. Second, as requirements are elaborated, it is always kept clear which epics features came from and which features stories come from. This creates a line-of-sight back to the original business value being achieved.
High code quality is critical for sustainable development. This requires test-first approaches, automated testing, continuous integration and many other XP practices. In particular, adopt Acceptance Test-Driven Development (ATDD). This is one of the highest returns for the lowest cost set of practices you can do.
Cadence means that every team follows a regular beat of work. Both Scrum and Kanban based teams use cadence. In Scrum, sprints enforce it while in Kanban, teams must add it. Cadence lowers variability because one regularly gets an indication of where one is. If you have all teams be on the same cadence, you create the opportunity to synchronize at the cadence point. Synchronization is critical, because without it, it is very likely teams will get out of alignment with each other. Their agreements will be misunderstood and this will only be discovered later – during integration. Continuous integration is a kind of synchronization on a continuous (or at least daily) basis. But aligning every other week is still useful and more often than most large companies do. Cadence and alignment is central to the rhythm of SAFe: “Develop on cadence, deliver on demand.”
There are often architectural initiatives that are important but have no business sponsor. Architectural issues are often like orphans having to beg for food. Elevating architectural initiatives to the business level by allocating a set percentage of investment enables organizations to make better, long term, decisions on how to improve and maintain their overall architecture. Most organizations eventually come to this conclusion on their own, but only after significant degradation of their systems. SAFe realizes this by calling architectural epics “first class citizens.”
The owner of the development value stream plays a critical role in managing the Business evolution of the system; that is, this role ensures the system is oriented around quick delivery of Business value increments. The owner is responsible for maintaining the functional integrity of the system throughout its development and deployment. Those organizations that have this role often call it a program manager. In SAFe, this is called the Release Train Engineer (RTE).
Structuring people into teams where they can work together is a very powerful Agile practice. However, it is not always possible to create cross-functional teams and it is not always advisable to have people limited to working on one team. Looking at lean flow can assist in changing the structure within which people work to be much more effective. This is an area where Scrum and the Kanban Method have become fairly myopic, one insisting on what is often not possible and the other ignoring the issue entirely.
For more on this, see my blog post series: Cross-Functional Teams Eliminate Waste and Manifest Lean, Creating teams when it does not seem possible and Attending to teams is important.
While an organization does not have to start with an “all-in” mentality, picking teams without considering the big picture can have adverse consequences while not addressing the real questions of how to achieve Agile at scale (see Successful Pilots Can Sometimes Harm Agile Organizations). SAFe allows for starting with one value stream and takes an organization forward while raising all of the issues that must be considered in order to achieve Agile at scale. For more, see What to Look at When Starting an Agile Transition.
The mindsets lead to some essential practices. Every effective Lean-Agile approach, including SAFe, incorporate these practices. This section highlight three important practices you should expect.
Continuous learning is an essential concept in Lean thinking. In Lean, learning is an intentional discipline that requires that the group understand how they are all working together. Plan-Do-Study-Act (or Plan-Do-Act) is a common rhythm for continuous learning in Lean thinking. It is greatly facilitated by making explicit the workflow and decision policies that the group is using. That is the basis for effective communication.
Kanban is based on continuous learning. It naturally uses explicit workflow. It requires explicit decision policies in order to adjust. Classic Scrum tends to use a more reactive, “inspect-and-adapt” approach. To make Scrum effective requires adding this intentional and explicit approach to continuous learning.
SAFe incorporates this practice by using Kanban appropriately at several levels and can use it even at the team level. The SAFe “Inspect and Adapt Workshops” add the needed discipline to Scrum in a regular cadence of demonstration, qualitative measures, and problem solving.
Managing delays in workflow and in achieving feedback are cornerstones of a Lean-Agile approach. Effective practices to achieve this are having multiple teams share backlogs. This may be those sequenced at the same time and then split up, or even maintained as one backlog over time. These backlogs can also drive team structure (see the earlier desired outcomes relating to teams). Attempts to achieve coordination via a Scrum-of-Scrums approach by the teams themselves has a dismal track record. Scrum of Scrums with Product Owners works a little better if they are aligned from a higher vision.
SAFe provides an aligned view by having features that the Product Owners are considering being driven by product portfolio management.
Decision making should be de-centralized wherever possible. In particular, when decisions are frequent, time-critical, and do not have any real economies of scale, they should be pushed down to the people they will effect as much as possible (including the people themselves).
No matter what size the organization, certain outcomes are always required. When an organization is under 25 people, a team-based approach works well. From 25 to 100 people, a program-level approach may work. But after that, an approach taking a holistic view across the portfolio of the organization is required. SAFe is one way to achieve Agile at scale these larger organizations. It helps assure that the outcomes will all be achieved.
As always, no matter what your size or context, please contact me if we can be of any assistance.
CEO, Net Objectives