Agility at Scale and Lean Software Development

1. Introduction

I have just finished writing a new book about the lean approach to digital transformation, where lean and agile software development methods receive a fair amount of attention. This has led me to read about SAFe and revisit my opinions about the best ways to perform Agile at scale. SAFe (Scaled Agile Framework) has become the de facto standards for agile at scale, but there exists a large amount of controversy and debates about SAFe. On the one hand, SAFe addresses a real complex question, which is how to scale the Agile Manifesto’s principles, with software development programs of more than 100 or 1000 team members. SAFe has been around for more than ten years, with constant enrichment and improvement. Most large companies that are not software product companies are using either SAFe or something similar for their Agile practices. On the other hand, there has been a lot of warnings and quite negative opinions, such as the famous quote from Martin Fowler who sees SAFe as a poor and dysfunctional version of Agile for companies who do not have an agile mindset.

I do not have much first-hand experience with SAFe (and keep in mind that SAFe is fast evolving so early opinions need to get revised), but I have been trying to address agile at scale for close to two decades. Like most in the “large-companies agile community”, I have looked at Spotify for sources of inspiration. Over the years, I have experimented with “scrums of scrums”, “multi-squad planning meetings”, “chapters and guilds”, “backmaps” (hybrid between roadmaps and backlogs) and many tools or rites that could be easily replaced today with those from SAFe.  When I read comments from Agilists that there is no reason to scale, I find myself clearly in the “SAFe camp”: large companies do manage large programs, large information systems or large products, with many external stakeholders, that make all the questions found in the SAFe introductory books very relevant. At the same time, I have evolved my vision of agile development with lean roots over many years of practice and observations, but I have a hard time qualifying the overall SAFe philosophy of software development as “Lean Agile”.

SAFe is a development framework which, in my opinion and those expressed in “SAFe : A Collection of Comments from Leading Experts”, fights the VUCA nature of the world and proposes a very structured, detailed and rigorous method to deliver value through software development. The need to constantly learn from the (user) environment and to adapt is here, but it is nicely “boxed into steps”. There are iterations everywhere, but they fit squarely into a big sequential and hierarchical design. SAFe claims inspiration from almost all recent product development frameworks, from Lean Startup and Lean UX Design to DevOps, including all kinds of Agile and Lean software practices. These are all great sources of inspiration, but the result may be overloaded, with a loss of sight about what really matters for a “Lean Agile” approach: customer satisfaction and continuous learning. From a “Scaled Lean & Agile” perspective, SAFe gives you the bones, but not the flesh for your software development culture. If you read SAFe books with a digital product perspective, the intricacy of learning from observing and listening to your users seems lost, the critical role of user experience design is not tangible.  If you read them with a Lean software perspective, you find surprisingly few mentions of software realities and issues. Somehow, my opinion in this debate about SAFe is closer to Ron Jeffries post “SAFe- Good But Not Good Enough”.

This post is organized as follows. The main topic is the review of “SAFe 4.5 Distilled: Applying the Scaled Agile Framework for Lean Enterprises”. Because SAFe is a very rich and complex framework, this section only provides an overview. SAFe is a framework designed to address scale and flow when developing in an “agile mode” for large products, projects and program. It proposes a multi-scale decomposition with the relevant vocabulary, tools and rites, such as the famous “PI (Product Increment) planning”. I will address the depth of the lean roots in SAFe, as well as the influence of Lean UX Design or Lean Startup. The third section talks about two other approaches for scaling Agile : LeSS and Disciplined Agile. I will also use two short book reviews to support these simpler analyses of alternate scaling methods. Interestingly both approaches also portray themselves as “Lean Agile” methods. LeSS is mostly about scaling Scrum and is rich with insights and practical considerations about customer satisfaction. LeSS is the most visibly “product oriented” approaches of the three. Disciplined Agile is strongly focused on the integration of Agile, DevOps and scaling with … discipline, which makes it a close cousin of SAFe. I will conclude this post with a short comparison with my own approach of “Lean Software Factories”, which is more focused on what “Lean Agile” means for the software development squads (i.e., without scaling).              

2.  A Short Glance at SAFe

As told in the introduction, SAFE (Scaled Agile Framework) is a rich and complex framework that has evolved through the years. I have decided to use the book from Richard Knaster and Dean Leffingwell, “SAFe 4.5 Distilled : Scaled Agile Framework for Lean Enterprises” because it proposes a comprehensive presentation of the framework, because it is one of the most popular book about SAFe and also because it addresses the relation with lean in its title.  The latest edition, SAFE 5.0, was released this year, while SAFE 4.5 was released in June 2017, however this does not matter much since I will only brush the surface of SAFe principles and ambitions. SAFe was developed “by and for” practitioners, with the intent to “scale lean and agile software development practices”.  As the title of the section says, this blog post cannot deliver a summary of SAFe : not only is the book long, but it is very often shallow and points out to further readings, because SAFe is a syncretic collection of practices. I will only give you a personal summary of the key tools and principles, together with my own understanding, trying to address the questions stated in the introduction. Obviously, I want to be very clear here, this summary is biased with my own opinion, which is that SAFe is a useful framework for scaling, and a poor software development methodology (so you should bring your own). As you will notice, the first three sub-sections are very positive about SAFe and the next three are definitely more critical, although what you plan to do with SAFe really matters here : there are many kinds of programs and products for which my own interrogations are less relevant.

2.1 Scale & Flow

SAFe is foremost a framework designed to address scale issues and to maintain flow while the scale grows : “The secret to successfully implementing SAFe is to establish a continuous flow of incremental value delivery based on continuous fast feedback and adjustment. Continuous flow enables quicker value delivery, effective built-in quality practices, constant improvement, and evidence-based governance”. As a lean practitioner, I applaud the recognition of the importance of flow and I fully subscribe to the introductory principles : “ The principles of flow are an important part of the Lean-Agile mindset: Understanding the full value stream Visualizing and limiting Work in Process (WIP), Reducing batch sizes, Managing queue lengths ”. It should also be stated that SAFe is NOT a strict set of processes, rules and methods. It claims the lean definition of a standard that the team, the organization, the company (remember the “at scale” approach) must appropriate and revisit and customize if necessary : “Agile processes in frameworks like Scrum, Kanban, and SAFe do matter. However, a process is only a means to an end. When you’re captive to a process that isn’t working, then you may know what you’re doing, but ‘what you are doing’ may not be working. So, favor individuals and interactions, then modify processes accordingly”.

Scaling Agile starts, quite logically, by reviewing the Agile Manifesto principles and wondering if these principles scale, that is, keep being practical when the software organization grows. The position of the authors is largely positive: “The conclusion from this exercise is that the Agile Manifesto does indeed scale. However, many principles require increased emphasis at scale, while others require a more expanded perspective”. The principles that are identified as being the most “scale sensitive” are: (2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage, (6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation and (11) The best architectures, requirements, and designs emerge from self-organizing teams.  Welcoming changing requirements does indeed require more discipline and method when it applies to a large software organization. The practice of Change Review/Advisory/Control Board has been around for a long time, for good reasons. Building large systems that support the agile philosophy of welcoming changes requires modular architectures (to simplify the infamous feature interaction problem) and disciplined practices, which is what SAFe addresses. Similarly, face-to-face interaction is a key agile practice, that requires method to scale. Frameworks such as SAFe are born from practitioners who have experimented with methods and tool to conduct large-scale synchronization meetings, such as the PI planning events. It is also clear that the need for constant feedback does not fit easily with scaling: “Most are certainly willing to comply with the spirit of this concept. However, there are limitations on the economic practicality and convenience of daily onsite feedback from customers of large programs, though we fully agree with the sentiment”. I would actually disagree with the authors, although it more complex to organize, user feedback is required to breed lean & agile development. The last question identified here, the scaling of continuous architecture, is indeed hard to solve. SAFe at the same times advocates for continuous, emergent architecture that co-evolves with the development process, but uses a multi-scale hierarchical decomposition that may seem both too rigid and traditional for a VUCA world.

2.2 Multi-scale approach

A foundation for SAFE is the multi-scale approach, with three separate levels: the teams, the agile release trains (ART) and the large solutions. This is a classical hierarchical decomposition (multiple agile teams organize into a train, multiples trains organize into a solution), with a  strong emphasis on decentralized decision making : “As Kennedy notes, and as decentralized decision-making (Principle #9) implies, centralized planning for significant solution initiatives is problematic. Simply put, the complexity is too great, and the facts change too quickly for a centralized planning function to be effective. In its place, SAFe provides for routine, cross-domain, face-to-face planning”. There are multiple claims that SAFe is influenced by “system thinking” throughout the book. As told in the introduction, I strongly recognize scaling as an issue that most companies must face, as is described in Robert Sutton and Ruggy Rao’s book : “Scaling up Excellence”.

Because the first level of the multi-scale decomposition is meant to reproduce the “Lean Agile squad” without the scaling issues, the contribution of SAFe is foremost the second level : “ The Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, develops and delivers solutions incrementally, using a series of fixed-length iterations within a Program Increment (PI) timebox … Each ART is typically a virtual organization (50–125 people) that plans, commits, and executes together”. The size of this second level is no surprise : there is a clear consensus about two sizes that matter with human organization:   the team size (the famous two-pizza rule) and the tribe size, which is linked to the army (starting with the Roman army) and the Dunbar number. The right size for the second-level organization should stay below Dunbar’s number (150) so that everyone really knows each other at this second level (from an emotional connection perspective). We shall see the same scaling pattern in the next section.

The third level, of large solutions, is another level of difficulty (precisely because members cannot know each other anymore) : “Building large-scale and complex systems is one of the most difficult and challenging endeavors today”. The heterogeneity of the workforce roles, as well as the (almost all the time at this scale) combination of enterprises and suppliers make for a different type of challenge : “Building these solutions may require hundreds, thousands, or even tens of thousands of mechanical, electrical, and software engineers, not to mention physicists, scientists, medical professionals, and other experts, along with the integral contributions of an extensive network of external suppliers”.  Large solutions are made of multiple ART, which contributes to multiple value streams. SAFe organizes large solutions with solution epics: “ Solution epics are initiatives large enough in scope and cost to warrant analysis and a Lean business case. Unlike capabilities, which can be split to fit inside a single PI, solution epics usually take several PIs to develop”. I will not address much this level of organization in this post, because of my lack of personal experience building software products with a thousand or more participants (this is not the same as running a thousand-plus organization delivering many hundreds-sized products or projects, which is what I am currently doing).

2.3 PI Planning

The heart of SAFe is how to apply the agile principles, including small steps, face-to-face communication and feedback to level-two organizations (ART). As told by Robert Sutton in Scaling Excellence, this requires synchronization. The most important SAFE Rite is the PI (Program Increment) planning : “This event is essential to SAFe: If you aren’t doing PI planning, then you aren’t doing SAFe”. The PI planning is a synchronization event for the different teams from the same train, so that they can work out their dependencies and synchronize their deliveries. This is the cornerstone of “agile at scale”: “the development of large-scale systems is fundamentally a social activity”.

The scaling from teams to train requires cadence (a common clock) and synchronization (leveraging to common clock to communicate and re-align ambitions). This is a key SAFe principle : “ Apply Cadence; Synchronize with Cross-Domain Planning”, following the advice from Donald Reinertsen : “Cadence and synchronization limit the accumulation of variance”.  PI planning are critical rites, which require careful organization (because of the large attendance) but delivers lots of value (as anyone who has experienced a successful PI planning event can testify): “Whenever possible, attendees include all members of the ART. After all, the people on the teams do the work, so only they can design the system, plan, and then commit to that plan”. One of the famous SAFE tools for PI planning is the program board : “ Typically, the RTE creates a program board in advance of planning and teams update it during planning. The board highlights the feature delivery dates, milestones, and dependencies among teams and with other ARTs”.

The only word that should get our attention in a VUCA world is “planning”. On the one hand, coordination at the ART level (level 2) requires planning and synchronization. Teams must say what they will do and, mostly, do what they said to their “train team-mates”. With the proper agile tools and concepts, the time horizon of a Program Increment (e.g, eight sprints) is short enough that planning works from a capacity view: “ Trains are predictable and can reliably estimate how much cargo (new features) can be delivered in a PI”. On the other hand, this does not tell the story of value creation, nor does it capture the possible complexities that may arise from developing a user story. To simplify (a complex issue), scaling does require planning of capacities and efforts, but the root of Agile which is to adapt constantly the delivery to the feedback of the environment still prevails (planning is not a tool to fight against volatility and uncertainty). For instance, the following quote: “The primary evaluation tool of the ART is a predictability measure that tracks the percentage of business value achieved for each PI objective in the plan” is a departure from agile principles.

2.4 Focus on Value and Lean Startup

The previous point is where most agilists start to disagree, as told in the introduction : the reliance on value creation as a control metric is a departure from the agile mindset and a return to last-century thirst for control (what Frederic Laloux calls “our beautiful illusion of control”). This contradiction is expressed with what the authors call “the economic view”: “Therefore, SAFe’s first Lean-Agile principle is to take an economic view, which is founded on two basic concepts: Deliver incrementally, early, and often. Sequence jobs for maximum benefit”. The idea that the future benefits are known well enough, with a reliable estimate, so that they can guide prioritization and decisions is too narrow for most VUCA situations. The authors quote Reinertsen about scheduling for maximum benefits: “Reinertsen describes an algorithm for job sequencing called Weighted Shortest Job First (WSJF). WSJF is calculated by dividing the Cost of Delay (CoD) for a job (i.e., the value not achieved while waiting) by the duration of the job”.  This works for lean manufacturing but is much harder to apply to lean software, because the cost of delay is most often unknown. For instance, this approach does not work for digital products and services, where value creation emerges continuously from usage. The discovery of value through usage and iteration is the heart of the Lean Startup approach, which makes the constant references to Lean Startup in SAFE confusing.

The authors make multiple reference to innovation accounting in their book : “Apply innovation accounting to establish early, nonfinancial, actionable metrics that provide fast feedback on the important elements of the solution’s new concepts, features, and its associated business model”. They quote Eric Ries on this topic : “Innovation accounting refers to the rigorous process of defining, empirically measuring, and communicating the true progress of innovation—such as customer retention and usage patterns—whether for start-up companies, for new productions, or business units within established companies.” In my opinion, and according to my previous experience of applying innovation accounting to digital products, the reference to innovation accounting is misleading : innovation accounting is a tool for managing the macro-iterations (at the PI levels) not for sequencing the backlogs “according to the economic view”.

An idea that is central to the book is that development (at all scale) should focus on value. No one could dispute this but understanding and considering the fact that value is hard to characterize and even harder to predict is what makes agility so relevant (versus waterfall approaches). Saying that all resource allocation decisions, at all scales starting from the portfolio down to the backlog prioritization, should be made from the value creation hypotheses, is definitely misleading. In a VUCA world, all value creation assumptions made before the product or the service is delivered … are just hypothesis (which is precisely the point of the Lean Startup approach).

2.5 Lean & Agile

SAFe claims to be a framework to scale Lean Agile, so it is fair to ask how much of the “Lean Agile mindset” is here. Deciding if SAFe is truly a lean approach is difficult. On the one hand, there is a strong lean “system thinking” influence, and many references throughout the book, such as “The foundation of Lean is leadership, the starting point of team success. The enterprise’s managers, leaders, and executives are responsible for the adoption and success of the Lean-Agile paradigm”. As said earlier, there are many lean principles stated in the book, such as “Operating a product development process near full utilization is an economic disaster” or “Faster Learning Through Faster Cycles”. On the other hand, for someone like myself who defines “Lean Software” from the reading of Mary and Tom Poppendieck’s books, there is surprisingly little software (software issues, software practices, software principles) mentioned in the book. SAFe offers a vision of lean which is very much system-based and lacks the relationship with the gemba (the code and the people). One could say that the « software » dimension of lean is what is done at the team level (hence visual management, kaizen or 5S are not covered here) … but I think that learning and system thinking practices need to scale.

The same comment applies to the agile roots of SAFe. As shown earlier, the principles of the Agile Manifesto are quoted multiples time in the book, with a deep appreciation : “The first phrase of the manifesto deserves emphasis: “We are uncovering better ways of developing software by doing it and helping others do it.” . Many practical pieces of advice, such as “favor working software. And document only what’s necessary”, tell of the SAFe’s agile heritage. At the same time, I see two potential problems (depending on your activities and what kind of software products you are building). First, there is a pregnant scale-hierarchy built into the roles: those who manage the bigger-size items are (or sound) more important than those doing unit elements. This is very visible with the over-emphasis about architecture and the small recognition given to technical excellence and software craftmanship (the influence of hierarchical system engineering is obvious). I would strongly recommend the reading of “Lean Architecture” from James O. Coplien & Gertrud Bjørnvig as way to balance the SAFe vision: “The SAFe concept of the architectural runway provides the means by which Agile architecture is implemented”. Second, there is the “control illusion” described in the previous section: the emphasis on planning, forecast, value creation … that can quickly become a burden when one wants to lead a true agile transformation, such as a digital transformation. To illustrate with a precise example, the book advocates for parallel design (set-based versus point-based) where experience shows that this really depends on the complexity of the environment (innovation accounting does not mix well with feature interaction).

2.6 One Framework to Rule them All ?

What is striking, when one reads this book or look at the framework schemas, is that SAFe claims inspiration from most product/project methodologies, such as Agile, Lean, DevOps, LeanUX, Lean Startup … as well as many management tools, from Daniel Pink’s motivation foundations or Kotter change management framework to servant leadership. Some of the complexity of SAFe comes from trying to reconcile a very structured, step-by-step, managed and controlled linear vision with the recognized need for iteration and adaptation : “ Even though Figure 9-2 seems to indicate a linear process, in reality, the pipeline doesn’t operate that way. Rather, it’s an overlapping learning cycle that occurs within every PI, which allows teams to establish a number of hypotheses, build and deliver against them, measure results, and learn from that work”. As a proponent of DevOps for many years, I welcome  statements such as “DevOps is the cornerstone of continuous delivery and enables the enterprise to economically develop and release small batches of functionality to the business or end user, providing faster feedback and time-to-market”, but the book does not tell much about scaling DevOps. The book to read on this topic remains “Accelerate – Building and Scaling High Performing Technology Organizations” by Nicole Forsgreen, Jezz Humble and Gene Kim.

It leads naturally to the opinion, expressed by some of the experts that I mentioned in the introduction, that “SAFE is too big, with too much content”. The attempt to squeeze approaches such as design thinking, lean UX or Lean Startup is not convincing. This yields an explorative, divergent, iterative step called “continuous exploration”, that fits into the large ART schedule : “Continuous exploration is the process of continually exploring market and user needs, and defining a vision, a roadmap, and a set of features that propose to address them.” Trying to fit everything on the same schedule does not convince me: I see the benefit of cadence and synchronization for software delivery, not for value delivery. I have written many time about the need for multiple time horizons and nested loops (as opposed to micro iterations within a linear process). Similarly, the books talks a lot about “building quality in”, which is fitting to the lean approach: “ Built-in quality is one of the four core values of SAFe. The enterprise’s ability to deliver new functionality with the fastest sustainable lead time, and to react to rapidly changing business environments, depends on solution quality”. However, the book contribution on how to improve software quality is shallow at best. Similarly, the reference to lean UX, “In short, the Lean UX cycle provides the knowledge that Agile teams need to adjust and redesign—or even pivot to abandon a feature—based solely on objective data and user feedback, enabling them to iterate toward a successful outcome”, does not bring much and one wonders why lean UX is invoked here. It actually highlights the fact that customer-centricity, a key principle both for lean and agile way of working is poorly represented here. Customer satisfaction does not receive much attention here, it is over-shadowed by value creation.

3. LeSS and Disciplined Agile

3.1 LeSS : Scaling Scrum to develop software products

I will now complement the analysis of SAFe with two other competing frameworks. The first one is LeSS (Large Scaled Scrum), a multi-team scrum framework designed to scale Scrum with teams of hundreds or even thousands contributors working on the same software product. The name also tells the intention to scale with less rules, less guidelines, less methodology than SAFe. To deliver my short introduction to LeSS, I will propose a short book review of “Large-Scale Scrum: More with LeSS” by Craig Larman and Bas Vode. Since this post is already quite long, I will simply focus on five key areas and attempt to compare LeSS with SAFe. “Large-Scale Scrum: More with Less” is a beautiful book, well-written and full of insights about scaling Agile, so I urge you to get your copy and give it your full attention.

Less is Large-Scale Scrum. Since Scrum is the de facto standard practice for Agile in most companies, it makes adapting LeSS a much easier proposition: “Large-Scale Scrum is Scrum—It isn’t new and improved Scrum. Rather, LeSS is about figuring out how to apply the principles, rules, elements, and purpose of Scrum in a large-scale context, as simply as possible”. The framework aims at keeping what makes Scrum easy to understand and to adopt. The emphasis is on transparency (using things that everyone can see as beacons), short cycles, working together and common definitions. There is a strong will to keep the framework simple and to avoid adding many roles to take scale into account: “We don’t want more roles because more roles leads to less responsibility to Teams. We don’t want more artifacts because more artifacts leads to a greater distance between Teams and customers. We don’t want more process because that leads to less learning and team ownership of process. Instead we want more responsible Teams by having less (fewer) roles, we want more customer-focused Teams building useful products by having less artifacts, we want more Team ownership of process and more meaningful work by having less defined processes”. LeSS is a Lean Agile methodology as is expressed, for instance, with two funding principles: “System thinking” and “empirical process control”. These principles, or should I say these words, are part of the SAFe book as well, but they have a different flavor here. System thinking is more concrete and applied to the product: “See, understand, and optimize the whole system (not parts), and use systems modeling to explore system dynamics. Avoid the local sub-optimizations of focusing on the efficiency or productivity of individuals and individual teams. Customers care about the overall concept-to-cash cycle time and flow, not individual steps, and locally optimizing a part almost always sub-optimizes the whole”. Empirical process control captures the heart of agility, which is, in my opinion, to constantly adapt to the customer environment: “Continually inspect and adapt the product, processes, behaviors, organizational design, and practices to evolve in situationally-appropriate ways. Do that, rather than follow a prescribed set of so-called best practices that ignore context, create ritualistic following, impede learning and change, and squash people’s sense of engagement and ownership”. Although this is out for scope for this blog post on scaled agile, it is worth telling that “Large-Scale Scrum” is a great book about Scrum, scrum masters, scrum communities and scrum tools.

LeSS proposes a scaling methodology with three levels. The first level is clearly, as was the case with SAFe, the SCRUM agile team. There are two additional levels (LeSS and LeSS Huge): groups of up to 8 teams, and assembling a large number of such groups : “ Large-Scale Scrum has two frameworks: LeSS for 2–8 Teams, and LeSS Huge for 8+ Teams”. The two levels, with a similar cut-over, should not be a surprise since we explained earlier that the difference between managing less than 100-150 people and more seems to be deeply rooted into our sociology and anthropology. The heart of scaling comes from the product structure: one product (one product owner team) and many product development teams (up to 8 teams). This works for LeSS and changes at the “LeSS Huge” scale where the product is divided into requirement areas (“Customer requirements that are strongly related from a customer perspective are grouped in Requirement Areas”) that are managed with a LeSS structure : “Each Requirement Area works as a (smaller framework) LeSS implementation, each working in parallel in one overall Sprint. We sometimes summarize a Sprint in LeSS Huge as a stack of LeSS”. Each requirement area follows the “four to eight teams” rule : “why does a Requirement Area have a suggested upper limit of eight teams? See The Magic Number Eight. What about the lower limit of four teams? Why not one or two teams? Naturally, four isn’t a magic number, but it strikes a balance so that the product group is not composed of many tiny Requirement Areas”. To manage the set of teams in the product structure, at all scales, LeSS uses a Sprint Planning which is not very different from the SAFe approach in its form, even though some of the intents are different because of the product focus. The planning belongs to the teams :  “Especially at scale with myriad different contexts and the need to improve, how Sprint Planning meetings are done in LeSS must be left up to the teams”. Sprint planning work very well when everyone can gather in the same space, but it can also be adapted to remote teams : “Multi-site—Use video, and offer items, using a virtual shared space. If questions, the simplest solution is to just talk together. If there are many teams and lots of items to discuss, try a diverging technique such as a chat tool with one window per item”.

LeSS is a product development framework. The move from project to product is a key transformation of software development methodology; it is a key foundation for Lean Software as defined by Mary Poppendieck. The authors tells how Scrum has also embraced this paradigm shift in the past years : “Luckily, this confusion is resolved. The Scrum Guide now states, “Scrum is a framework for developing and sustaining complex products” and eliminated projects. Does that matter? Hugely!”.  The focus on product is everywhere in the book, as the product is a key part of what defines the team : “Whole-product focus—One Product Backlog, one Product Owner, one shippable product, one Sprint—regardless if 3 or 33 teams. …  Your product definition determines the scope of your adoption, the content of the Product Backlog, and who makes a suitable Product Owner. Broader product definitions are advantageous, but your definition has to be practical enough to start”. The focus on product leads to long-term engagement, long-lived teams and patience. LeSS promotes technical expertise over project management skills: “LeSS requires technical excellence. Technology, team, and organizational decisions are strongly related and your coach needs to have this broad and deep perspective. Avoid people with no or limited technical expertise. These are often ex-PMI-project managers”. This is quite different from a project culture of assembling the right people for a short time and letting them go, it bears repeating and is illustrated by the LeSS requirement for the initial teams : “dedicated—each person is a member of one and only one team stable—the members of the team aren’t changed frequently long-lived—the team isn’t a temporary project team but stays together for years”. As told in the previous paragraph, the product organization scales with feature teams (and Requirement Area at the “huge” level). One product owner (either a person or a small team depending on the size) work with a set of feature teams, as peers (there is no hierarchy between the product team and the features teams). All feature teams operate in a continuous integration mode: “The continuous integration of all code across all teams creates the opportunity to cooperate by checking who else made changes in the component being worked on”.

LeSS is a customer-centric framework. The importance of customer-centricity – a key component of Agile – is much more visible in this book than the SAFe one. Many pieces of advice are given to enable customer-centricity and achieve better prioritization: “ Focus on learning the customers real problems and solving those. Identify value and waste in the eyes of the paying customers. Reduce wait time from their perspective. Increase and strengthen feedback loops with real customers. Everyone understands how their work today directly relates to and benefits paying customers”. LeSS acknowledges that customer-centricity is hard to scale (“In a small one-team product, organizing by customer value is trivial. The more teams, the more they become like cogs in the large development machine”). The feature team organization is designed as a tool to scale the focus on customers.

LeSS is a Lean Agile software development framework with clear lean roots. It makes “Lean Thinking” one of the founding principles: “Create an organizational system whose foundation is managers-as-teachers who apply and teach lean thinking, manage to improve, promote stop-and-fix, and who practice Go See. Add the two pillars of respect for people and continuous challenge-the-status-quo improvement mindset. All towards the goal of perfection”. As explained in the previous section, some of this could be found in the SAFe book (we find the same references to queues and work in process), but the importance of the gemba (people and code) is more visible. The same remark applies to the importance of continuous improvement: “A LeSS adoption ends only when you’ve achieved perfection and world domination. Without that, there are always things to improve. The job of managers is to build an environment in which teams continuously deliver and continuously improve. Preferably the teams themselves do most improvements, but managers and Scrum Masters are often involved for organizational and environmental improvements … —Here’s a perfection goal: Create and deliver a product almost all the time, at almost no cost, with no defects, that delights customers, improves the environment, and makes lives better. Do endless humble and radical improvement experiments toward that goal”. The guidelines that are provided to managers are deeply influenced by lean thinking : “Create an organizational system whose foundation is managers-as-teachers who apply and teach lean thinking, manage to improve, promote stop-and-fix, and who practice Go See. Add the two pillars of respect for people and continuous challenge-the-status-quo improvement mindset”. Even with the small set of quotes that I have included here, one can see that the LeSS emphasis is not on the framework or its methods, but on the product that is being build. LeSS coaches needs to be former doers: “Prefer hands-on experience. Ensure that your trainer/coach has hands-on experience in LeSS from both inside (as a team member) and outside (as coach). Avoid training providers who don’t care about who teaches, and avoid trainers with only theoretical knowledge. …  De-emphasize certification. Most certification of people and courses is almost meaningless. It probably doesn’t hurt, but certification is not a reliable guide”.

3.2 Discipline Agile : Scaling and improving agile development processes

I will now turn to Disciplined agile, which is often considered as the most natural competitor to SAFe. Disciple Agile started in 2015 and has scaled, with successive versions, to incorporate “disciplined DevOps”, then “Disciplined IT” and later “Disciplined Agile Entrerprise”. Disciplined Agile focus on people first and acknowledges the diversity of development life cycles. In a way that is similar to SAFe, Disciplined Agile claims inspiration from many sources such as Scrum, extreme programming (XP), SAFe, Spotify, agile modeling (AM), Unified Process (UP), Kanban, outside-in software development, and agile data (AD). Following the same principle as the previous section, I have selected “An Executive’s Guide to Disciplined Agile : Winning the Race the Business Agility”, by Mark Lines and Scott Ambler, as my path to describe DAD (Disciplined Agile Delivery) shortly in this blog post. Since I only selected four themes to feed my comparative analysis with SAFe, it is clear that I will not do justice to Disciplined Agile or to Mark Lines and Scott Ambler’s book.

Disciplined Agile is a “process improvement toolkit”, that is, a framework that can be used on many software development processes: “In many ways Disciplined Agile (DA) is very different from other process offerings. DA is a process improvement toolkit, not a process or methodology”. In a way that is very similar to Jurgen Appelo’s writing (cf. his great book “Management 3.0 – Leading Agile Developpers, Developing Agile Leaders”), complexity theory and system thinking play an important role in the proposed approach to scaling. Organizations are seen as complex adaptative systems, for which DAD uses to Cynefin framework to identify the “unknown unknowns”. I applaud the reference to complex system thinking, but I find the application to stay too much on the conceptual side. There are many pages about how to organize you governance, without mention of what kind of issues this governance should resolve. Similarly, the part about architecture is very generic. In a lean spirit, it would make sense to describe which problems architecture is trying to solve (such as modularity, open-ness with API, reactiveness, high availability and resilience, extensibility and unified data semantics, etc.). DAD is a transformation framework; it proposes a long journey towards continuous improvement. I quote here a long fragment from the conclusion that I like very much:

• Solution delivery is complex. DevOps is complex. IT is complex. Your overall organization is complex. What makes it even more challenging is that your people, teams, organization, and the world around them is constantly learning and adapting.
• No silver bullet. There are no quick fixes, no silver bullets, no one process or scaling framework to rule all regardless of the marketing rhetoric surrounding them. Every person, every team, and every organization is unique.
• It will take time. This is a multi-year journey. And when you have achieved what you perceive to be true business agility you will need to evolve to a long-term continuous improvement approach as everything around you will continue to change.
• It requires sustained investment. Achieving your transformation goals will take a material investment.
• It requires courage and commitment. Every single success story, every single one, starts with the organizational decision to do the hard work to get better. And every single one eventually recognizes that improvement is a way of life, not a project.
• Change must be pulled not pushed. You need to pull agility and discipline into your organization, you can’t push change onto people and hope it will stick.

Disciplined Agile is organized around seven principles: “Delight Customers, Be Awesome, Pragmatism, Context Counts, Choice is Good, Optimize Flow, and Enterprise Awareness”.  These principles reflect the pragmatism of the framework authors, the agile and lean heritage and a focus on system thinking. DAD embraces the preference for long-lived stable teams: “A very common trend in the agile community is the movement away from projects, and the project management mindset in general, to long-lived teams”. The fact that “Delight Customers” is the first principle is a good indication that customer-centricity received more attention than it gets with SAFe : “In 2001 the writers of the Agile Manifesto told us that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” This is a good start, but disciplined agilists prefer the lean philosophy that to succeed it isn’t sufficient to simply satisfy the customer but instead we must regularly delight them if we wish to keep them as a customer.” However, the customer-centricity claim stays as a principle and does not lead to the practical focus that is found in the LeSS book.

Disciplined Agile is a Lean Agile framework with many sources of inspiration : “DAD is an agnostic hybrid approach that puts proven strategies from Scrum, Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, SAFe and several other methods into context”. Similar to SAFe, DAD also claims inspiration from Lean Startup: “The toolkit includes support for multiple delivery lifecycles, including but not limited to a basic/agile lifecycle based on Scrum, a lean lifecycle based on Kanban, two modern agile lifecycles for continuous delivery, and an exploratory lifecycle based on Lean Startup”. Notice that there is no attempt to create a hybrid monster lifecycle that includes everything (including Lean Startup in a “continuous exploration” mode), which is definitely a good thing. Lean is often quoted as a source of inspiration for principles: “The 10th principle behind the Agile Manifesto suggests that “Simplicity – the art of maximizing the amount of work not done - is essential”. Similarly, Lean advocates regard any activity that does not directly add value to the finished product as waste”. However, when it comes to practical guidelines, such as those for the “Lean Change management cycle”, any lean practitioner will cry for the absence of any mention about the “gemba” (people and code). It is hard to imagine a lean software development practice without deep diving into what people do and which issues they meet. The authors explain that enterprise culture and organization need to evolve to match Disciplined Agile ways of working – this is definitely true, as was pointed beautifully by Jurgen Appelo or by Steve Dunning in his great post “How To Make The Whole Organizations Agile”. They use the wonderful book for Frederic Laloux, “Reinventing Organizations”, as a guideline: “ There are several important observations we’d like to make about Laloux’s organizational maturity scale: Green and teal align well with agile. For your organization to support Disciplined Agile it should at least be (mostly) Green, with a participative and values-based culture, or better yet Teal with a truly adaptive and aware strategy”.

Disciplined Agile is a framework for Agile DevOps. The integration of DevOps is what makes this book stand apart from the other two : many thoughts have been given to scaling DevOps practices, and this shows in the book organization, with a collection of schemas that will be useful to agile practitioners at scale. The emphasis on “discipline” becomes the vehicle to promote the scaling of unified development methods (something that my own experience confirms: the laissez-faire spirit about what “agile really means to you” works beautifully at a team level, but does not scale) and the fierce promotion of automation (hence DevOps). The larger the organization, the larger the benefits of constant, relentless and continuous automation. I mention in the introduction that the software giants such as Google, Facebook or Netflix do not use SAFe, but they do use DevOps and very large amounts of scripting and automation. Disciplined DevOps is a valuable framework for large enterprises: “Disciplined DevOps is the streamlining of IT solution development and IT operations activities, along with supporting enterprise-IT activities such as Release Management, Support, Security and Data Management, to provide more effective outcomes to an organization”.          

4. Conclusion

Before I conclude with what I take from these different reviews, it is worth telling briefly where I come from. As you may have found if you clicked on the URL links, the divergence of opinions about scaled agile is quite wide. You cannot have an opinion that is independent from your own experience as a software practitioner. I discovered the agile manifesto in its early day because of my past as an object-oriented language designer and my interest with software development methodologies in the previous century. I moved to Scrum in 2005-2008 when I had to scale my agile practices. I then moved from Scrum to DevOps when faced with the challenge of developing software for internet gateways and set-top boxes. The practice of Scrum+DevOps has led me to look into Lean Software development around 2010 and progressively define the “Lean Software Factory” ambition, which I refined progressively when I moved to digital products development at AXA Digital Agency. I have covered this lean agile software approach many times in my blog, but I have never written about scaling before this post.  Interestingly, there are two separate topics: what does lean & agile software development mean? and how do you scale this approach? I have given the first question a lot of consideration, but not much to the second although I have been faced with scaling challenges since 2005.

The short version of my conclusion is that SAFe is an interesting toolkit for scaling but should not be used as a lean agile development methodology. If you know what you are doing, you may derive great value from SAFe rites and practices, but If you follow the guide/books too closely, your are likely to get yourself back into 20^th century software development (not always a bad thing …). If I try to expand my concluding thoughts about these three books, here is what I would propose:

• I really liked the LeSS book, and the LeSS framework, but not everything is here. The lean (kaizen) and DevOps angles are missing from my perspective. The good news is that there are no incompatibilities between LeSS and the Lean Software Factory Principles, so using LeSS as a scaling framework works for me. What makes LeSS the best book of the three is the focus on software products. As told earlier, I believe that moving from projects to products is the center of lean software transformation.

• I liked Disciplined Agile for its DevOps integration. I also appreciate the flexibility to support multiple kinds life cycles. However, to me, this is only a companion book since it says too little about software development and stays at a “meta” descriptive level on too many topics.

• I would recommend SAFe for the practices at scale, such as PI planning, but definitely not as a development methodology. In my opinion, SAFe and DAD suffers from the same drawback of trying to integrate too many ideas and concepts from other methodologies. DAD does it with more grace, while SAFe tries forcefully to fit all the pieces together.

• None of these books do a compelling job to explain the value of combining lean and agile, nor how does it really work at the squad level … but this is not the topic of this post. 

I will end with a COVID-related note. There used to be a debate whether agile development required co-location. It is very clear to anyone who has experienced both, that colocation – of all team skills, but mostly of the product owner with the developers – works better. Multi-site agility requires more experience, more discipline, a strong set of common language, concepts and tools. “Remote agile”, however, has become a necessity for large-scale organizations because of geographic constraints. What we see currently is that “remote agile” may become a standard practice in a more general sense, when most software workers are required to work from home.