Better SAFe than Sorry

23rd of June 2016

In the world of consultancy, there is an argument to be made for doing lunch with former colleagues. Working for a consultancy firm, a consultant is quickly indoctrinated into the corporate strategy and approach of that particular firm. It is in the best interest of a firm to devise a common methodology so to present a unified view towards existing and potential customers. However, even with best R&D efforts, tunnel vision is a risk to the consultant. That’s where these lunches come in, as they help expose you to the tunnel vision particularities of other firms, and to come into contact with something different and new. The lunch I had last week exposed me in such a way to the Scaled Agile Framework (SAFe), a framework built on the following core values: Alignment, built-in quality, transparency, and program execution.

 

The website hosts several pages dedicated to their core principles, nine in total. These, as is stated on the Wiki page, are heavily based on Agile and Lean paradigms, and are as follows:

  1. Take an economic view
  2. Apply systems thinking
  3. Assume variability; preserve options
  4. Build incrementally with fast, integrated learning cycles
  5. Base milestones on objective evaluation of working systems
  6. Visualize and limit WIP, reduce batch sizes, and manage queue lengths
  7. Apply cadence, synchronize with cross-domain planning
  8. Unlock the intrinsic motivation of knowledge workers
  9. Decentralize decision-making

The first principle talks of an economic view where we align all development of capabilities with the “economics of the system builder’s mission”. This is similar to the BPM imperative to align with the business strategy of the enterprise. The framework correctly identifies the issue that this strategy is usually not widespread knowledge in the corporate population, and the burden it places on the hierarchy of decision makers as too many decisions are needlessly escalated to a level where they have this more complete view. The principle translates into a combination of the Agile statement “Deliver Early and Deliver Often” combined with the Lean value stream assessment of matching value to development expense, risk, cycle time, and product cost.

The second principle is the application of the lessons W. Edward Deming. Since so many disciplines are built on his tenets, I can‘t really disagree. Then again, this principle is sound, but not really a differentiator for the framework, just a solid best practice all around.

The third principle plays on progressive insight a team will acquire when developing a system or solution. During the run time of a transformational process, such as the development of a new solution, it is hubris to think we can capture and predict all possible answers. These usually come later in the product development life cycle. So, the framework suggests keeping all possible solutions open and at various points during a project, to whittle them down till only the one choice remains for the remainder of the project. This approach can also be used for individual building blocks within a solution, or on an even higher level of detail.

Principle 4 is the straight-up use of iterative development. Sprinkle this Agile approach with the Plan-Do-Check-Act (PDCA) mindset at several points in the development progress to ensure at each of the iterations is achieving its potential. Each of the iterations should aim for a viable solution to create value early on in the project, without having to wait till the end of development. In larger solutions, the integration points become an important factor in this constant evaluation. In my personal experiences, it is indeed always the integrations that represent the largest technical risks of projects.

Coupled to the fourth principle, the fifth principle states that we need regular milestones and preferably accompanying demos to showcase the economic viability of the solution under development, and that the evaluation of this viability is to be done as objectively as possible. This should mitigate the most common critical mistakes project of a certain size have to endure, such as for example the creation of large sets of requirements, code, test scenarios and other deliverables solely based on up-front decisions.

Principle 6 is taking charge of your capacity planning in a visual way so to detect possible overcharging of teams. Sharing this visualization with all stakeholders so that all are aware of bottlenecks and overloads that can happen. Once this is known, actions can be taken to balance out the work and optimize the resources available to the project. This is not a trivial exercise, and one that should be performed with due diligence and tenacity. Too often, this sort of exercise is thrown overboard when a project team experiences crunch time near an important deadline.

This flows over into principle 7 where cross-domain planning should be endeavored at regular intervals in what the framework defines as a Release Planning Event. All stakeholders should assess the present state of the project, realign on a common vision and plan the next iteration of development. Similar to Scrum, I am a bit weary when only one sprint in the future is planned. It is good to have a vision of the end goals, and at least a brief outline of how your sprints will stack up to get there. At this planning event, a rearrangement of this stack of sprints can still be reassessed as well to fit the current state of affairs. This becomes especially pertinent when other projects, which need to align their proper planning with yours, occur in parallel.

Motivation is the key for a successful project and your knowledge workers are usually beyond the point where money incentives play a large role. Principle 8 states this simple fact, and it is a topic on which I already spent some thoughts.

The final principle is to take decisions on the proper level, and avoid unnecessary escalation to levels where the needed context is no longer common knowledge. It is a good idea to draft up a decision framework at the start of the project, much like a communication plan, in order to clearly indicate what needs to be decided on which level.

With the limited amount of information on the website, it is clear that I’ve only put my toe in the water about this subject, but it is already clear to me that there is wisdom to be gained from studying it more closely. A quick search of Amazon has revealed a book which goes more into detail, and thus I have added it to my TO-READ list: “Scaling Software Agility: Best Practices for Large Enterprises (Agile Software Development)” by Dean Leffingwell.

Thought EA Business Architecture ALM