I got hung up on a conversation the other day about projects. The conversation went something like “we don’t do projects anymore, we do Agile. There’s just a continuous flow of value to the customer.” It’s hard to argue with, because what they’re saying is “we’re different and therefore you can’t put us in that bucket with the waterfall stuff.”
So I looked up the definition of “project” and here’s what Google gave me back:
an individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim
Interesting. It doesn’t say anything about project plans, or budgets, or team structure, or timelines, or scope or any of that. A project is, in my words, a group of people getting together to get something done. (And don’t get on me about Agile isn’t planned all up front. You plan constantly in Agile and adjust to what you’ve seen at the start of each sprint. To paraphrase, “plans are useless, planning is critical”)
Pretend all you want that it’s something different, but at the heart of things you are arguing semantics. And this matters, because if the goal is to avoid evaluation by measurement then the first thing you want to do is argue that something is apples vs. oranges – comparisons cannot be made.
That said, I don’t think measures like on time or on budget make any sense for Agile projects. Of course, I don’t think they make any sense for waterfall projects either. The issue with on time and on budget measures is there are two things that go into whether you meet that outcome or not. The first is whether you have managed your work well. The second and frequently ignored part is whether your estimate was any good in the first place (for duration or effort). You can’t actually know which happened, in a deterministic manner, though you could evaluate your development practices over time and the ways you make estimates to figure out what might predict better outcomes. But I’d argue instead, for a given amount of work, what you’re shooting for as an organization is to be more productive and that has little to do with on time or on budget. Anyway, I digress (which I’m wont to do).
My point is this: if you want to measure the organization’s project-delivery performance, don’t get caught up in semantics about whether something is a project or not. Find a reasonable measure of a group of work (might be a traditional project with all the IT project management stuff that goes with it or might be a “feature” or an “epic”) and then set out to measure the outcome of the work in such a manner that you can make comparisons between different chunks of work. You’ll be a far better position than if you say “oh, we simply can’t compare those things.”