So you've decided to try Scrum as your development methodology. Good! To start off on Scrum I relied primarily on these two documents:
- "Scrum in Five Minutes" by Softhouse [PDF]. It really is what it claims: A simple, understandable guide to the roles, responsibilities, and processes defined by Scrum. For my first few sprints and roadshows I would present this document first to get everyone speaking the same language.
- "Scrum and XP from the Trenches" by Henrik Kniberg [PDF]. A 142-page ultra-detailed user guide on how Henrik implements Scrum. A must-read for potential Scrum Masters or anyone wanting more detail on how Scrum works. About six months after you've been implementing Scrum you'll want to read it again.
There are also key web sites to help you:
Personally once I had read the documents, attended training, and implemented Scrum I found I didn't rely on the web much if at all. It takes a lot of discipline just to keep the Scrum ceremonies going, and if you know what they are (such as the daily stand-up meeting) there's not a lot of mystery or refinement required.
My primary advice, though, is to make sure your team is adopting Scrum for the right reasons.
- Your requirements change often, usually near the end (or after the end) of the project.
- Your team has a hard time handling change at any stage of the project.
- All of the team's planning, scheduling, and velocity estimates are based on subjective data (like gut-feel).
And I do say "team" purposefully. We found that a Scrum team under the recommended five person minimum is a lot of overhead per resource. Due to attrition we're currently scraping by under the minimum, and as Scrum Master I can tell you it's more difficult to keep a few people at full capacity for a long duration than a larger team. You tend to get tunnel vision and a bit burned out trying to maintain too high a velocity.
Set some goals for your Scrum adoption before you jump in. Mine were to increase my team's agility (no more last-minute rewrites of fundamental components), predictability (knowing how much work we could do in a given time span), and visibility (where the customer always knew our status and plans). Take some time to think about your problems. If small iterations and a high-level of customer interaction won't solve them, don't adopt Scrum for that purpose. I'm sorry, but no development process in the world can fix a development team whose primary problems are lack of skill, lack of motivation, or poor management.
Last but not least, when you first adopt Scrum my advice is to implement it "by the book". Don't tweak it before you've tried it. Do the daily stand-up meetings. Slog it out through the initial, painful Product Backlog generation. And do this for a few sprints. If you don't like it after that by all means change it. After all, Scrum is a flexible framework. It's not like trying to swim up a waterfall.
Technorati tags: Scrum Agile