Agility

By the time you get to my age in the software industry, you’ve probably dealt with your fair share of “agile” ceremony. You may have gotten a fair bit bored and disillusioned with SCRUM, with retros, grooming meetings, sprints, and so on.

You’ve probably seen a lot of the things I have — sprints that never have a fixed scope, work that gets pulled in without being groomed, “wind in my sails” retro games, hour-long grooming meetings where two or three colleagues go into the finest of detail about what the field list on that GraphQL type should be. Maybe you were one of those colleagues?

I can think of few people who have a healthy relationship with the concept of “agile.” Even very capable engineers and product people often fall either on the side of frustrated rejection or resigned acceptance. Both of which actually rather miss the point — and it is a rather sharp point.

If you’ve never read the actual manifesto, you should definitely do so. It’s barely a page:

Agile Manifesto

It’s a pretty straightforward commitment to a rather straightforward ethos. But let’s boil it down even further, alright? It is a little too contingent on the circumstances of its inception — these were luminaries of software development responding to their contemporary historical realities.

A Purified Version of Agile

Here is a more purified version:

1. Understand the value proposition.
2. Have a desire to deliver it.
3. Take the minimal amount of action before updating your information.
4. Meet reality as often as possible.
5. Accelerate.

There’s nothing about two-week sprints and grooming meetings there, right? Funny, that. It is true that a whole cottage industry has grown up around “agile” concepts that really are at best tangentially related to agile principles.

It’s worth understanding what those methodologies actually brought to the table too — because you may, in fact, find yourself at some point in a position where they are your optimal modus operandi. But the trade-offs are not “agile” trade-offs; they are trade-offs for value, delivery velocity, and minimal action.

SCRUM and Two-Week Sprints

Let’s take SCRUM and the famous/infamous two-week sprint. Why in the world would you try to lock scope for two-week intervals? In proper SCRUM, you’re actually expected not to have “specialists” in your team per se, but rather to be fully cross-functional and able to complete stories. People who finish their piece early should assist those running late — holding to a rigid scope being completed at the end of those two weeks is the entire point.

Well, if you’re doing white-label or consultancy development for a customer setting and reviewing the requirements — that’s exactly what you should do. You become a predictable partner, you present a clean façade of two-week delivery under clear circumstances and ceremony, and you’re able to reduce the discussion and approval cost on your work massively by being able to cheaply and frequently pivot.

The people who came up with SCRUM understood that clients often don’t even know what they want until you show them something they don’t want. Yes, you sacrifice the throughput of the individual developer, but you substantially cut the overhead of fuzzy requirements, long iteration, and unhappy clients who get something they didn’t want after three months of waterfall development on your part.

Product Companies and Flexibility

Does it make sense if you’re a product company and your stakeholders are internal, your product team is fine-tuning your vision multiple times a week, and you can be flexible on your delivery cycles? NO! But that’s most of the software world nowadays, right?

It’s a bit of a tragedy that the tooling is so tuned to handling the popular case, not the effective case. A company like Atlassian would love nothing better than every software company adopting two-week sprints — they have mountains of software available to support that use case. And then you’ll see this same assumption propagate as a network effect across even more modern tools that will yoke AI into the task of measuring your sprint velocity, scope drift, and so on.

The Essence of Agility

But if we think back on what “agile” really means? You probably don’t need it. Be aware of the value, effort, and velocity of your working mode, and then tune it to your specific circumstances.

Maybe that means Kanban. Maybe that means retros once a month. Maybe that means a custom ticketing system to handle your very particular set of stakeholders.

Bottom line: you’re responsible for being agile, not the methodology.