Making the switch to Scrum – Part One
Rugby, bad. Delivering on-time, good.
It’s not a quick undoing years of sedimented project management technique. You can read about agile and the Scrum methodology on many websites, but here is what we have learned since switching to Scrum:
1. The buy-in
Fear is to be expected when a company director swans into the studio after a fancy workshop in London saying, “We’re going to change how we do EVERYTHING!”.
Fear not, because things don’t actually change an awful lot. It’s as much a conceptual change as a practical, production-focused change.
Firstly, run the team through the “why?” of Scrum. Ignore the buzzwords and explain:
- There will be no more discussions over 2 month-old wireframes or trying desperately to remember the list of changes.
- Everyone, including the client, will know what is going on at all times. Transparency, yeah?
- The client can request changes and we’ll be ok. They just go in the next sprint. We won’t feel screwed.
- Fewer late nights attempting to deliver 3 months of work all at once.
2. A white-board Sprint board
Make it so that you can write on your Scrum board. People can write around the tickets and you can order the track easily. We got our white board paint from here (it’s fairly pricey stuff, but works like a charm).
3. Post-its: only the toughest glue survives
Buy super-strong-glue post-its. They’ll be up for weeks at a time and won’t float off like autumn leaves. This is annoying, not to mention distracting.
4. Storing the master project backlog: Spreadsheet? Ticketing system? On paper?
Keep them separate from the Sprint board. We keep our master backlog in Hercules, our custom bug-tracking system, so people can add tickets on the fly.
At the beginning of the project the team will order the user stories with the Product Owner (usually the client) so we Post-it note everything first, then the scrum master adds everything to the digital master backlog. The Post-its are added to the sprint board as the project progresses.
Thanks to agile supremo @pitkin for the helpful advice in this area.
5. Common Agile / Scrum questions
Question : Does this really work?
(“Sounds like guff. But if it works my life will be so much better, thanks.”)
Answer : Yes, it does work. We have felt more organised, been better able to prioritise tasks, and the whole process has been more transparent for everyone. Yes, it does sound like guff.
Question : Why can’t we measure things in time!?
(“Story points are weird, please explain it again.”)
Answer : We’re still not sure about this one. Story points are meant to give you a more realistic idea of ‘velocity’ (how much work you can complete in a sprint), but hours are much easier to understand. If you are realistic, and keep updating your estimates as the project progresses, measuring in hours will do just fine. There is a good post about it here.
Question : Is the client really allowed to change things?
(“That’s too good to be true, tell me about the a sprint backlog again.”)
Answer : Listen to their changes, add them to the backlog and talk about them for the next sprint. The client will know exactly what you are supposed to be getting done in the sprint, and thus understand that any changes will knock other work out, or cost more money.
Question : So, who’s my project manager now?
(“Organising my own tasks sounds like hard work. And Scrum Master is a stupid made up title, I’m ignoring it.”)
Answer : Every team member is their own project manager, so get self-organising. Make sure the whole team is invested and involved in the project from the outset (Project and Scrum Kick-off meetings!) This way they have a much better idea of how to handle issues and questions that come up.
Question : What is grooming?
(“Er, grooming? Industrial action waiting to happen?”
Answer : Weird term for looking through the backlog, organising and filling in any gaps before the next sprint.
More info in Part 2 next week, including our quick guide to the confusing world of scrum terminology.