Blueprint Vs Prescriptiveness
As usual, all of Agile recommends that you should go into the world and achieve Business Agility, meanwhile they provide no guide, no support, no manual for achieving this unprecedented feat. SAFe, again, does not let you walk this unknown path alone. It provides a level of support that someone like myself who started from a Traditional Project Management and then vanilla Agile background, would always appreciate.
Unfortunately, the detailed support from SAFe has been re-interpreted by critics (who do not present an alternative, by the way) to be SAFe being “prescriptive.” They act in the same way a mischief maker would criticize medication like Tylenol by saying Tylenol could be used to commit suicide, even if he/she knows it was designed to, and actually brings good health. The simple fact is that when use is not known, abuse is inevitable; the outcome you get from any initiative depends on how you use it, but I digress. Back to the subject matter, SAFe simply did the unusual and extra work of providing organizations with a roadmap to actually achieving Business Agility, SAFe equally covered the blind spots that many enterprises would otherwise, or usually, miss. What is mistaken for being prescriptive is the fact that SAFe put together learnings from thousands of successful SAFe implementations to come up with a manual/guide/blueprint for implementing SAFe with the aim of ensuring success. Rejecting a manual because it’s comprehensive and detailed will only lead to failure as there is a reason for every recommendation therein. Those who hold the belief that SAFe is prescriptive and go on to redesign their own version of SAFe without thoroughly understanding that the blueprint is a result of thousands of hours of research and experiments put together by some of the world’s greatest minds, go on to experience failure. When I hear the stories of failure, I search for the root cause and when I get to the root cause of the failure, I realize that the problem is not with the SAFe framework itself but with the remix version of SAFe that the users attempted to implement.
On a lighter note, I will use this analogy:
SAFe critics can be compared to a person who has never seen or used a car before, taking delivery of one. He looks at the owner’s manual and thinks “this manual is too comprehensive/long/prescriptive” and so he goes on to redesign what he thinks will work for him. First, he says, “this car thing, let’s make it simpler by removing the engine, and then the steering wheel, and then the gas tank, and then the tires.” After he has dismantled the car and created this contraption, he looks at it and says, “good job, now let’s drive, they say it can get us to our destination in a very short time” and then he attempts to drive but the “car” wouldn’t even start. He goes back to read the manual and puts the key in the ignition and tries to start the “car” again and…nothing! Then he goes on a campaign of calumny “SAFe is a disaster”, “SAFe is not Agile” (he doesn’t even know what it means to be Agile), “SAFe is too prescriptive.” IS YOUR ENTERPRISE’S VERSION OF SAFe A CAR OR A CONTRAPTION?
For more information on the concept of Business Agility within SAFe, please visit https://scaledagileframework.com/business-agility/