How to Make Scrum Fail

a lot of people have heard about scrum; some of them know what it is, some of them have 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.

you may also like:  5 reasons why scrum fails in software development 

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 

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.

 bad product owner 

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.

 bad scrum master 

 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.

 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 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.

 wrong definition of done 

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.

 no velocity tracking 

 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.

 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  ). not a single person but the entire team owns the story and testers should be part of the team.

 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.

 interruptions/po bypassed 

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.

 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 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.

my advice/conclusion for those who want to try scrum and want to succeed with it:

scrum is not a silver bullet. it’s no methodology that defines a lot of rules. instead it’s a framework which defines some best practices. of course you’ll have to adopt the basic principles to make it work. but how some things are filled in (when do we do standups, how does a task card look like, …) is up to you and can differ from project to project.

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  …

 originally published feb. 4, 2013 

further reading

 what product owners should not do 

 10 common scrum mistakes and how to avoid them