Thursday, November 5, 2009

Scrum. You're doing it wrong when...

…your sprint is so long that you feel you have to make a time-plan for it.
…your Scrum Master tells people in the team what to do and when.
…the team report their progress to the Scrum Master.
…estimates are not done collectively by the team-members who will be doing the work.
...you hear one team-member say to another; “Sorry, I’m really focusing on my own tasks here in order to finish by the end of the sprint, so you will have to solve your own problem yourself.”.
…all stories in the sprint finish on the last day of the sprint.
…lower-priority stories in the sprint gets done before higher-priority ones.
…the team has as many stories in progress as it has team-members.
…the Scrum Product Owner can’t explain every single story in both the Product Backlog and the Sprint Backlog.
…you still think it’s a good idea to write down all requirements before you start coding.
…you consider customer feedback a risk.
…the team doesn’t know who their Scrum Master is.
…your system testing happens all at once, after a couple of sprints.
…you still think that a detailed Gantt chart is a useful planning tool for the software development tasks.
…your sprints are 6 weeks long.
…the team’s burn-down has been flat-lined for three days and they’re not discussing why.
…you think the customer knows what he wants.
…you think the team knows how to build what the customer says he wants.
…the team doesn’t know how much work is remaining of the sprint.
…you think it’s OK if the team has 45-minute Daily Scrum meetings.
…you come running to the team after a sprint and yell “Hey, we have to release now!” and someone in the team responds “…Oh, but wait, we still haven’t done any system testing… And there’s some more code review to be done too.”.
…the team doesn’t know when and where the sprint demo will be held.
…the team constantly over-commits.
…you think it’s OK that the team has their Daily Scrum meetings every other day instead; “It’s their choice, and meetings take so long, so….”.
…the team is persuaded to add more to the sprint than they really want.
…the team accepts to include stories that have not been estimated.
…you don’t collect feedback from the customer after every sprint.
…the team doesn’t know who their Scrum Product Owner is.
…your team is larger than 8 team members.
…the team doesn’t know what the sprint goal(s) are.
…your Scrum Product Owner misses a sprint demo or a sprint planning every now and then.
…the team decides (or doesn’t follow or care about) the order of the stories in the sprint backlog.
…you think the Scrum Master is sort of like a Project Manager.
… you think Scrum doesn’t require or need planning.
… you think you can’t have a deadline or commit to a scope "because you’re using Scrum".
… you think you don’t need to document "because you're using Scrum".
… you commit both to a certain scope and to a certain date.
...you need to add stuff to the sprint half-way through.
…you think the Scrum Product Owner is sort of like a Project Manager.
…the team doesn’t know their velocity, or the meaning of it.
…the team haven’t met the Scrum Product Owner for a week.
…the contents of a sprint demo comes as a surprise to the Scrum Product Owner.
…the team doesn’t know or understand the overall vision of what they’re working towards.
…you can’t release the software after every sprint.
...Scrum doesn't work.

9 comments:

  1. Great list - feels true, if you get what I mean.

    ReplyDelete
  2. Nice list, but I'm curious about this one:

    "...the team has as many stories in progress as it has team-members."

    What is wrong with that? What should the team members be doing instead if they shouldn't be working on a task?

    ReplyDelete
  3. I think it means that you are meant to collaborate on stories. Collaboration within the team is a key concept in scrum, so you don't want to spread out all your workers across completely different stories. Remember that one story usually covers work in a lot of different areas.

    ReplyDelete
  4. You're right, reallyjoel, this is what I meant. Collaboration is key. I definately want to see less stories in progress than there are team members.

    Thanks for your comments!

    ReplyDelete
  5. Great group of lists! This sure build up the right way of doing projects with the team.

    These lists sure is helpful. Thanks a lot for this post!

    ReplyDelete
  6. Please could you explain this one:

    … you commit both to a certain scope and to a certain date.

    In the sprint planning you plan to deliver stories by the end of the sprint. Surely that has both a defined scope and date?

    ReplyDelete
  7. No. The team doesnt commit to delivering the scope. The scope remains a flexible thing. The team commit to believing they can deliver it - not to actually delivering it. A big difference. Also, the team commit to delivering the scope in priority order, most important story first. Implying that lower priority stories may not be delivered in case there’s problems.

    Additionally, the time box is substantially smaller than in a traditional project.

    ReplyDelete