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.

Author

  • Trisha Gee

    Trisha is a software engineer, Java Champion and author. Trisha has developed Java applications for finance, manufacturing and non-profit organisations, and she's a lead developer advocate at Gradle.