Recently Theo Bendixson wrote Agile is literally meaningless and one my colleagues Conrad Jackson wrote a reply Agile is Thai street food
This post explains why they're both right, and wrong at the same time.
So first off, why does Agile mean "literally nothing"?
As engineers, we're predisposed to solve problems and we believe all problems can be solved with logical thought. Our typical process might go something like this.
- "What's the big problem" (Agile)
- "How can I break it down?" (Artefacts and Ceremonies)
- "How can I solve the smaller problems" (Do the ceremonies and produce the artefacts to perfection)
There are two main issues with kind of approach, firstly Agile is not the problem to be solved and secondly our mental model of what Agile is, is wrong.
When we try to treat to Agile as a problem to be solved, our goal tends to turn to doing Agile "right".
"If only we can Agile perfectly, our software development issues will go away!"
We seek perfection and attribute success to following a strict set of Agile rules.
- "I must do standup's"
- "T-shirt sizing estimates are crucial"
- "We're not succeeding if we don't have sticky notes on a whiteboard"
Our analytical minds crave structure and our humanity causes us to gravitate to the path of least resistance, we find it easier to follow than to lead, so we observe other teams, we research and we imitate what we perceive the perfect implementation of a process might look like without really considering the root cause of why we might be trying to use that process in the first place.
Agile is like music, I might not like Stormzy's music but there's no doubt he's successful. If I am a musician I'm not likely to be successful in my own right by playing covers, even covers from a successful artist. This is especially true if the artists genre doesn't match mine.
The second problem is that our mental model of what Agile "is" tends to be built partly from knowledge in the head (what we've read, researched and been taught) and partly from knowledge in the world (our local bias' and experiences).
What this ends up with is a model comprised from a huge matrix of tools and techniques with no context; taken from other teams, other cultures other times and find this hard to organise and reason with sometimes our own experiences conflict with what we think we should do. We don't know what we should do, we want a clear defined path to follow and there isn't one.
This is why Agile means "literally nothing", Agile is not a thing which has a single defined implementation, if we think about as a tangible entity to be caught and tamed and our brains don't like that.
The human brain doesn't like ambiguity and uncertainty. Cognitive friction is increased if we have a huge range of options to choose from and it takes us a long time to choose an approach (Hicks Law), sometimes causing us to stagnate through procrastination.
This is because as Conrad writes Agile is not something to do "right" in a universal sense, Agile is everything you do within a set of guiding principals in order to find your own path with the goal of developing a set of processes which work for your team, project and culture.
Theo is also right, if we're not talking about the same Agile, conflicts can occur if the communication paths aren't clear about what we our goals are and what we mean. However, this is avoided if we followed the first Agile manifesto item:
Individuals and interactions over processes and tools.
However if Theo is finding Agile meaning nothing, perhaps it's this expectation that we can quantify a principle through a specific process that's the real problem.
Gestalt design principles talk about figure/ground and often use images like this to demonstrate the principle.
The human visual system will (almost arbitrarily) see either two faces, or a vase. What's interesting is that both exist in the image depending on which colour you consider the figure and which the ground.
What's more interesting is once you know both exist, you can switch your interpretation easily, what's even more interesting is that whilst your default visual preference is for one or the other pretty much randomly, I could influence you to see one or the other if I had spoken very deliberately about the many faces of Agile before introducing the image.
What I'm trying to illustrate is that many simple objects have multiple interpretations and trying to insist that it's one thing or another is futile, Agile is the same.
This is why Agile means everything, the processes are an interpretation, it's not what others do, it's not specific ceremonies, your not doing it wrong if don't do what everyone else seems to do, it is everything you're doing if your considering the principles not just when writing software, but also when you're thinking about things, talking to people or managing the work, it's a mindset.
This is why Agile means literally nothing, and everything at the same time and that's alright!
Oldest comments (0)