After my workshop at How to Web in Bucharest today I was approached by a project manager who wanted to know why he should move to Agile. He was clearly very good at his job, things were fine, but Agile still interested him, and he needed a reason if he was to actually embrace it. My first response was that there was no reason why he should: if it ain’t broke, don’t fix it (as they probably don’t say in Romania).

But then he asked in a different way: what were my experiences as a project manager before and after implementing Agile? What differences might he expect? That was a great way to look at it. Here’s a little of what I said…

Less waste

Before Agile I would find myself running projects with wasted activity. We’d spend the first few days creating the database schema and libraries. And then by the time we got to the end some features would have been dropped — maybe because we had to go live sooner than we’d have liked, maybe because requirements were explicitly descoped. And looking back we’d realise we spent days implemented the underlying functionality for those unused featured. Similarly I would have specified interfaces to high level of detail, and yet those interfaces would have changed during implementation. Again, wasted time up front.

After Agile, that doesn’t happen. If a feature is needed it’s implemented top to bottom in one task. If it’s not needed none of it is implemented.

Better software

Before Agile, if that library or database schema was still in use, then often it was in use poorly. We’d implemented it based on expected requirements, but when the day came those requirements turned out to be slightly different. Maybe because of a lack of understanding, maybe due to an actual change. But there wasn’t time to change the earlier work, and we could still manage with a workaround, so that’s what we did. And the result was software that worked, but included serious compromises, to the extent that it was really difficult to evolve beyond the original launch.

After Agile that doesn’t happen. Well, not so much. I’m not sure I’ve ever delivered perfect software, but I’ve certainly — consistently — delivered software that can continue to grow with the requirements of the client and their business.

Fewer difficult change conversations

Before Agile, conversations around mid-project changes were very difficult. If the client wanted a change then they they would hear me act like an unhelpful car mechanic. I’d suck my teeth, exhale, and say “We-e-e-e-ll, it’s gonna cost you….”. We’d worked so far based on a different assumption. So, yes, they could have what they wanted, but at significant cost. Or they could have a compromised version at a reduced cost. What was it to be? Significant cost or compromise? Not a great decision.

After Agile, change is the norm. If you want a change (which might be a new feature, since that’s a change to the software we’ve delivered to date) then we’ll prioritise it appropriately. If it’s going to take 8 days and you don’t want to increase your budget then just take out something else, that’s less important, that’s also 8 days. All features should be interchangable, so you can change your mind a very short notice.

It’s not a perfect world

I was at pains to add that I’ve still had difficult projects before and after Agile. Agile isn’t perfect, and neither am I. (“And,” said my friend, “you’re still dealing with people.”) But undoubtedly the chances of success are much greater, and the general level of satisfaction is much higher.