Guaranteed Endpoints

Stuart Lynn gave a good answer to what I thought was a pretty weak question on Quora the other day: What's the "right" method of project management in IT? Stu noted that "its not always clear from Scrum what the guaranteed endpoint will be" and I wanted to pick up on that.

I would actually go further than Stu and say that it's never (or at least very rarely) clear what the guaranteed endpoint will be. In fact, that's kind of the point!
Scrum - and other agile processes - assume that you won't/can't have a full and correct understanding of the requirements at the outset. They assume that requirements will change: new requirements will appear, understanding will improve. The idea is to have a good, clear, visible picture at all times of what you expect the end-point to be... but "guaranteed"? Nope.

Does that matter? Scrum favours the ability to change your mind over the ability to predict exactly what you'll deliver. For the vast majority of projects, certainly all those I've ever worked on, this is appropriate. There ARE projects where this may not be the case - ATC software, missile guidance systems, for example - where a precise endpoint can and must be guaranteed. For these, the ethos of Scrum is inappropriate (although some of the practices may still be useful).

In the world of shrink-wrapped commercial software, I personally don't believe this is the case. Yes, there can be absolutely iron-clad requirements that cannot deviate, but I've never seen a full project progress from start to finish without change.

Of course, this can make life very difficult for Product Managers and Marketing Departments, but no-one ever claimed Scrum was easy (well, maybe some disingenuous consultants...). At the end of the day it all comes down to a simple question:

Is it more important to build the right product, or to know exactly what you're going to deliver?

That's NOT a rhetorical question, but if you're going to go with the second option you better be sure you meant it!

Of course, real life isn't always clear cut; the line from agility to certainty is a continuous spectrum and you have to make the appropriate choices depending your needs and preferences. Which is why my own answer to the original question would, like Stu's, have amounted to "it depends" - but unless you're a long way over towards the extreme then Scrum may be a good fit.