You've probably already heard of Scrum, the popular agile software development framework. While the basics aren't difficult, a lot of people seem to fail implementing it. In this post I'll sum up 10 things you should do if you want your Scrum project to fail miserably.
How would it be possible to make things better if you’re not looking behind? Retrospectives are required, because there every team member can tell what went good and what could have been better. If you're not willing to learn from the past, retrospectives are useless.
If you do organize retrospectives but do not remove impediments, it still won't work because you'll hear the same complaints over and over again. Problems won't magically vanish, they still need to be solved.
The Product Owner should be available at any time. He should participate in stand ups, retrospectives and sprint planning.
He should be able to prioritize the backlog by business value. For this, he needs to have a vision, a business plan and a release road map.
He should define the stories in a way that they are clear enough for the team to understand what they mean. He shouldn't estimate stories. The team will split up these stories in concrete tasks and estimate them during sprint planning.
The ScrumMaster should not become a manager. The team should be self-managed. The ScrumMaster should not lead but facilitate the team when needed. He should make final decisions if team members can’t agree.
He should be able to make a prioritized impediment list and to remove those impediments as soon as possible. He should keep the team focused and try to improve things constantly: things can always get better.
Tasks should not be assigned to people by the ScrumMaster, team members should pick them up themselves.
In stand up meetings everyone should say what he has done, what he will do and what’s blocking him. That’s all that should be said. A stand up meeting should not be a social talk and you don’t have to provide detailed information. If one needs detailed info he can get it after the stand up.
Stand up meetings shouldn’t take longer than 10 or 15 minutes. If they take longer, maybe the team's too big. You'll also need to stick to what you promise. If you say that you'll finish something today, and you already promised that 2 days ago, then something's wrong. Maybe you underestimated the work, or you worked on something else or something's blocking you. It's important to tell this.
Retrospectives and sprint planning meetings should be time boxed as well. They also need to be prepared carefully. Stick to the essence of the meetings. Scrum should be fun but it’s not meant to be a playground.
At the end of each sprint, the software product should be production ready and thus demo-able. This means that every piece of code should be reviewed, covered by automated tests with a decent test coverage and thoroughly tested manually to guarantee it's bug free. If not all tasks of a story are completely finished, the story can't be marked as done and that story can't be demoed.
Team velocity should be tracked. For example by the amount of story points the team burns per sprint. The ScrumMaster must take action if the team is slowing down. He must find the root cause of the problem by doing some root cause analysis. Using the "yesterday's weather" technique, one should take the amount of story points picked up in the last three sprints to make a good prediction of next sprint's velocity.
It’s better to have 75% of the stories 100% done than having 100% of the stories 75% done (cfr. definition of done). To make this work, the development lead time per task and per story should be as small as possible.
This means that:
Technical debt must be avoided because otherwise more defects will appear at the end and last iterations would produce less new functionality while every iteration should produce as much functionality as others. Refactorings (and redesigns) should be done immediately when they are needed because they cost too much and take too long if done at the end. Bugs should also be fixed as soon as possible.
The team should stay focused. Too many interruptions are a bad thing. One can ask for support of course but new features should be requested to the product owner and not directly to team members.
The product owner should add the new feature to the backlog and prioritize it again. If it’s an important feature, the team can already deliver it at the end of next sprint.
Scrum does not mean that no analysis should be done or no documentation should be written. The way of doing analysis and documenting is just a bit different: it’s a continuous process.
Stories in the backlog should be clear and detailed enough for the team to split it up in tasks and estimate them during sprint planning. This means that stories shouldn’t be too detailed from the beginning of the project (but still clear), but stories need to be estimated in story points when creating the backlog.
The cartoons used above are copyright of Implementing Scrum.
