Your Agile process may kill you.

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!

Three simple ingredients:

• 2 cups Martha White® Self-Rising Flour
• 1/4 cup Crisco® All-Vegetable Shortening
• 3/4 cup milk

Three simple steps:

1. HEAT oven to 450°F. Place flour in large bowl. Cut in shortening with pastry blender or two knives until crumbs are the size of peas. Add milk, stirring with a fork until soft dough forms.
2. TURN dough onto lightly floured surface. Knead gently 5 to 6 times, just until smooth. Roll out to 1/2-inch thickness. Cut with a floured 2-inch round cutter. Arrange on baking sheet with sides touching.
3. BAKE 10 to 12 minutes or until golden brown. Serve warm.

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%.

Being agile ain’t no different, baby.

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.

Dogmatic Pragmatism

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 developingsoftware by doing it and helping others do it.Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value in the items onthe 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.

You’re doing it already

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.

Uncertainty

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…

Individuals and interactions over process and tools

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.

Working software over comprehensive documentation

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.

Customer collaboration over contract negotiation

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.

Responding to change over following a plan

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.

“Agile” as a verb

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.

Who am I?

I’m not a Fortune 500 CEO. I’ve not written a best-selling book. I don’t have a Nobel Prize. I co-founded ZEAL, a people-centric product engineering company. For years we’ve worked shoulder-to-shoulder with mid-to-large product teams to build customer-centric software that delivers recognizable value…

Learn more at codingzeal.com