A recent shower thought of mine is that agile software development might be similar to the strategic concept of a glass cannon in gaming — specifically, that it’s a high-risk high-reward strategy where the risk can be mitigated by skill/experience.

Glass Cannons

In gaming, a glass cannon is something with very weak defensive capabilities (hence the “glass”) but very strong offensive capabilities (hence the “cannon”). The strategic idea is that if you can survive long enough to get your attacks in, then you will win due to having the superior offence. The difficulty is that you can’t engage your opponents on an equal footing because if you’re both attacking each other then you’re both going to take hits, and your defence is so poor that if you take hits you’re probably going to lose.

The effectiveness of a glass cannon strategy really depends on your skill level.

To succeed with a glass cannon strategy, you need some kind of non-standard defence. In skill-based competitive games like DotA 2, one such non-standard defence is decision making. The best DotA 2 players are able to avoid disadvantageous fights by anticipating all the probable behaviours of their (human) opponents and using that to make good decisions about when and where to move.

So the effectiveness of a glass cannon strategy in DotA 2 really depends on your skill level relative to your opponents’. When your opponents are more skilled than you, you get shrek’d. They repeatedly surprise you — appearing out of nowhere and attacking you before you have time to react. But when your opponents are less skilled than you, there are no surprises. Everything goes according to plan. When they jump out of the trees to catch you, you saw it coming and you’re already gone. Now you’re the one appearing out of nowhere, wailing on them from an advantageous position where they can’t hit you back.

Agile

What does this have to do with software development? Well let’s say we’re spinning up a new software company and we’re choosing what our workflows and processes will be. Maybe I’ve experienced a high-performing team in the past that was really into Kanban and talked about “agile” a lot, and I want to replicate that. So we move ahead with a Kanban workflow and try to do all the agile stuff.

Agile’s de-emphasis on prescriptive process means that success largely depends on the skill and experience of the individuals involved.

But it doesn’t work. On the previous team, when you picked up a card it had everything you needed to do a good job. On this team, the cards are a mess. On the previous team, we would deploy changes quickly, see the results, and instantly course-correct if necessary. On this team, initiatives drag on for weeks or months and get abandoned after release, with sub-par results and significant technical debt that never gets revisited.

This scenario isn’t uncommon, and may even be the norm when attempting to implement an agile way of working. Yet many people — myself included — still consider agile methodology to be the best way to achieve top performance from software development teams.

Where does the mismatch in belief and reality come from? I think the very first line of the Agile Manifesto is a hint: “individuals and interactions over processes and tools”. The emphasis on individuals, and de-emphasis on prescriptive process, means that success largely depends on the skill and experience of the individuals involved.

Exactly what level of skill and experience is required to get good results? It’s impossible to give a definitive answer, but thinking about this a bit recently, my opinion is that the level required is probably dishearteningly high compared to the average for the industry.

Bringing It Together

So if I believe that…

  • the likelihood of implementing agile methodologies well in an average software development team is low
  • but that it’s necessary for top performance
  • and that success is largely determined by the skill and experience of the individual team members

… then I’m saying that agile is a glass cannon: a high-risk, high-reward strategy where the risk can be mitigated by skill.

Agile advocates are sometimes accused of being overzealous — claiming that agile is the best way to work, and that everyone should be doing it. Reframing it as a glass cannon brings attention to the fact that, like everything, there is a tradeoff. Even if, for the sake of argument, we assume that agile has the highest potential, that does not necessarily make it the best choice. Context is crucial. It’s not a silver bullet that magically one-shots the software development werewolf we’re all facing.