I’m talking at the Agile Professionals Network in Auckland tonight about Scrum. It’s an introductory session for people who haven’t had a chance to experience Scrum yet, so I’m taking a very simple approach to it, going through all the important facets of the roles and the process, and making it more real by using examples from some projects I’ve done recently. (If you’d like to come, and it’s still 12 May, you can register at the APN website).
And the first thing I’m going to say in the session is that the title of the talk contains a kind of lie: Scrum’s not a “theory” any more than riding a bike is a “theory”. You can’t prove mathematically that it works, and you can’t learn either one just by reading a book (or listening to a talk). You have to do it to learn it: they’re empirical skills. They’re crafts, rather than sciences or arts.
I’m going to update this post after the presentation tonight, with a bit more detail about what I said (can’t give the game away now!) and notes on what sort of questions people asked. But for now: what sort of questions do you have, if you haven’t done Scrum at all? and if you have experienced Scrum, what’s the main thing you would tell people who were new to it?
… to be updated tomorrow …
It’s tomorrow now, so here is the slide deck on Slideshare.net:
I’ve also added a link on our APN website, and details about the next APN event. Sign up now, it should be a good one!
I had some great questions during and after the talk. Inbal asked some in a comment below, so I’ll answer those in a follow-up comment. But someone else asked a particularly good one:
What do you do about deployment, especially if it takes a long time? do you do those in a Sprint?
Ideally, deployment would be a one-click process (as Rowan Simpson said here a while ago). But lots of platforms (including two we use a lot at Fronde: Salesforce.com and MOSS) can’t do that easily because of the way they’re architected.
If you can do deployment in one step, or even in a few minutes, you could deploy at the end of an ordinary Sprint in which you delivered stuff (and schedule time to do it, either as a single specific Sprint Backlog item, or by reducing the time-available within the Sprint and formally putting the deployment between sprints .
If you can’t do deployment in one step, you’re going to have to schedule time to do the deployment within (one or more) Sprints. Make a Product Backlog item, put it in the Sprint, and Bob’s your uncle.
And either way, there’s usually pre-deployment stuff to do: this is where the “Sprint N” concept comes in. It’s commonly called the Hardening Sprint, and it’s where you polish and prepare your working software for the full release. It might include final data conversion, last rounds of training, refactoring and retesting, end to end process testing, serious load testing… things like that.
This is NOT an excuse to leave all the testing until Sprint N. That would just turn the project back into a waterfall. Every Product Backlog item needs to be tested, documented, UATed, etc (to make it Done) during the Sprint it’s built in. The Sprint N is to do the overall polish and reduce some of the Design Debt.
There are lots of very good articles on this and other topics on the Scrum Alliance website.
and then throw them out. We use MOSS sites to keep all our project documents and backlog lists, and those stick around.