Why you should be careful with “agile frameworks” and three recommandations to make the most of it
TL ; DR : Nowadays agile frameworks like SAFe and Scrum are criticized a lot.
This is for a reason: first, frameworks tend to normalize ways of working which is anti-agile; second, institutes behind frameworks are most of the time more interested in making money, than making agile better; third, frameworks might lead you to fail your agile transformation and “throw the agility baby out with the water”.
However frameworks do bring a lot to agility: (i) they are reinsuring for stakeholders that might not buy in agile without; (ii) even if superficial, they are a great learning starting point; (iii) at the end of the day, it gets people interested about agile and there’s no such thing as bad publicity.
My recommandations regarding frameworks: (1) see them like a table of contents not like a guide / gourou; (2) don’t shame agile newbies, beginning with SAFe or Scrum, pull them upwards; (3) be clear with stakeholders that frameworks are not a silver bullet towards agility.
A quick definition of frameworks: they are methodological guides that define good practices and ways of implementing agile. Two of the most famous agile frameworks are Scrum and SAFe.
Scrum is twenty years old and has created roles like Product Owners or Scrum Masters; items like backlog (prioritized list of functionalities to develop) and ceremonials like sprint plannings.
SAFe is more recent but is very renowned in the IT world as it’s supposed to help you achieve agility @Scale, namely, for a number above of 50 developers.
First a little confession : SAFe taught me huge deal about agile
I was certified SAFe Program Consultant (SPC) in november 2019 and it actually enabled to improve myself a lot about agile:
- First, I had to study hard. The certification is tough. I had 4 days of course with 2 high-level teachers, each of them with several years of agile transformation experience. You have to study for at least 10–15 hours to make it through the exam which is a hard multiple choice questionnaire.
- Second, you know better where to look to deep dive into agile. You cannot deep dive in all the topics are mentionned in SAFe before the certification. But afterwards, it was very interesting for me to dig further into topics. For instance, I bought, read and studied books about DevOps or Lean Software Development (which constitutes the theoretical basis of SAFe). Thanks to SAFe, I knew these books were references on the matter and it had already given me a first understanding of it so the books were not unaccessible for me.
- Third, “you’re certified? So you’re an expert”. Good or bad, deserved or not, once you’re certified, you’re seen as an expert of agility. Quite concretely, it implied for me to give trainings to many people in my company. The training and the expert posture pushed me to challenge myself even harder which helped me improve myself even more.
You should be careful with frameworks can easily lead to agile antipatterns
Nonetheless, let’s keep in mind that most of the critics about frameworks like SAFe or Scrum are justified:
- They tend to normalize when agile theoretically strongly relies upon auto-organization to deliver value. Frameworks push us to apply rules that are supposed to be agile without understanding how agile could help us and to what extent following these rules is agile. Therefore it might make things more rigid and making us diverge from our goals with antipatterns like “we do that because it’s in the framework not because it brings value to the user”.
- Institutes behind frameworks have marketing / sales objectives. Just like any business, they want to make money through certifications and providing coaches. The more people know them, the better for them. It introduces a bias towards easier and lower quality certifications that are therefore less relevant. Moreover, to appear the most relevant on the theoretical plan, they tend to gather many theoretical elements even if the whole lacks consistency
For instance, with SAFe, it seems that as soon as there is a new trendy buzzword, they have to include it in the framework which ends up looking like a “patchwork”-framework
- Consequence of the two first points, you might not succeed in your agile transformation only thanks to the implementation of SAFe or Scrum. There’s a high risk then, that the initial buy-in of sponsors gets replaced with a strong opposition not only against the framework but also against agility in itself. What we could call throw out agility baby with the bath water.
Many prominent actors in the software world have put emphasis about the agile antipatterns brough by frameworks ; I like a lot the one of Ron Jeffries (one of the signatory of the Agile Manifesto) “Dark Scrum”.
However, it would be wrong to completely discard frameworks because they also bring a big deal to agility
Despite all their flaws, I still believe frameworks can be useful for agility:
- The “patchwork” aspect makes the whole framework less convincing intellectually; however it gathers a lot of informations in the same place and it’s a good starting point. Of course it doesn’t make quite sense to gather in SAFe Lean Software Development principles; DevOps practices and Design Thinking methodology. But still, it’s still useful just to know that these stuff exist in the IT ecosystem and to be able to find easily the relevant books on SAFe website.
- Big fat frameworks like SAFe are reinsuring for stakeholders. They can picture themselves in it and they can see their teams in it. Of course agile is not supposed to work this way: stakeholders’ focus should rather be on how to picture developers and themselves, but if it’s the only way to get an initial buy-in, I’ll take it.
- Good or bad, they make people talk about agility. It remains publicity and publicity is never bad. Even Scrum of SAFe or another framework are not the best way to achieve agility, they might still be smart enough to take hindsight and not follow religiously the framework. This is the exact path I took. Eventually, so many people go into agile through this frameworks that they cannot be 100% bad.
Three recommandations to make the best of frameworks
To sum up, I think that frameworks are “good servants but bad masters”; use them wisely:
- See the framework as a table of contents that can guide you towards more detailled content that will help upskilling you or anyone that want to be better at agile. And most of the time, frameworks do rely a lot on detailled content written in books, so make the effort to go further than only the superficial presentation for the framework and read the raw content.
- Don’t shame beginners that are enthusiastic about frameworks as they start their agile journey. It will just make them feel bad and once again, enthusiasm about agile even if it’s through a questionnable framework is still positive and must be encouraged. As a more experienced agilist though, you should pull them up towards better ways of achieving agility. The journey is not over. Help them achieve and keep a learning spirit.
- When it comes to stakeholders, be very careful to handle their expectations wisely to avoid the “throw out the baby with the shower water” effect. It’s okay to start with a framework be it SAFe, Scrum, XP, Kanban; but stakeholders should be aware of the fact that it’s not enough to generate all the benefits of agility. Therefore, communicate clearly about the fact that it’s only the starting point of the journey and that the rules within the frameworks should not be followed eternally to the letter.
You want to learn more about agility and the wise use of frameworks ? Join us:
Interested about tech like us? Get in touch with us and stay tuned for more articles to come.
