All agile and lean approaches will be assimilated
The Borg are a community of cybernetic organisms. They are one of the most formidable antagonists in the universe of Star Trek. They grow their knowledge and technology by forcibly assimilating other species. These species will be augmented and made part of the Borg collective. Resistance is futile. The Borg are too strong to oppose.
SAFe is like the Borg. It assimilates everything popular in the Agile and Lean sphere. But not before changing it, augmenting it. The processes, practices, and frameworks are still recognizable. But they are absolutely not the same anymore.
Do you think this is far-fetched? Well, let’s go through some examples to underline my argument. Starting with the most obvious example, writing this for Serious Scrum.
Assimilation of Scrum and XP
Agile teams in SAFe theoretically can use any process they wish. But in practice, they need to align to SAFe (like the Agile Release Train). This is why it makes sense to follow the process recommended and described by SAFe: ScrumXP.
It already starts with the naming: Scrum and XP (Extreme Programming) are made into one. Two independent approaches are put together into the SAFe framework. This means Scrum and XP were augmented.
I did write about Scrum vs ScrumXP before to stress how much the two are not the same. Despite being deceptively alike. Just like Jan-Luc Picard still is recognizable, but drastically altered by the Borg. Here are a few examples:
- ScrumXP is a delivery process, not a discovery framework
- ScrumXP has no mention of empiricism and its first pillar transparency.
- Scrum Master, Product Owner and Developers still exist. But the accountabilities and responsibilities are different.
- The events have different names, but also different purposes.
- The Product Backlog is renamed to Team Backlog.
The differences are often very subtle, but all the more glaring once you realize the impact.
XP is omnipresent in ScrumXP if you look for it. The naming of the events is from XP, most notably using the term Iteration and Standup. On top of that, ScrumXP lends engineering topics like Test-Driven Development and Continuous Integration. It also works with the term User Story.
But important topics like the XP values and customer-centricity are not mentioned in SAFe’s ScumXP article. XP is augmented too.
Kanban
Kanban is another popular approach in the Agile and Lean world. Of course, SAFe has this too. It is called Team Kanban and is presented as an alternative for ScrumXP. Typically for teams that don’t produce software. This is the definition of Team Kanban:
“Team Kanban is a method that helps teams facilitate the flow of value by visualizing workflow, establishing Work In Process (WIP) limits, measuring throughput, and continuously improving their process.” — SAFe 5.0
The above definition ticks all the boxes of Kanban.
The fact that SAFe has its own description of their version of Kanban speaks volumes. Apparently, SAFe’s version of Kanban needs to be described separately.
There are obvious differences indeed. Especially to ensure that there’s alignment with the Agile Release Train. So we see topics like iterations, estimation and velocity. All to ensure the team works in the same cadence as the other teams in the train.
Many other terms and approaches
Scrum, XP and Kanban are obvious examples of assimilated and augmented approaches. But we have a sheer endless list. Here are some other examples.
DevOps
DevOps is hot. Everyone wants to be DevOps. So, SAFe assimilated it. SAFe focuses on the mindset of collaboration between teams (and topics like automation). But, is better collaboration between Agile Teams, operation teams and security teams the key to DevOps? Or is it more about having these capabilities within one team? Whatever it is, SAFe again created its own version of a concept.
CI/CD
Another unavoidable concept is CI/CD (Continuous Integration/Continuous Deployment), closely related to DevOps. This is about making frequent incremental code changes, largely due to automating build, merge, test, and deploy steps.
SAFe embraced this and made it it’s own. Adding something, of course, calling it CE/CI/CD. What is CE you ask? Well, it’s Continous Exploration. It’s where people like Product Managers and Architects form hypotheses and envision an approach. The idea is to test a hypothesis fast. As I see it, the connection with CI/CD is artificial. But it’s an integral part of SAFe.
Lean Startup
Another popular approach lately is Lean Startup. The core of this concept is verifying your assumptions as quickly as possible because most ideas we have will not bring the expected results.
SAFe has Lean Startup thinking creating Minimum Viable Products. I sincerely wonder how you would use Lean Startup — which is doing the smallest possible thing to verify your assumptions — in a SAFe environment.
SAFe typically works with ARTs that take multiple iterations and multiple teams. So the investment is considerable if you’d use Lean Startup in a SAFe environment. The very thing you wish to avoid in the first place.
Other examples
There’s also Lean Budgeting, Key Performance Indicators, Design Thinking, OKRs, Lean UX, and much more. The list is endless. SAFe is everything but the kitchen sink.
SAFe adapts to get more resilient to resistance
But there’s more. SAFe doesn’t only assimilate all these Agile and Lean practices. It also adapts. It especially adapts to counter resistance, the ongoing flow of criticism.
For example, one of the major criticisms was how SAFe (4.0) didn’t have the customer in the centre of attention:
So they changed the picture when they released SAFe 5.0:
Another example is how I was corrected by a SAFe proponent. I argued how un-agile multi iteration release trains are. Then the proponent said: SAFe Allows one-Sprint trains now! So, he ‘won’ the argument.
The more the critics bash SAFe, the more SAFe will be adapted to ensure ‘resistance is futile’.
I guess there’s something good about this. SAFe can get rid of its glaring issues this way. That said, there’s still a lot made part of SAFe that is painfully misrepresented. On top of that, there’s a difference between SAFe in theory and SAFe in practice.
Because the vast majority of companies working with SAFe have implemented the version with long release trains inhibiting agility. SAFe has been the agile approach for organizations that resist change.
SAFe is like the Borg: confirmed
SAFe assimilates all popular Agile and Lean approaches and makes it its own. As if it makes perfect sense to have everything in one gigantic framework. But often, the assimilated approaches are so drastically augmented, that they are no longer the same. Scrum, for example, is very different from ScrumXP.
The worrying thing about this is that the assimilated approaches are practised by many teams. Because SAFe is widely adopted.
This raises the question: will Scrum (and other approaches) be completely assimilated and cease to exist on its own? As the Borg have done with many species? Only time will tell. Probably there will be people who manage to resist the omnipresent SAFe.
But there’s more. The Borg used to be the antagonist. But lately, in the Picard show at least, they are making an effort to change and co-exist with other species. Is the same happening to SAFe?
Through the fierce backslash of the agile community, SAFe was under threat. By adapting and having a more nuanced stance, and having more flexibility, adaptation, SAFe presents itself in a different way. Only time will tell how this will work out.
And let’s not forget that Scrum basically grew in the same way. It started heavily inspired by The New New Product Development Game and added all kinds of best practices to the framework, like the daily and the retrospective.