I recently heard the claim “Agile is good for developers, but bad for management.” I don’t agree with that view, but it did get me thinking a bit about why someone might say that.

Over the years, I’ve also heard another common complaint about agile, which can be summarized as “Agile is good for management, but bad for developers.”

Obviously, both can’t really be true. But it seems that both are common views.

And I think both failure modes are the cause of essentially the same thing: Treating “agile” like a smorgasbord.

If we look at the Manifesto for Agile Software Development, and perhaps even more important, the associated principles, I think we see a pretty well-rounded approach to software development. It’s not detailed, to be sure, but it definitely pays attention to the needs of both business/management, as well as software developers. There’s no real favoritism going on. There certainly isn’t anything I can point to in either document that is “bad for management” or “bad for engineers”.

But, if we start to pick and choose which parts of the manifesto or principles we care about, at the exclusion of others, we can start to approach something lop-sided that favors either developers or managers.

For example, one of the arguments that “agile is bad for management” was the idea that “agile rejects deadlines”. But does it? “Welcome changing requirements” is not the same as rejecting deadlines. And it’s certainly not an excuse to ignore a deadline from management. The second principle says

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The goal here is actually to help the customer, not ignore them!

On the other side, I hear complaints about things like “dailies worthless for developers” or “sprints are just mini-waterfalls” desgigned to make management feel better. Worthless dailies and mini-waterfalls aren’t in line with the spirit of the Agile Manifesto any more than the idea that deadlines are anathema.

Both views are based on a skewed history with agile projects. And at best, they’re the result of cherry-picking parts of agile, while ignoring others. In the worst case, they may be the result of just a complete misunderstanding of agile.