Zealots are born when work starts working. Through sheer force of charisma, and with every good intention, they make enough noise to attract attention. In the case of Agile, what began with engineers soon grew to catch the ear of global consulting firms.
The job of these firms is to listen closely to the problems companies are having, and then use what they have heard to convince them to buy services off the shelf. So Agile was inflicted on a wave of knowledge workers, spread out and tamped down by the bulldozer bucket of big-n consulting.
The problem is that whenever you take a set of systems and rituals that is working in one domain, and simply apply the mechanics to another domain, you often lose the intent along the way. So cargo cults are born, and round pegs mashed into square holes.
Classic, by-the-book Agile works beautifully well for makers whose outcomes are well-clarified, but who encounter high levels of complexity and risk strewn along the path to completion. This applies to software engineers, data scientists, tax accountants, certification and compliance managers, manufacturing prototyping, and many other left-to-right disciplines requiring technical skill. It also only works downstream of a solid product definition process, of which sprint planning is only one small part.
Most knowledge workers are exactly the opposite — the clarification of their outcomes in the first place is, in fact, much of the job. Tracking outcomes to completion, holding each other accountable, and visualising progress along the way is no less important. But most marketing teams don’t need formal daily scrums or weekly retrospectives, let alone to bid on parcels of work in made-up units of sprint points.
They do, however, need everything that is behind Agile. They need some way of visualising who is doing what — at the appropriate high level — to support each other in keeping their commitments to the group. They do need tactical sync-ups using visualisation of shared commitments (albeit maybe not daily or while standing). And they do need some kind of periodic look back on how they are doing what they are doing. It doesn’t have to be a daily scrum, a weekly retrospective, or a KANBAN board. But to function as a high-performing team, these fundamental rituals and systems need to be there.
Mechanics are easy to productise and scale, and the firms who have been touting Agile to other markets are all about scaling what’s hot (and sometimes, some time later, doing a volte-face to ride the counter-movement, then packaging and selling that as well). The intentions behind Agile are not a fad, however — they’re something much more like common sense not commonly applied.
For those who live within the organisational structure day-to-day, common sense talks. One way to get there for the Agile-disillusioned is not to swing violently toward the next buzzy paradigm, but to begin dismantling the Engineering-specific elements that were never meant to apply: meeting every day in a proscribed format, defining work units in tiny increments, and measuring velocity. From the other side, for the Agile-curious, try adopting and then adapting components, scrutinising their effectiveness in an honest way.
Here’s the kicker: most teams think they need greater agility when they actually just need more focus and execution. The real secret to Agile teams that work in engineering is having a product strategy that’s actually being used. The way you know that strategy is being used is by the extent to which it is causing people to say “no” to distractions. This is how Agile, for all its output-specific focus, can actually be used to manage to business outcomes.
Agile isn’t going away in engineering until we can find something better. It’s been about twenty years now, and so far the best alternative to Agile is actually doing Agile properly. That typically means more strict adherence to the format of the rituals without losing sight of their intent. For everyone else, I suggest the opposite–start with the intent, test the rituals against those intentions, and build from first principles into a working practice that your team can embrace as their own.
Good systems and rituals make good teams. Find them, adopt them, adapt them, defend them. And call them anything you want.