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.

1. No or bad retrospectives

   
   

   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.

2. Bad Product Owner
   

   

   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.

3. Bad ScrumMaster
   

   

   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.

4. Scrum Ceremonies are taking too long
   

   

   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.

5. Wrong definition of done

   

   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.

6. No velocity tracking
   

   
   
   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.
   

7. Waterfall within sprint
   

   

   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:

   • tasks should be clear before starting the sprint. This requires that analysis (on story level) should be ready at least 1 sprint ahead.
   • 1 developer picks up 1 task at a time and focuses on finishing it as soon as possible
   • when picking up a new task, a task from a story in progress needs to be picked up first in order to complete the story as soon as possible

8. Technical debt
   

   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.

9. Interruptions/PO bypassed

   

   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.

10. No analysis/documentation
    

    

    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.

My advice for those who want to succeed with Scrum:

• Scrum is a completely new way of thinking and mind-set shifting compared to waterfall.
• Scrum is not a silver bullet. It’s no methodology that defines a lot of rules. Instead it’s a framework that defines some best practices you’ll have to adopt to make it work.
• Preparation, planning, tracking and follow-up are crucial. This should be done at task level, story level and sprint level.
• You need discipline to make Scrum work. If you don't follow the basic rules and don't stick to them day after day, it will definitely fail.

The cartoons used above are copyright of Implementing Scrum.