4 Old School Agile Mantras that Change Agents Should Be Stealing

I think it's a good assumption to say that when agile started to become a big business somewhere around 2012-ish, the intention was lost.

These are 4 super old mantras many of us, uh, older agile fellows live by that capture the spirit of what agile is along with how you can adapt them to the wonderful work you're doing as a change agent.

YAGNI

"You Ain't Gonna Need It." It's like your grandma telling you not to pack your entire wardrobe for a weekend trip. You don't stuff your suitcase with outfits you might wear someday; you pack what you'll actually use.

In software , YAGNI reminds developers not to add fancy features just because they sound cool or because someone says you might need them someday. Keep it simple, folks! Focus on what you need right now and save the bells and whistles for when you're sure they'll be party-worthy.

YAGNI keeps your software lean and mean, ready to adapt to changes without carrying unnecessary baggage. So, in a nutshell, don't build a rollercoaster in your backyard if you only wanted a swing – save the loops for a real amusement park.

How to steal this for change

Leaders might ask for a year long roadmap, but they don't want one. They want some degree of certainty that you know what you're doing. Do what's important now, keep a fungible list of stuff to do next, within the context of the big picture.

Lean Change Element: Big/Next/Now

Last Responsible Moment

You're 3rd in a long line at an ice cream parlour, and you're faced with a choice between flavours. You still have some time to decide what flavour to get before you're at the counter annoying everyone else behind you as you hum-and-haw over what to pick.

In agile, this is called the "Last Responsible Moment," which is a bit like being at that ice cream counter. It's the sweet spot where you make decisions at the very last moment you absolutely have to. You know, like not deciding on a flavour until you're almost ready to order.

In the software world, it means you don't rush into big decisions until you've gathered all the juicy details. You avoid committing too early, just like avoiding the brain freeze from eating ice cream too fast. You let things unfold, gather info, and make choices when you're sure they're the right ones.

By doing that, you stay flexible, dodge unnecessary work, and make sure your decisions are as tasty as that perfect scoop of ice cream.

How to steal this for change

People confuse agility with doing whatever you want, whenever you want. The Last Responsible Moment is about prioritization and decision making. Ask yourself, do we need to decide on this now? Can it wait? When would we need to decide? This goes for training too. We know we're going to need to do training for the new system rollout in 2 years, but we don't need to license the platform and make the plan for that now. It can wait.

Firing a Tracer Bullet

Ok, it's a bad name, but don't blame me, blame Dave Thomas and Andy Hunt. They coined the term in 1999 in the book The Pragmatic Programmer. I read a post many moons ago where someone used a better metaphor called 'walking the dog' - essentially imagine you're walking your dog through a park (the codebase) and make note of all things (features, components etc) that the dog needs to sniff to make sense of the park. If you don't build software, that might be lost on you. Essentially, walking-the-dog is about virtually walk-though the impact a new feature has on the existing system.

Anyway, imagine you're exploring a mysterious forest at night, armed with a glowing bullet that leaves a trail of light. This bullet is your "tracer bullet." It's not for shooting squirrels; it's for finding your way and figuring out what's lurking in the shadows.

In software, a tracer bullet helps de-risk the project by creating a feature through your whole tech stack, not layer-by-layer.

This tracer bullet helps the team see the big picture. It shows how the feature works from start to finish, like a sneak peek of a movie trailer. It's a guide, like a trail of breadcrumbs, that leads the way as you develop the full feature.

People will argue this leads to expensive rework. Yes, if your technical practices are garbage. The rework will be painful if that's the case, but rework is part of software development no matter how you slice it. It's much less expensive to find out early that you've got severe design problems when you try to deliver a small, working feature that's usable.

How to steal this for change

There's a bunch of ways to steal this metaphor for change. The most obvious is for project-based change: create cohorts and split rollouts into chunks. While working for a city, we had 5 departments and 14 groups. A 'cohort' was the combination of a slice of end-to-end functionality and whatever departments and groups it touched. Example: new hire forms. We could build and roll that out without waiting for the whole 3 year program to be implemented.

It's a little trickier for transformational change, but think of it this way. When you want to transform to agile the 'tracer bullet' helps you understand what processes and structures might have to change as a result. I always say that no organization can know how a transformation will affect their organization until they're actively working on it for at least a year and lived with it through every relevant organizational ceremony. It'll affect how projects are funded, how teams are structured, how rewards system work and more. This metaphor can help you 'walk the dog' through the organizational park to get an idea of how much stuff is likely to get peed on. Sorry, that was gross, but probably accurate.

Yesterday's Weather

Imagine you're trying to guess how much pizza your friend can eat at the next party. Do you make a wild guess, or do you look at how much pizza they've devoured at the past few shindigs? That's "Yesterday's Weather" in a nutshell.

In Agile, teams use Yesterday's Weather to forecast the future. Notice I said 'forecast', not estimate. If we got a 23 kilo chunk of work done this past iteration, there's a good chance we'll get about the same amount done this time.

After we have enough iterations under our belt, we get better at being predictable. Not perfect, but better.

How to steal this in change

For project-based change, it basically works the same assuming you're clever enough to get embedded into the agile team so you can merge and synchronize the IT stuff with business readiness. If your organization is forcing the development schedule with fixed scope and time to align with change and business activities...well, don't bother with agile, you've got other problems.

For transformational change, again, it's trickier. Yesterday's Weather can be more about looking at past attempts to transform and using that to figure out how to change the approach this time around. Agile's been around long enough that big companies have been continuously running 12-18 month long transformation programs. After each cycle, the consulting firm is fired in favour of another one, or the 'lead transformation' person is the odd one out and someone new comes in. You can expect today and tomorrow's weather to mimic yesterday's weather unless you consciously choose to do something different.

These 4 mantras give you powerful clues about how to approach the change and situation you find yourself in. If you want to get the most out of 'agile change' approach, whatever that means, these 4 mantras are worth a look.