97 Things Every Engineering Manager Should Know

Chapter 72. Projects for Which Agile Is Inappropriate

Ron Lichty

I encountered Agile for the first time in 1999. Ten years later, I was not only coaching my own teams in it but also teaching it to friends’ teams. One of the questions I repeatedly heard in those days was, “Is Agile appropriate for every kind of software project?”

I wracked my brain for some possible kind of software development for which Agile wouldn’t be a fit. I didn’t have a good response.

The answer leapt out at me a few years later. It was staring me in the face. I’d been stymied because I was looking for a kind of software. The answer was instead a kind of environment. Micromanagement. Agile is not a fit for command-and-control environments.

Micromanagement disrupts Agile. Micromanagement prevents best teams. Micromanagement prevents learning. Micromanaged teams become order takers.

Agile’s self-organizing teams call for everyone on the team to step up. Micromanagement causes everyone to step back.

For teams to self-organize, they must be nurtured, not thwarted. For most teams, self-organization holds the promise to be the most powerful part of Agile—and possibly the most fragile. Over the course of two decades introducing Agile into my teams and more recently parachuting into organizations purportedly already Agile, I’ve repeatedly run into organizations signed up for the ceremonies and practices—sprints, standups, planning, points, backlogs, frequent delivery and the rest—without ever embracing the ...