A recent discussion on the Scrum Alliance Linkedin group was around Mike Beedle’s claim that “Hard-coded Frameworks are neither Agile or Frameworks” which is clearly aimed primarily at SAFe.
I admit to thinking something similar before really getting to know SAFe in depth. Over time I realized SAFe isn’t one size fits all. Far from it.
It has many configurations and options. Do we need the Value Stream level? a System Team? at which level? How many ARTs? Component teams or Feature teams? Which metrics? Which ART to start with? Even if you don’t follow my Invitation-based SAFe implementation approach that is now a formal SAFe guidance article, you still have a lot of options at all levels and it is hardly a hard-coded methodology. Yes, not all practitioners understand this. But that’s a familiar problem from the Scrum space isn’t it. “Though shall do tasks”. “Though shall estimate in story points using planning poker”. “Though shall stand up in the Daily Scrum”.
Scrum was and is a powerful tool. SAFe, Enterprise Scrum, Nexus, LeSS, Kanban and others are powerful tools as well. A powerful tool is typically also dangerous at the wrong hands or the unexperienced hands without good guidance.
Besides — it IS funny to hear about the danger of force-fitting a hard-coded framework from leaders in the scrum community that have been telling us about SHU and following practices and the danger of scrum-but all along. And rightly so! Sometimes you do need to insist on a practice/change even if it feels hard! Agile IS about challenging your comfort zone.
Can we all agree that the real art/expertise is to figure out the right set of practices that is the goldilock between too much force-fitting and too-easy “common sense that is somehow too close to the status quo”?
(Updated) Oh — and also can we also agree there’s a huge difference between force- fitting practices to challenge your comfort zone (which is healthy change management done right) and forcing people to do something vs inviting them to consider trying it?