Scrum: SAFe Considerations

Scrum was introduced to address the unacceptably high failure rate of software projects. (The annually published CHAOS Report by the Standish Group publishes data  on the success rates of IT projects. It was started in 1994 and at that time reported that a startlingly low 16.2% of IT projects are successful). Software development projects can have highly unpredictable outcomes due to the complexity of the problems being addressed and because they often have goals that change over time. Scrum is based on Empirical Process Control supported by the principles of Inspection and Adaptation. Empirical simply refers to an approach to problem-solving based on experimentation. An empirical approach is necessary for work that is not easily amenable to analytical or predictive planning. In this type of work it is typically not possible to know in advance all of the required input variables, or all of the relationships between input variables and outcomes.   Examples of this type of endeavor include software development, scientific research, economic forecasting and perhaps police detective work.  In these cases, planning is ideally based on an adaptive approach as opposed to an analytical or predictive one. Cause and effect may only be obvious in retrospect, and thus progress is best made by solving one small problem at a time, learning as much as possible from those results, and then building incrementally on that learning, adapting both process and the solution itself along the way.   Contrast this with, say, the problem of building construction where the design, required materials and labor needs can be completely specified up-front – this is an example of the analytical approach. Scrum is a system of short inspect and adapt cycles (or fast feedback loops) based on the PDCA (Plan-Do-Check-Adjust) cycle of Deming. Progress is made by only focusing on a small set of details within a narrow time-box, or iteration, called a sprint, at the end of which both the resulting product increment and process are inspected and appropriate adjustments defined for implementation in the next cycle. 

Think of scrum as a set of PDCA (Plan-Do-Check-Adjust) cycles, where the plan, the product and the process are constantly inspected and adjusted in order to arrive at the best possible solution:

The scrum framework is usually represented in a diagram like the following:

The official definition of Scrum by Ken Schwaber and Jeff Sutherland is documented in The Scrum Guide, and  runs to a grand total of 13 pages. Scrum is intended to be a customizable framework, not a prescription (“there is no methodology” says Sutherland), and The Guide studiously avoids all references to techniques, methodologies, tools or tactics. In particular, there is no mention of “user stories”, and the authors instead use the term “backlog items” for the work of a scrum team. This is indeed a perfect abstraction since it sets up scrum as a framework for almost any endeavor, not only software development. The authors define scrum as: “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value”. And that, “specific tactics for using the scrum framework vary and are described elsewhere.” Hence, nowhere in the Scrum Guide will you find any reference to User Stories, TDD, BDD, test automation, or continuous integration (let alone architectural runways or release trains, which we’ll get to later). These are considered to be tactics, which may or may not work in all situations, and hence have been appropriately omitted. The 13-page Scrum Guide is devoid of practices, methods or tools, and is instead devoted to defining a framework comprising 3 roles, 4 events and 3 artifacts. The intention is that scrum teams use this basic framework to evolve and improve, iteration by iteration,  a set of practices and methods that works best for them and whatever they are trying to accomplish. 

It is unfortunate that the scrum lexicon has been infused with terms like ‘velocity’ and ‘sprint’, as these can imply that scrum is primarily about speed of execution.  Scrum’s mechanisms for inspection and adaptation are what enable it to satisfy customers through early and continuous delivery of valuable software, while at the same time providing the flexibility to absorb changing requirements in support of a customers pursuit of competitive advantage.  

The Scrum Framework comprises four fundamental events which are an integral part of it’s PDCA cycle: Sprint Planning, Daily Scrum (or Daily Stand-Up), Sprint Review and Sprint Retrospective. Many teams include a Backlog Refinement event on their sprint calendars, which is an essential process for getting backlog items to a state of readiness for implementation, but is not considered one of the key events of scrum, as it may not be necessary in all circumstances.

SAFe Considerations

With SAFe, the practices required to plan and execute fully integrated product increments are encapsulated in an outer program loop that has its own set of practices, devoted to delivering the PI objectives. The program-level practices serve the same purpose as those at the iteration level, except that they are focused on maximizing the value output from the entire release train. Like scrum, the SAFe program level runs as a PDCA cycle, with its own Inspect and Adapt (I&A)  activities. It is not represented like this in the SAFe literature, but is intended to operate in a similar way:

At the program level, SAFe is a PDCA loop that delivers product increments based on the integrated output of multiple collaborating teams. Like scrum, check and adjust plays a central role in the process, where the plan, the product, and the process used to develop it are continuously reviewed and improved. 

In SAFe, the final iteration of each Program Increment is devoted to Innovation & Planning (IP).  The IP iteration culminates in an Inspect & Adapt (I&A) event which includes a demo of all of the objectives delivered in the PI, a scoring of those objectives by business stakeholders, and finally a PI retrospective and problem-solving workshop. This I&A event is the program-level equivalent of scrum’s sprint review and retrospective activities, and serves the same purpose. The event takes place typically on the last day of the IP Iteration, which is the day immediately before the PI Planning event for the next PI. Inspect and Adapt (I&A) activities also run throughout the Program Increment as a faster inner loop to ensure a timely reaction to problems or opportunities as they present themselves.  

Here’s a link to The Scrum Guide.