How to Make Scrum Fail
A lot of people heard about Scrum, some of them know what it is, some of them tried it already and for some of them it failed. In this blog post I’ll enumerate things you should do if you want your Scrum project to fail. For those who don’t like failure, keep on reading the descriptions below each topic, they’ll help you to make Scrum succeed.
I won’t cover Scrum basic principles like sprints, daily standups, task board and burndown because I expect you know them. Those are things you must do if you’re implementing Scrum, I think that’s quite obvious.
- No or bad retrospectives
- Bad Product Owner
- Bad Scrum Master
- Scrum Ceremonies are taking too long
- Wrong definition of done
- No velocity tracking
- Waterfall within sprint
- Technical debt
- Interruptions/PO bypassed
- No analysis/documentation
How would it be possible to make things better if you’re not looking behind? Retrospectives are required because there every team member can communicate what went good and what could have been better. And of course you’ll have to learn from your mistakes. If that isn’t done, retrospectives are useless.
The Product Owner should be available at any time. He should participate in standups, retrospectives and sprint planning but he should not estimate tasks during sprint planning because estimations are the team’s responsibility. 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 roadmap. He should define the stories in a way that they are clear enough for the team to understand what they mean. On-going changes shouldn’t be present in the Sprint Backlog.
The Scrum Master should not become a team administrator. The team should be self-managed. The Scrum Master should not lead but steer 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, they 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 ups shouldn’t take longer than 10 or 15 minutes depending on the team size.
Retrospectives and sprint planning meetings should be timeboxed. 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 produced software product should be production ready and thus demo-able. This means that it should be tested, not only by unit and integration tests but also manually. And of course the developers should know about the exit criteria the testers are testing against or there’s a mismatch between automated and manual tests.
Team velocity should be tracked. The Scrum Master must undertake some action if the team is slowing down. He must find the root cause by means of the 5 why’s method or Ishikawa’s fishbone diagram.
It’s better to have 75% of the stories 100% done than having 100% of the stories 75% done (cfr. definition of done). Not a single person but the entire team owns the story and testers should be part of the team.
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 which means that too many interruptions are bad. One can ask for support of course but new features should be requested to the product owner. He should add it 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. One should not send feature requests to team members directly.
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 enough for the team to split it up in tasks and estimate them during sprint planning (= at the moment the story will be implemented in the sprint, it should be detailed enough) . 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.
Scrum is a completely new way of thinking and mind-set shifting. It is not just a list of practices: if you “stand-up” it doesn’t mean you do Scrum …
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)