My last post discussed some basics for starting a sprint - in essence, how two meetings and a little process can dramatically clarify expectations and reduce workload. Having said that, I see time and time again teams who adopt Scrum but build avoidable failures into their project before it even starts.
You can avoid pitfalls by following one simple rule: "When first using Scrum, start with the most formal process." I recommend doing this for at least three sprints, but if you must do fewer, do it for at least one sprint..
Whatever you do, make sure that you:
- Don't skip the daily stand-up meeting.
- It's hard to stress this enough. In my career, this is the most common mistake people make from day zero. Most projects I've worked on have had one weekly status/planning meeting. An inexperienced lead will often say, "I like Scrum, but a daily meeting is too much to ask ." One week later, half of the team is held up due to issues that could have been resolved with communication earlier in the week.
Make no mistake: Scrum turns weekly progress into daily progress. The daily scrum is the key to this rapid pace.
- Define your Scrum roles before the project starts.
- Sometimes old school Project Leads make the mistake of carrying traditional project roles into Scrum. They think that a Product Manager translates to Product Owner, and Project Lead is a Scrum Master. I've found that Product Managers and Project Leads can be completely different from project to project. Scrum roles are extremely well defined specifically to eliminate this variability. It helps to start a project by introducing the person in each role, as well as what is expected of each role.
- Invest in tools.
- Use the many free Scrum tools available. The Scrum Team should be able to see all assigned tasks and their owners at any time. The Scrum Master should produce a burndown chart and use it for trending. One of the major benefits I've found in Scrum is the huge increase in visibility into the guts of the project. Anyone can see the entire list of work to be done, the work we're doing for this sprint, how far we've gotten, and how much work each individual has produced. They can do this because we use one tool instead of email, Word, and Excel.
Moving to Scrum from a traditional project lifecycle is a big change. My advice is to make the biggest change you can, and only then remove the things that don't work for you. Scrum is very flexible and accomodating, but, like medicine, it's most effective when taken all at once.
Technorati tags: Scrum Scrum Process