 |
| SAFe 2.5, Leffingwell LLC |
Originally I fell in love with the simplicity of having on one level sprints and on another über-sprints. We were building new releases of our product a few times a year and wanted to speed up. Also, we were having quality issues due to scope extensions and schedule slippage. Our story has been presented in this case study.
Version 3.0 made it more clear that we don't have a separate value stream for architecture and business. I guess it was also due to popular demand that the hardening was dropped from the end of the release period. I still think it was quite realistic and would be for an enterprise that is new to agile. Things don't become fully automated over night. I became certified SAFe Agilist during the 3.0 version.
 |
| SAFe 3.0, Scaled Agile Inc |
I had mixed feelings about version 4.0. I was really happy to see the Customer in the big picture for the first time, but adding yet another layer (Value Stream level) seemed like too much. That was probably mainly due to the fact that I weren't involved in such activities where so many layers would have been needed. In a way, I think it would be possible to add even more of these levels. After all, we are talking about scaling.
SAFe 4.0 was very handy when you hid the Value Stream level. Of course you need to make decisions based on economics in all cases and you want to apply agile architecture, but you can do it even if you don't have it in the big picture. Communities of Practice were also a welcome addition. You probably want to have some support groups for people who serve in similar roles. That's how you can benefit more from organizational level learning. During the 4.0 era I got certified as SAFe Program Consultant (SPC4.0).
 |
| SAFe 4.0, Scaled Agile Inc. |
As with previous changes and additions, the new version SAFe 4.5 brings both welcome additions and things that seem to be added mainly because they are current hype. The ability to customize your big picture: Essential, Portfolio, Large Solution or Full SAFe is really good thing. I bet many companies can do with Essential or Portfolio SAFe. But it's a good thing that the more complex versions are available too.
 |
| SAFe 4.5, Scaled Agile Inc. |
Then what I don't really like (this is my personal opinion), is the fact that SAFe is getting more bloated. I think in the core things are about scaling, cadence and transparency. The power triangle that makes a distinction between content, process and technical quality authority (PO, SM & Team or PM RTE & Architect). I see no need to add DevOps practices, Lean UX nor Lean Startup practices here. They are fine practices that I appreciate and use. But for example in teaching Leading SAFe course, they make things more complicated. Also, due to the fact that the slides covering those aspects don't really include much of instructor notes, I kind of feel those topics are still in an early phase.
Special rant from many of my trainees: THERE ARE WAY TOO MANY ABBREVIATIONS! MMF, WSJF, CoP, FAB, RTE, STE, CoD, CALMR, MTTR, WIP, CI, CD, CE, BUFD, MBSE, KPI, ROI (...maybe you get the point). Some of these are industry standards, but if you bump into these for the first time during your Leading SAFe class, you have quite a mouthful.
As an end note, I feel SAFe 4.5 is great, but there should be a clear separation between the core practices (regardless of configuration) and such additional practices that simply underline that SAFe is a collection of different IT industry best practices. Which it clearly is.
