SAFE 4.6: Improvements Direly Needed

2018 11 02 head

It is official.

The power engine of the SAFe 4.6 vehicle is the team and technical agility. View the SAFe for more information [1].

It is one of their five Lean Enterprise competencies and one of their four core values. SAFe finally recognizes the tremendous importance of technical proficiency and craftsmanship.

They advocate two findings. First, you need team agility, how you apply Scrum or Kanban.

In other words, being agile instead of doing agile. Second, you need technical agility, how you develop a quality product.

I challenge you. If you are following SAFe, talk with your teams and checks how many of their official good practices are you using on a daily basis.

I have seen SAFe introductions in Swiss, German and Czech companies. Attention was set on the structure of the release train. A lot of effort was spent on the various ceremonies, meetings and artifacts. But how to produce quality software and apply technical excellence was sadly always an afterthought. And more than once a senior SAFe coach just publicly stated that the SAFe core value x is not so important for a successful introduction. Quite a denial approach of his own methodology, I think!

Be honest with yourself and your teams, either you implement the techniques described in Technical Agility and[Build-In Quality] chapters of SAFe or you are not agile and have no SAFe power engine. It is called cargo cult.

A good starting point is the five dimensions of build-in quality described in SAFe 4.6. And yes now SAFe acknowledged the tremendous importance of a[continuous delivery pipeline]. Experts agree you can apply DevOps only if you have continuous integration, delivery, and deployment.

Once you realize where your organization stands remember that build-in quality is one of tour core values of SAFe. That I mean is walk the talk.

And please read some Internet blogs and books about LeSS, Software Craftsmanship, Extreme Programming, TDD, ATTD, clean code. Most of these concepts were defined and published in the last millennium. It is time your teams finally adopt them and produce high quality, maintainable and cost-effective products. This is the whole concept of the lean movement. And I welcome the fact that SAFe now explicitly mention[Cost of Delay].

One of the strengths of SAFe is their clear statement that an agile organization transformation is only successful with lean-agile leadership. All C-level managers are trained in lean and agile, they advocate these approaches and are visible champions. Therefore, all managers shall advocate technical excellence on a daily basis.

If not, the seminal work of John Kotter clearly states the transformation will fail. You will have a bunch of Scrum teams in your development department, but have none of the expected synergies at the product or company level.

Personally I prefer the LeSS approach, but I respect your choice - SAFe, Nexus, or Scrum@Scale - as long as technical excellence is a key aspect of your agile strategy. Embrace technical agility and do not let your train of teams produce mediocre software every two weeks.

Employ professional software craftsmen and deliver quality products. Follow your SAFe approach, respect one of the[four core values] and one of the five core competencies of your method.

See also my blogs Pragmatic Craftsmanship, Software Quality Graal, and How healthy is your Product? article series for information about technical excellence.

The other big improvement is that the PI horizon is now limited to 8 or 12 weeks. No more semester or hopefully quarter cadence.

It still does not make sense to plan for three months and at the same time advocate DevOps and design thinking.

DevOps has a time horizon of days. It is waste to have huge quarterly PI gatherings and plans just to discard them after the next DevOps finding. You should probably just update your PI roadmap.

Call for Action

My call for action is fewer meetings and paper artifacts and more technical excellence. You want to sell excellent and well-designed products, not mediocre software.

1. scaled agile framework site has discarded the information for older versions of the framework. Try to find the news and the slides for version 4.6.