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 and 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 Build-In Quality 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 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 are 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. And 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 advocates these approaches and are visible champions. Therefore all managers shall be 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 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 semesterly or hopefully quarterly cadence. It still does no 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.
My call for action is less meetings and paper artifacts and more technical excellence. You want to sell excellent and well-designed products, not mediocre software.
No comments:
Post a Comment