Now...anyone that has done any work utilising SCRUM will happily tell you that implementing the full SCRUM method into a small development team is quite difficult...even unnecessary. Ask any SCRUM instructer and they will tell you if you DON'T implement the full SCRUM method ... then you aren't using SCRUM.
Keep in mind though that SCRUM was designed initially to be implemented in large groups of developers for large projects in large companies. It works great in smaller projects too with some modification and ensuring that you keep a few basic guidelines in mind.
Truth 1: Rely on the Team. If the team is a very skilled one that has worked well together then they need less and less management. In a high accountability team you need less oversight.
Truth 2: The Product Backlog is King. Make it well, update it often and keep it accurate. If this is followed you can skip huge amounts of unnecessary admin.
Truth 3: Rely on Your Data. If its quacks like a duck, walks like a duck and looks like a duck - it's a damn duck. Don't rationalise the data, accept the findings and identify problems early and fix them.
The Barebones SCRUM Implementation
If the above truths are well in-hand for you as the SCRUM master then this is the bare bones structure you need to implement SCRUM properly:
- Create the product backlog. If you want a template to start with use my one here.
- Do daily stand-ups every day. No exceptions, nobody gets to skip it.
- Measure your results each sprint, don't skip it. Analyse the data together with the team and get team buy-in on the conclusions.
- Do not run from problems. Engage the team in the solution. A large problem is not fixed by ignoring it and solving an easier one.
- Do a project review session after the project to identify what you have learned.
How do you know you need to use SCRUM?
If your turn around time is less than a month, then you don't need SCRUM. Each sprint should be at least 2 weeks long and there should be at least 2 sprints for SCRUM to be needed. Why, you say? Because SCRUM is an iterative method of improving results based on data. If your project lasts less than 4 weeks any data you collect will be incidental and not yield correct results.
If you project team consists of less than 3 people you don't need it. Perplexed as to why? Because you need to analyze the data in a group and if you don't have enough people to weigh in and consult - you may very well draw the conclusions you want. Two people can convince themselves of anything, a dissenting majority requires at least three people to happen.
If you are going to be doing only one project in your working life - don't bother with SCRUM. It's designed to improve over iterations of many projects, not to slam dunk one.
Scrum Official Site: http://www.scrum.org/
The Agile Manifesto: http://agilemanifesto.org/
Other Agile Methods: http://en.wikipedia.org/wiki/Agile_software_development
Like what you've read?