7 ways to sabotage your shift to agile

Agile should be yesterday’s news. Really, yester-decade’s news. The Agile Manifesto appeared nearly twenty years ago, and unlike Athena, who sprang fully grown and armored from Zeus’s head, many of us had practiced or encouraged agile-ish techniques long before the manifesto made them official.

And yet, some fearless holdouts have managed to keep agile, with its higher rates of success and business satisfaction, at bay. If you’re among them and you’re under pressure to “go agile,” it’s time to stop feeling like a dinosaur waiting for the asteroid to hit. Here are seven proven ways to take the offensive and surely prevent agile from happening to your IT organization without you gaining a reputation for being sand in your company’s progress gears.

1. Call it Agile. Make it haphazard

As you launch your next project, insist the project manager run it the “agile way,” with everyone on the team figuring out each morning what they can do that day to move the project in whatever direction they think is forward.

Testing? When the team is ready to test a feature, let the product owner know today you’ll need business staff to bang away at the feature tomorrow. If they won’t be available tomorrow, that’s okay. It just means that feature will have to slide into the next sprint.

And if the product owner complains about the project not staying on schedule, well, this is the beauty part: Just explain that “agile projects” don’t have schedules.

After all, agile means “No Plan,” doesn’t it?

2. Ignore architecture

Don’t waste time early in the project defining the application architecture. If agile means requirements continuously evolve, shouldn’t the application architecture continuously evolve, too?

So don’t constrain developer creativity by insisting on conformance to a bunch of abstract principles. Instead, empower your developers. Let them develop however they want to develop, structuring their modules and interfaces however they like. And if different modules from different developers don’t plug and play together, or different developers write code that depends on different libraries, don’t worry about it. That’s what refactoring is for.

Heck, if different developers want to develop in different languages, well, that’s what containers are for, isn’t it?

3. The answer is Scrum. What was the question?

Agile isn’t a methodology. It’s a family of methodologies, each suited to a different sort of project. Scrum has emerged as the most popular, not because it’s “best practice” but more likely because it’s the most rigidly structured agile variant, making it closer to a waterfall shop’s comfort zone than any of the others.

Especially, Scrum is poorly suited to the commercial off-the-shelf software (COTS) and software as a service (SaaS) implementations that constitute the majority of projects IT undertakes. A different Agile variant, conference room pilot (CRP), or its close relative acceptance test driven development (ATTD) are better alternatives.

But who’s ever heard of them? In all likelihood, nobody who matters. Even your strongest political opponents won’t criticize you for choosing the most popular agile variant, and that’s if they know there are other agile variants to choose from.

So when things go sideways with your Scrum-driven COTS implementation, it won’t be because you should have known better. Well, it will be, but you can claim the project failed because agile was never a good idea in the first place, and you can safely hint that anyone who argues otherwise is just nitpicking to protect themselves.

4. Play leapfrog — from Waterfall to SAFe in a single bound

Agile’s charm, and its greatest strength, is its simplicity. Its greatest weakness is that it doesn’t scale all that well.

Smart businesses keep agile agile — so much so that they extend agile principles to encompass, not only software implementation, but all business change. Viewed from this angle, large-scale strategic plans are intrinsically waterfall in nature and fail for the same reasons IT waterfall projects fail: They’re linear, with lots of interdependencies and single points of potential failure; and they’re built on assumptions about the future that will change at least twice by the time the future gets here.

But never mind all that. The CIO’s job isn’t to make the business more agile. It’s to support the business strategy, whether or not the strategy has any chance at all of actually working. And as agile doesn’t scale to strategic-program-size plans, IT needs to adopt a methodology that sounds like it’s agile but scales like it’s waterfall.

Welcome to SAFe — the so-called Scaled Agile Framework (where the “e” comes from is an enduring mystery). But whereas agile itself succeeds through methodological simplicity, SAFe is godawful complicated, with as many moving parts, potential points of failure, and assumptions about the future as waterfall does, with the added bonus of being unfamiliar.

Understand, SAFe isn’t intrinsically bad. But it requires experienced practitioners and quite a lot of program infrastructure.

If SAFe is what the business needs, SAFe is what IT will do, leaping across the Waterfall-to-SAFe chasm in a single bound, never mind the risks.

The program will fail, but your hands will be clean. You already warned that agile doesn’t scale.

5. Insist your development partners use Agile. Also insist they agree to fixed price bids

Of course they have to use agile. It’s better, isn’t it? And besides, you’re schooling every manager in the business in how to work with IT the agile way.

And of course vendor bids have to have a fixed price tag. That’s the only way to keep vendors honest. Otherwise they’d have a “perverse incentive” to slip the project budget and schedule.

And if a vendor has the temerity to point out that starting with a fixed scope and only changing it through rigid change control governance is the antithesis of agile, well, it’s a good thing you learned how difficult that vendor would be to work with before signing a statement of work.

6. Offshore agile

In theory, business planners set goals for revenue, cost, risk, and achieving the business mission. In practice, in most businesses, the projects approved for actual execution are the ones that cut costs.

What better place to start than the rates you pay for developer hours?

So when you engage a development partner, make sure most of its team members live and work 11 time zones away.

Yes, agile principle #6 emphasizes the importance of face-to-face conversations — among developers and between developers and business users. No, offshore developers won’t participate in them.

That’s okay. Ignore it. It’s just theory. Given a choice between saving money and abstract principles, those who save money are the hard-headed businesspeople we need around here.

And when the agile “team” delivers modules that, when they do hit a bullseye, hit one that’s in the center of the wrong target, that’s okay too. Those modules will have cost a lot less, and IT can always fall back on the tried-and-true explanation that “the business” wasn’t clear about its requirements.

That the requirements weren’t clear because of too little face-to-face communication won’t even occur to anyone who matters.

7. Make it all about process

Yes, yes, yes, we all know that the Agile Manifesto prizes “… individuals and interactions over processes and tools.”

But if there’s one thing management has learned over the past few decades it’s that success in business depends on instituting well-defined repeatable processes. Success doesn’t come from relationships, or from employees collaborating to figure out better solutions together.

No, success comes from employees following the processes, step by step as the swim-lane diagrams prescribe.

And as every process designer knows, a good process leaves nothing to chance. It’s up to you to make sure your agile process, like all other good processes, describes how the process flows from bucket to bucket to bucket, with every decision point described as a process branch while everyone involved turns their inputs into outputs that become the next employee’s inputs.

Add enough complexity to the Agile process flow and eventually IT will extend the reach of the EPMO’s project management process enforcement police so they keep a watchful eye on your agile coaches, just as they’ve been keeping your waterfall project managers in line all along.

Remedy: Get with the program

If the seven strategies outlined here strike you as unappealing, you do have one more alternative.

You could surrender to the inevitable.

You could, that is, acknowledge that agile really does work better than waterfall and give it an honest shot.

It will hurt, but think of it this way: knee replacement surgery hurts too.

But in both cases, in the long run, avoidance hurts worse than making it happen.