My partner loves to bake. She’s from the south, and her grandma used to make these Martha White® “Hot Rize®” cathead biscuits that were to die for!
You might assume with three ingredients and three steps, the result would always be the same… but you’d be wrong.
Over the years we’ve moved around the country. Every time we make this recipe, we have to recalibrate. The oven would be too hot/cold or plain inconsistent. The flour wouldn’t “rise” evenly or take longer/shorter amounts of time. Even the same mix and same batch wouldn’t produce the same quality biscuit.
The only consistent thing was that no recipe would work 100% of the time or address every edge case. We had to adapt. While the recipe was a vetted guide, the statistical probability of success was high, but never 100%.
We love recipe books that break down complex outcomes into simple to follow steps. Cooks and business gurus alike have made a fortune off of providing the right way to do just about anything.
Don’t get me wrong, there is plenty of value in the knowledge and experience of others. There is plenty to be learned from how others approached a problem, and what they discovered as they walked the path.
I don’t know many technology companies who haven’t heard, read, tried, or been consulted on agile development. You can pick one of many flavors: SCRUM, XP (eXtreme Programming), Kanban, etc.
The failing of most agile teams is not that they chose the wrong flavor of Agile, but that they’ve lost real agility after choosing it.
From the Agile Alliance:
What is Agile?
The ability to create and respond to change in order to succeed in an uncertain and turbulent environment…
Agile Software Development is an umbrella term for a set of methods and practices based on the values and principles expressed in the Agile Manifesto.
Solutions evolve through collaboration between self-organizing, cross-functional teams utilizing the appropriate practices for their context.
The irony of many Agile practitioners is the relative dogma they install against the pragmatism Agile encourages. Remember…
Your process as a team should not simply be a reflection of another process; it should be an iteration of a process that represents both Agile values and those of your team, as well.
The entire Agile Manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
There are only twelve principles to go along with it, but the manifesto is nine lines — that’s it.
Our company has never partnered with a team who’s been able to follow one of the above flavors of Agile to a ‘T’. It’s not only hard to be so dogmatically pragmatic, but, ironically, within weeks of going down the path, they start to feel like their less agile than when they started.
The first point is “Individuals and interactions over process and tools.” The irony is that this statement is the first to be violated by going Agile.
We know from our agility training that change is the one constant in life and business. Each of the above flavors of Agile address this same question: How do we handle change?
The Agile Manifesto spells this out…
These two comparisons, often lead teams down a binary path: individuals, not processes, and interactions, not tools. However, it’s not a one or the other model. It’s a prioritization model. If you had to choose, choose the first over the second.
We’ve found that the two are even more connected: Processes that embrace individual contribution and tools that encourage interaction. A process isn’t bad, nor are tools. Like a map and compass, they aren’t useless; in fact, they’re incredibly valuable when used properly and prioritized accordingly.
Pulling back from its literal interpretation, a routine that achieves the goals of the team — whatever it is — is more valuable than dogmatic adherence to a process. Remember, if I trust Google Maps 100% of the time, then I could conceivably drown in a river or drive the wrong way into traffic.
For the moment, replace “customer collaboration” with “process iteration” and “contract negotiation” with “process dogmatism.” Prioritizing dogmatism over iteration is a core concern. Now, that’s not to say a team should change direction willy-nilly without taking the time to determine that a particular step in their process is effective; they shouldn’t be afraid to add a little salt to their recipe and refine their process over time.
Team too often ask the wrong question of themselves, “Are we doing it the ‘Agile’ way?” versus “How do we know what we’re doing does or doesn’t work? and if what we’re doing doesn’t work, are we doing the way we know works? and if so, what do we need to do differently?”
The most undervalued tool in the arsenal is a retrospective. In our many years at ZEAL we’ve changed the format and frequency plenty of times; however, the purpose has always stayed the same: to respond to the questions above.
It’s become a noun. It’s become an item on a store shelf. But, it’s not a compass. It’s not a map. It’s the way we navigate the work. It’s the way we wrap uncertainty and handle the emotion caused by the unpredictable. It’s not a theory, it’s a fact.
To be agile is to embrace change in all things. To embrace the diversity of the situation and recognize that, while many things will walk and talk like a duck, it might just be 2 o’clock.
Are you ready to build something brilliant? We're ready to help.
.jpg)
