So, let’s get one thing straight, this read will provoke people, entertain others and even make some people angry, some people won’t even read it because of the headline… well point proven
Let’s also get another thing straight, I am not pretending to be a SAFe expert, tons of other people are doing that with their fancy certifications, I’m just a simple agile coach trying to make the world a better place.
My “problem” with SAFe (for those not familiar: Scaled Agile Framework).. is not so much the framework itself, I’m sure many (some) companies have achieved great results with SAFe, it’s more HOW they are branding themselves.. And also the fact that they have pretty much “stolen” most of their content and now brand it as something revolutionary..
SAFe is portrayed as a scaled agile framework when it is simply not. They have however, improved waterfall project management. Which is by the way, great, if you can predict the future.
Let’s have a look at one of the cornerstones of SAFe, the notorious PI Planning.
I have myself been part of PI Plannings, and I must say it is an interesting spectacle. One of the managers saying (yes, I used the word manager, not leader) saying “this is organized chaos, this is agile”… NO there is nothing organized about this, and this has nothing to do with agile, AND agile isn’t chaos! I was lost for words, and I rarely am.
Anyway, let’s have a look at the purpose of PI Planning:
- Each team should commit to objectives from the PI, this is basically what the team commits to do during the upcoming PI
- A program board, this is an overview with all sprints and the user stories to be executed in each sprint, also mapping all dependencies.. So, pretty much a timeline.
Also, the PI Planning agenda is a standard agenda that should be followed each time.
Okey, I have some issues with this.
First off, the set agenda. What happened with one of the core agile principles, learn and adapt? If we are not using the (mandatory) retrospective at the end of each PI Planning to improve our process, we are simply not doing agile very well, or not at all.
Secondly, that each team should commit to objectives. I believe this is fundamentally wrong. The number one objective should be that everyone understands what they as a team (meaning everyone) are delivering. What customer value are we delivering here? I simply don’t care if my team commits to something, if they don’t know what they’re committing to!
Thirdly, you make a detailed plan, but add iterations/ sprints instead of adding week numbers, that makes it agile? Sorry to break it to you, THIS IS WATERFALL. Don’t say any different (sorry, I’m real stubborn about this one).
If you map something out, in detail, and expect it to happen you are either doing waterfall or you have precognition abilities, if so, I’d like to get in touch!
Lastly, in a PI Planning you have a “confidence vote” (1-5 how confident you are in your plan), this is a great idea and you’ll get a feel to how the team is feeling since everyone raises their hand. But, you’ll only get an honest view if you have high psychological safety in the group. If you don’t, this is only a false picture and will actually do more harm than good since the leaders are not getting the truth and then they won’t be able to do what is needed in order to build trust..
Therefore, I propose that SAFe changes to SAWe. I have really great reasons.
- SAWe stands for: Scaled Waterfall framework, this is much more applicable and explains what you REALLY are doing.
- SAWe is also really nice because it is what you ARE doing, you are saving people from large scale waterfall projects.
Check out our Master class on Udemy! Now only $9.99 instead of $199.99!
You are not convinced yet? Lets round this up, I want to know what happened to the core agile principles in SAFe, did someone just forget them?
Trust & Openness: this is crucial in agile, we need to encourage, create and facilitate trust & openness in our organizations. This will create empathy, and we need this in our workplaces in order to create truly high performing teams.
I can’t find anywhere in the SAFe framework where this manifests through the framework. Rather the opposite, everything is supposed to be visible to the managers, stakeholders and ARTs, and all stakeholders can participate in backlog improvements. So, I think I’m missing something.. Isn’t the key that the team should experience and receive trust FROM the leaders, not that the managers should monitor progress? Isn’t trust supposed to go both ways? My impression with SAFe is that it doesn’t.
The DEMO supports this. In SAFe the purpose of the demo is to give the ART a way to measure progress. WHAT?? The purpose of a demo is for the team to show of what awesomeness they have created, and be proud. Nothing should be developed for a demo, rather what you have created should be shown. But, nothing speaks trust like some good old reporting (because that is what this really is), am I right???
Self-organizing teams: in agile we believe in strong, self-organized teams, not title and role-based teams. We believe that we have highly intelligent, competent people in our teams. They will figure out how they should be organized on their own. Not through standard roles and responsibilities.
Do what works when it works. For me, this is the core of agile. Do what works for what team when that works. When they mature the team-ups the ante. They challenge, change, and adapt as they go. We don’t force a team to do anything a certain way, and we certainly don’t force a whole bunch of them into a standard mold that managers (or consultants) think will work.
Alright, I can keep going about this, but I won’t. I think you have gotten enough of my input to break free and start thinking on your own.
Good luck ?