It's the ultimate theory that world science is currently striving for, the one unified coherent theoretical framework for physics that explains the mechanics of the universe. It's basically a tiff between the two major theoretical frameworks - General Relativity and Quantum Field Theory. The problem - they are not compatible with each other. It's been years that scientists from these communities have argued with each other to prove the superiority of these theories. Yes, String Theory provides some relief but the struggle continues.
But why am I talking about Physics? I'm no Stephen Hawking (RIP), not even his toe nail. Unfortunately, the software world is no different. We have survived the age of Agile Software Development for almost two decades now and the proponents of agile values, principles, and practices continue preaching about its benefits. What remains is a struggle between multiple parties to prove the superiority of their frameworks. Many like me have settled for a way of working that fits our context most of the times (it's ScrumAnd… for me). Still there are many who continue with their hunt to find that one soft(ware) theory that binds everything together.
And just like Physics, there lies few biggies at the roots: Scrum, Lean / Kanban, eXtreme Programming (XP), and their scaled versions. There might be more (there are more), but for the purpose of this post, these will suffice. What are these? Primarily frameworks with various levels of prescription for delivering products (software in our case).
Frameworks have immutable boundaries; this is what defines its working. If any of the immutable elements of a framework are not implemented, one can safely say that the framework is not implemented. Scrum without the Scrum Master is not Scrum; XP without Continuous Integration is not XP; Kanban without WIP limits is not Kanban; and so on. Which also gives you a vague idea that if Agile is a set of 4 values and 12 principles from the Manifesto and a part of it is not implemented by you, are you still Agile?
Probably; the manifesto is a guideline and not a framework so the expected immutable nature doesn't apply to it. Obviously, your conscious mind can have you believe this without realising that the optimisation of your results is the key the objective. It's a very common belief that Agile way of development is better than Waterfall and yes, in many cases that's true. We have come a long way since Waterfall and our development practices and tools have definitely improved the quality of our deliverables many-folds. But Waterfall as discussed by Dr. Winston Royce at the 1970 IEEE WESCON still talks about 5 principles which are extremely crucial for Waterfall to succeed, including the principle to "Involve the Customer" at every stage of development.
It's crazy that we spent years between Waterfall and the manifesto for Agile software development to acknowledge that customer collaboration is a crucial aspect for software development to succeed. And here lies the problem of compatibility, very similar to theoretical physics. Analyse this, according to Scrum, every Sprint delivers a Done Increment which is potentially releasable. The Product Owner decides if the Increment is good enough to be released. Principle #3 from the manifesto for Agile software development states - Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
According to the manifesto, I consider that Agile engagements must release a piece of valuable working software to its customers at least 6 times in a year. If a Scrum team fails to do this, they may be scrumming, but does that make them Agile? Which would mean that an Agile framework has the potential to not be Agile based on the context in which it gets executed. These types of incompatibilities exist with almost all the frameworks, but the good news is that these frameworks also have subtle similarities. For example, Scrum and XP are frameworks suited for complex problems. And as long as they compliment each other around the theory of constraints, the results can be phenomenal.
I admire the beauty of the ScrumAnd… philosophy. It tends to embrace the good implementation techniques from various frameworks, values, practices, principles, and tools within the immutable constraints of Scrum in order to optimise results. You may never know if the results are truly optimised since the best way to achieve that is by solving the exact same problem, with the exact same skills, while utilising different ways of working. Having said that, for my context, the Scrum framework blended with other ways of working provide enough implementation for my software development needs.
Which brings us to the final statement and question, "Is there a single theory that binds the best ways of delivering software"? That's not SAFe to say. The answer is "maybe" or "maybe not", we don't know yet. I have an open mind and although my current context attracts me towards ScrumAnd..., it may attract me to a different framework that fits my purpose better in the future. The truth is, I really never wish to see a single theory that binds all together (not even in Physics). The deal with single accepted theory is that it's the end of the journey - the destination. What next?
I rather enjoy the journey instead of the end goal.