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.

"agile" versus "Agile"

I am a big fan of agile project management.
Scrum - or something very like it - is my default approach.
There can be huge benefit to eliminating waste.
eXtreme Programming, Test Driven Development and other development practices definitely have their place.

What I don't like, what I do not believe is ever the right or appropriate thing, is dogmatic adherence to any particular process, approach or manifesto.

In this blog, if I say "agile" with a lower-case "a" then I mean the good and valuable attribute of being able to react with agility. If I use the upper-case "A" - "Agile" - then I'm likely being ironic or scathing of the idiots who stick blindly to the words of the over-paid Agilista consultants, and are therefore anything but.

First Post

Well. A first post titled "first post". That's original!
Last time I had a blog was back in the days when you had to provide your own hosting and upload all the files with FTP - and I spent more time pratting about with learning about CSS, JavaScript and cookies than I did writing content.

Many things have changed since then - I'm writing this using a wifi connection on a touchscreen phone - but my ability to write amusing and informative content probably isn't one of them.

So I don't really expect to keep this up for long; but many times recently I've found myself wanting to comment on things that are too geeky for facebook or too complex for twitter's 140 characters. Maybe I'll write them here and maybe I won't...

(And in case you're wondering about the title, my name is an anagram of "Damn Fathomless Prattler" and I like the nod to incomprehensibility and lack of depth!)