Personal opinion on software development in general, development methodologies, tools and best practices in particular

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.

  1. No or bad retrospectives
  2. 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.

  3. Bad Product Owner
  4. 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.

  5. Bad Scrum Master
  6. 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.

  7. Scrum Ceremonies are taking too long
  8. 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.

  9. Wrong definition of done

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

  11. No velocity tracking
  12. 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.

  13. Waterfall within sprint
  14. 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.

  15. Technical debt
  16. 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.

  17. Interruptions/PO bypassed
  18. 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.

  19. No analysis/documentation
  20. 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 …


Comments on: "How to make Scrum fail" (18)

  1. Another excellent post!

  2. Congratulations. A very nicely done post. Excellent. Boris

  3. Hendrik Placlet said:

    Interesting post. Contains valuable information about a lot of pitfalls in the IT-world.
    I am not that familiar with SCRUM, but I think that a committed product owner is the first requirement to start with a productive project.
    Keep up the good work.

  4. Retail said:

    What a wonderful read thanks for the insight loved it !…

  5. Nice post!

  6. Just want to say what a great blog you got here!
    I’ve been around for quite a lot of time, but finally decided to show my appreciation of your work!

    Thumbs up, and keep it going!


  7. thank for your artikel..;p)

  8. Nice to post to read.

    I would also include:
    – make sure all stakeholders are involved during the post-iteration demo
    – plan spike (technical investigation) as stories to explore uncertainty in terms of technology/design/technical complexity in advance

  9. […] How to make Scrum fail ” about:software development ( […]

  10. Quite a beautiful website. I just finished mine and i was looking for some design ideas and you gave me a few. The website was developed by you?


  11. […] The busiest day of the year was May 10th with 592 views. The most popular post that day was How to make Scrum fail. […]

  12. […] nosso caso precisamos tirar prazer dos pedacinhos entregues a cada iteração. Isto quando o sprint não falha. Algumas vezes acontece por erro na previsão no planning. Mas em outras é porque alguma coisa […]

  13. Rickf said:

    Scrum is a big waste of time. I’ve be et experienced a more inefficient or sloppy way to write software. It’s for managers who have no value other than to tell people to update thei tasks so the rundown will look better. Really, I’m not saying all planning should be up front….just that this stuff borders on cultism.

    • Rick,

      Scrum is absolutely no waste of time. But it seems that you were doing scrumbut. A lot of people who don’t follow all the scrum rules (which is called ‘scrumbut’) give scrum a negative connotation, which is normal. In scrum, the team is self organizing. The scrum master takes decisions when needed and tries to optimize the team’s performance. The product owner decides which features should be implemented and which functionality has the highest priority. There shouldn’t be a ‘manager’ who are you reporting to during stand ups or something. No, each member of the team reports to the other team members. You decide which task you take… But you shouldn’t analyze things in the same sprint as in which they are implemented. Analysis should be done before implementation (at least 1 sprint earlier). And you’ll have to do some upfront stuff like creating a good architecture. If you do all those things during the sprint, it won’t work…

  14. I almost never leave a response, however i did some searching and wound up here How to make Scrum fail about:software development.

    And I do have a couple of questions for you if it’s allright. Is it just me or does it look like a few of the remarks look like left by brain dead folks? 😛 And, if you are posting on additional places, I’d
    like to keep up with anything new you have to post.
    Would you make a list of all of all your community sites like your twitter feed, Facebook page or linkedin profile?

  15. Great site. A lot of useful info here. I’m
    sending it to some pals ans also sharing in delicious.
    And naturally, thank you to your effort!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: