Take the blue pill, the story ends
February 21, 2022The one question that lies at the heart of the "big A Agile" vs "little a agile" debate.
In the Allegory of the Cave, Socrates describes a people living in chains, facing a blank cave wall upon which shadows are cast by unseen objects or people passing between a fire and the wall. Those living in chains only see the shadows, a poor representation of the greater reality, but the only experience of reality they’ve ever seen or known.
If someone escapes the chains, and is able to turn around and see the fire that is the source of light, and the objects or people passing between the fire and the cave wall, their attempts to explain this reality to their still-enslaved colleagues will be fraught with frustration.
To me it seems we often have the same problem when it comes to discussing software development, and particularly when we talk about “Agile”.
One attempt to bridge this gap between “reality” and the “cave wall” is talk of “big A Agile” versus “small A agile”, which I interpret as follows:
“Big A” Agile typically refers to “the Agile Industrial Complex.” That is, “Agile as sold to large companies.” This version is largely focused on frameworks, certifications, check-boxes, to-do lists, maturity indexes. It loves to quantify agility. This is the 2-dimensional version of reality, cast upon the wall as shadows that everyone thinks they understand.
“Little a” agile, in contrast, is meant to convey the principles in the Manifesto for Agile Software Development. It’s much fuzzier, more subjective, harder to define, and therefore harder to “sell.” This is an attempt to explain the larger reality, often to those still chained, looking only at the cave wall.
But this won’t help anyone. According to the allegory, anyone living in chains will be incapable of understanding what the unchained are talking about.
Is there hope?
Maybe there is.
The best I can tell, whether one lives in “agile chains” or not, comes down to how one responds to a single question. The question may sound subtle, but the implications are anything but. It’s a red pill/blue pill kind of question.
You take the blue pill, the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in wonderland, and I show you how deep the rabbit hole goes.
— Morpheus, The Matrix
I’ll expand on my thoughts on this question and its implications soon. For now, I’ll leave you to ponder it.
So what’s the question?
How do you respond to uncertainty?
Don't become complacent
If a thing helps you, use it. But don't become complacent.
By calling iterations "Sprints", Scrum implies a need for constant running. Don't be fooled.
"Agile" isn't about delivering every sprint
Frequently delivering software, but not considering feedback on how to improve, isn't agile.