This Blog Has Moved!

Right, so yes, five years ago I moved to github pages, and never bothered to redirect any of these pages there. Now I've moved on from there, and... Finally I am using my real domain, trishagee.com . My blog is now at trishagee.com/blog .  See you there!

Scrum

I think the statement that struck me the most when I was on the Certified Scrum Master course was: the start of the project is when you know the least about what you're doing.

Which of course is absolutely true.

So why do we come up with extensive requirements, detailed design, and fixed plans at this point of time?  We haven't put anything into place yet, we haven't played with the code, the customer hasn't seen anything of what we're promising to deliver.

If we think about it this way, suddenly the waterfall method makes even less sense (assuming people do still like to work this way).

How many times have you just played with a bit of code, done a prototype, a "hello world", knocked up a basic screen, before you can even give your manager some finger-in-the-air estimates?  I don't know about you but I'm not comfortable unless I have played a bit to get the feel of something before even looking at someone who asks those questions!

The empirical approach makes a lot more sense to me.  So why aren't we doing it more?  

Because it's harder.  

I think it's harder because it works, but I daren't make such a bold claim without having a number of such projects under my own belt, or at the very least digging through the web to find examples.  Which frankly I'll leave to you to do, if it matters to you.

Comments

Popular posts from this blog

Dissecting the Disruptor: What's so special about a ring buffer?

Dissecting the Disruptor: Writing to the ring buffer

Dissecting the Disruptor: Why it's so fast (part one) - Locks Are Bad