Not Agile? Good!
The working world needs a little more rigidity
The Agile Manifesto (sic) and the Scrum Guide—indeed Scrum itself—are often criticised for not being agile. It is an absurd criticism, like complaining that an eggbox is not itself an egg, or that a songbook cannot sing.
A few days ago on LinkedIn my friend and fellow change agent,
, wrote the provocative post, Scrum isn’t Agile, to which I responded thus:Scrum isn't agile. True. Scrum is a framework, or as the guide expresses it, Scrum is a container. Containers should not be agile. Imagine an agile saucepan, all floppy and adaptable to different cookers, food and liquid spilling out everywhere. Containers should be rigid, and strong. Scrum is rigid and strong—but also, like a saucepan, open to receive different ingredients. Scrum is a container for agility.
The manifesto for agile software development is also not agile. It would be ridiculous for a manifesto to be continually responding to change or user requests. Imagine the mess we'd have! It would be now be several hundred pages long, full of conflicting opinions, versioned up the ying yang, with no two practitioners using the same version. Nightmare. The manifesto is a rigid, frozen document, about the most unagile document in the Agile world. And thank goodness for that! The manifesto is our rock of ages.
The cartoonist and satirist Jules Feiffer once wrote, “Freedom is the right to choose your own prison.” The prison I choose is the Scrum Guide. It gives form to the passion. In the IT world, and perhaps beyond, we seek autonomy, collaboration and self-expression, in other words the freedom to explore and create, but if there are no goals, no boundaries, no structure we only get hopelessly lost—nomadic artist wannabes wandering a desert of crumbling dreams. And this, I propose, is why so many Agile projects fail: too much agility.
I’ll end this sermonic post with a quote from 37 Signals, which could have been (but wasn’t) written about the Scrum Guide.
"Instead of freaking out about these constraints, embrace them. Let them guide you. Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage."
"The manifesto for agile software development is also not agile. It would be ridiculous for a manifesto to be continually responding to change or user requests. Imagine the mess we'd have!"
We dont need to imagine, agile is creating those messes in other things, just as you feel they would with the manifesto. Why is the manifesto different to a requirements document written for a product?
The real reason why the manifesto wont change is because the author see it as a historical document, which is most likely driven by ego - not change.
Not all constraints are good constraints, some are destructive, irrelevant or enabling.
Scrum is not even a container for agile. You could easily do BDUF inside of the Scrum framework.