If you’re manufacturing commercial airliners, a year-long development cycle (down from, say, six for the Boeing 787) would be a minor miracle.
In software development, though, a year would never stand. “That’s waterfall,” comes a derisive snort. “We do Agile.”
Do Agile–are we using? To the extent that it’s something we do, without thinking, maybe we are. Though it takes a journey, a better outcome is to be agile. Little-a. But let’s start with what makes agile agile at all.
A quick refresher:
- Waterfall development takes a predetermined, linear path towards its similarly predetermined goal. We don’t move on to Phase B until Phase A is complete.
- With an agile mindset, completion of Phase A is an opportunity to adjust our plans. Do we proceed to Phase B as planned? Revise it? Or take on something else entirely? The optionality is useful if Phase A delivers standalone value; less so if Phase A delivered a wing but we’re still one fuselage short of a plane.
Appropriately-scoped units of work are both an important part of agile development and a sometimes-victim of the realities at hand. Building a plane takes longer than updating a display ad. A certain level of ambition requires a certain level of patience and coordination–plus cycle times and a project roadmap with a vaguely waterfall-like appearance.
Even with short cycle times, frequent adjustments, and independently-valuable units of work, agile development still depends on working towards a consistent vision of the future. Working on Phase A we’re not blind to what Phases B, C, or D may entail–we’re just gathering more input before planning them in earnest.
If the vision is consistent and cycle times dependent on the work, the only real difference between agile and waterfall is the amount we presume to know up-front versus what we’re open to learning along the way.
Little-a agile is an ongoing quest for the shortest possible cycle of planning, implementation, feedback, and iteration–maximizing our opportunities for learning and adjustment. Test-Driven Development is agile. Pair programming (whether your pair is human or not) is agile. Continuous integration is agile. The list goes on.
What’s notable about little-a agile is the lack of prescription behind it. Being little-a agile requires nothing. Not scrum masters. Not story points. Not even a Kanban board (though some communication system will help). It’s a mindset. If you’re delivering value, squeezing overhead, and continuously improving across the board both, you’re there. It doesn’t much matter how.
When we Do Agile, it’s the Big-A kind–the kind with the industrial complex of systems, trainers, and consultants peddling prescriptive their own true path. Where little-a agile teams have a “minimum-valuable” mindset ingrained in their psyche, the cadence of planning, delivery, and iteration in Big-A systems imposes it by force.
This isn’t necessarily a bad thing. Where the instinct for frequent delivery and introspection is lacking, Big-A Agile scaffolding can close the gap. But its prescriptive approach comes with costs:
Ceremonies can’t replacement a mindset–but they can take time. Between bi-weekly (or so) observances of the Agile calendar and internecine debates over the application of its teachings, Big-A systems can add significant overhead and meta-work.
Big-A systems also prescribe limits on the minimum feedback loop they can achieve–and the prescribed dogma isn’t itself subject to continuous improvement.
No two teams are alike, and an agile system developed for a certain industry, scale or regulatory climate may not translate. The path from zero to one on a new feature (or airplane) looks very different than an iteration on an existing one.
If a team isn’t delivering otherwise, a Big-A Agile approach may be worth it. But as a no-less-likely-source than McKinsey offers up,
…many of the business leaders we interviewed assumed agile ceremonies at a team level would be among the top enablers of software development. But while agile team practices are helpful (especially in lifting performance among third- and fourth-quartile players), our study finds they do not play an outsized role in advancing [developer velocity] beyond that.
In other words: for teams above the 50th-percentile, and (one would assume) particularly for those with an established little-a mindset, Big-A Agile doesn’t help.
“Doing Agile” and “being agile” are two different things. We shouldn’t conflate the two. When you think of Big-A Agile, think training wheels–not a bike. At some point you’ll want them off. But the mindset–towards faster feedback, learning, and ultimately value delivery–that’s something we can all get behind.
That one there, with the little-a? That’s agile.
What are you thinking? Buy the premise, or take a different view entirely? While I’ve offered a few modest observations, they’re being challenged (daily) by both new research and my own experience and thinking. Wherever you’re at, I’d love to hear your thoughts and keep the conversation going.