Why Agile 2 Is Not a Manifesto
Cliff Berg
Co-Founder and Managing Partner, Agile 2 Academy; Executive level Agile and DevOps advisor and consultant; Lead author of Agile 2: The Next Iteration of Agile
Quite a few of the comments that we have received after launching Agile 2 have pointed out that Agile 2 does not look like the Agile Manifesto. I am not talking about the web page layout. I am talking about the length, the tone, and the nature of the content itself.
In particular, several people have said that Agile 2 does not read like a “call to arms”. The Agile Manifesto was (and is) seen as a rebellious document: it called into question many traditional methods and said, in effect,
We don’t like those old things very much. Well; we like them a little, but really we prefer these opposites.
It was kind of like when my dad bought me a very conservative and boxy used car when I graduated from grad school, but I immediately sold the car and bought a zippy little hatchback that was nothing like the one that he had got me. Not only did the little hatchback have more style, but it was also a lot more practical.
There was emotion in my act: a car is personal. I was not only choosing something that was better for me, but I was rejecting the old boxy style, and identifying with the more modern and slicker hatchback style.
Agile was like that: it was as much a cultural statement as it was a practical one. And like my selling the boxy car for a hatchback, there was identity and emotion in the Manifesto and the Agile movement. Out with that old clunky stuff, in with this new zippy stuff.
The Manifesto was also a very short document. One could put one of its values on a bumper sticker. Each principle was self contained - stated without explanation. Presumably they were seen as self evident, or things that should be accepted at face value, kind of like the Ten Commandments.
But Agile 2 does not look like that. The principles are not too long, but they are explained, and supported by an entire thought process consisting of “problems” and “insights”. These help to provide context, and enable one to discern the true intent, which is helpful for finding one’s own insights.
One person wrote about Agile 2,
[Thoughtful commentary is] not what a manifesto is supposed to do! High levels of ethos and pathos, usually low on logos [discourse]. They get the heart pumping, heads nodding, and the pitchforks sharpened.
We did not want Agile 2 to be like any of that.
We feel that emotion is too high today around everything. We did not want Agile 2 to be a call to arms of sorts, or a political chant. We wanted it to be thoughtful, and calm, and deep.
That means that it will not be put onto bumper stickers.
The same commenter wrote,
Yes, the tendency to take the Manifesto as literal holy writ leads to religious crusades. Most belief systems tend to attract their fair share of people looking for answers, not asking questions, and critical thinking seems to be in a shorter supply than ever.
That is what we did not want. We do not want Agile 2 to turn into yet another dysfunction: dogma and fanaticism and emotion and quick answers.
The commenter then wrote,
What I read in Agile 2 was a great start at providing a thoughtful, rational point of view on how to [approach agility].
That is our goal ??
And that is why it is the way it is. It cannot be summarized on a few bumper stickers or cheat sheets that one is supposed to just accept. Agile 2 is designed to provoke thought, and hopefully lead to insights. It does not claim to have all the answers. And there are no hidden meanings in the words: meanings that only those who read it a hundred times - the Agile “clergy” - will attain.
We wrote Agile 2 with plain language, and purposefully lacking references to theoretical models, because models get replaced over time and would cause the Agile 2 material to not age well. In contrast, Agile 2 is based on what seems to work, and as long as humans do not change, the things that work will probably not change. (The forthcoming book will apply some behavioral models to help to explain Agile 2.) In other words, Agile 2 is neither zippy nor clunky: it is just - we feel - the way reality is.
Agile 2 just says what its authors - experienced practitioners in the fields of Lean product design, business (including successful startups), leadership, human resources, system engineering, DevOps, and many others - have found to work in practice. Opinions may differ, and that is okay. It is not “modern”, and it is not “old fashioned” - it is timeless, we believe.
There is one way in which Agile 2 does reflect our time. Things change more rapidly today. The Agile of the early 2000s was partly a response to an increased need for agility, but it got some things wrong, left out some other very important things, went too far in some respects, and in some ways did not go far enough. Agile 2 offers adjustments. Some of the adjustments do indeed reflect today’s increased need to go faster - to be even more agile.
Not everyone will like the no-nonsense content-heavy format of Agile 2. In her article, How to Talk to an Engineer, novelist and former Google VP Jessica Powell wrote that engineers prefer problem-focused content with the details, whereas,
“when communicating with a non-technical crowd, there tends to be a greater tolerance - and sometimes preference - for storytelling and packaging as a way to get at the heart of an issue.”
So we accept that many people, particularly those who have backgrounds other than engineering (including many excellent Agile coaches), will look for a storytelling and inspirational format - formats and focuses similar to those used by Modern Agile and Heart of Agile - but many technical product developers - the people who are most directly affected by Agile - will actually prefer our format.
But why did we write it? That is well addressed in the article, Why We Created Agile 2, and it is partly because the “tendency to take the Manifesto as literal holy writ leads to religious crusades”. That crusading community culture that worships Agile at an emotional level has stifled the evolution of Agile. We felt that there are many things that the (well meaning) community is not seeing, even though those things are ubiquitous in human writing and the intellectual contributions of other communities. We just wanted to say, “Hey! Consider these things too!”
In a calm and thoughtful way.
Technology Leader | Innovating Digital Colleague Platforms to Enhance Customer Experience and Drive Growth
4 年Osvel Garza
New Solution Delivery
4 年Evolution is appropriate. The manifesto was appropriate for a revolution. Now we have a functional approach that is working and we need further refinement
Profit Wizard | GTM Alchemist
4 年100% agree on moving away from "manifesto" thinking. There is no need for a call to arms against the "waterfall" bogeyman oppressing us all; plan-centric thinking and cognitive biases are baked into us, so the escape path is more about careful reflection and empirical adaptation. That said, narrative storytelling is not in conflict with problem-solving. We need both, working in concert with each other. Which is why we encourage delivery teams to start with Why, create user personas, map customer journeys, perform gemba and user anthropology, and use user stories to trigger *actual conversations* with *actual users*. Not to mention, we have technology to capture behavioral scenarios and problem examples for use as both config-controlled "requirements" *and* automatable test specifications. At the end of the day, we don't deliver minimum lovable products that make our users awesome by "problem-solving", but through deep empathy, and such empathy is triggered by the emotional connection of a story or experience -- not problem analysis. Engineers' problem-solving skills are necessary, but not sufficient, to deliver successful product.