SAFe Evolution
Freestocks photo

SAFe Evolution

This is actually a repost. The original appeared in my blog two years ago. But since it mostly concerns history, I think it's still quite up to date.

I have been involved with SAFe for about seven years now. We first started by taking inspiration from Dean Leffingwell's Scaling Software Agility book. Then we bumped into the SAFe big picture. I think it was something like version 2.1 back then. There were still HIP-iterations in the end (H stood for hardening) and the model was talking about Potentially Shippable Increments and Releases.

SAFe v.2.5

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 v.3.0

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 v.4.0

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 v.4.5

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.

If you managed to read all the way until thi point, thank you very much! How was it? Agree/disagree? Has it stood the march of time or do you think it has become out of date? Let's discuss.

Riku Siimesvaara

Software Architect at Tornator Oyj

5 年

Nice that you mentioned HIPs and bloating! Always felt all hardening sprints/increments to be extremely counterintuitive for Agile and did not realize that they were also included in older SAFe versions. If you are shipping vertical value-adding increments with constant quality there should be no hardening step (outside story or task context). Isn't hardening on the PI/sprint level just another term for a phase-gate process step???? You know your framework is bloated with buzzwords when you are doing Lean Business Cases...???

要查看或添加评论,请登录

Toivo Vaje的更多文章

  • Rule of Three Eights

    Rule of Three Eights

    I recently had a conversation with a team member about using time for learning. They had noticed that taking the time…

    2 条评论
  • What I've Learned in my 17 years in LinkedIn

    What I've Learned in my 17 years in LinkedIn

    Has it really been that long?? Apparently I did create my LinkedIn profile in 2007. First it was mainly an online CV.

    4 条评论
  • Testing GitHub Copilot at Smartly.io

    Testing GitHub Copilot at Smartly.io

    GitHub Copilot is a revolutionary AI-powered coding tool that is designed to assist developers in writing code. It is…

    4 条评论
  • 10 points for Team (Self)Assessment

    10 points for Team (Self)Assessment

    During my years in the software development industry I've noticed that it's really important to be able to measure your…

    4 条评论
  • Early stage (software) business development

    Early stage (software) business development

    The following post is not that directly concentrating on software development, but more in the early stage business…

    4 条评论
  • Scaling Software Development

    Scaling Software Development

    Software development is a team sport. It is true that even a single person can make huge contributions (like Linus…

    11 条评论
  • Rekrytointi on myynti?

    Rekrytointi on myynti?

    Rekrytointi on myynti?. T?m? saattaa olla rekrytoinnissa ty?skenteleville itsest??n selv??, mutta selkiytet??n silti…

    14 条评论
  • Sis?inen motivaatio ja vaihtuvuus

    Sis?inen motivaatio ja vaihtuvuus

    IT-alan ty?markkina on t?ll? hetkell? tilanteessa jossa harva yritys pystyy palkkaamaan kaikki henkil?t jotka toivoisi.…

    18 条评论
  • Projektip??llikk?n? Elisan ITBU:n Liiketoiminta IT:ss?

    Projektip??llikk?n? Elisan ITBU:n Liiketoiminta IT:ss?

    Tiedustelin tuossa v?h?n aiemmin yleist? kiinnostusta projektip??llik?n tai teknisen tuoteomistajan teht?viin. Minulla…

  • Team Agility

    Team Agility

    I'm not really much of a manager. Probably a slightly better coach, but mostly I'm a leader.

社区洞察

其他会员也浏览了