Re: What to do with stalled tasks
- Thank you both Ryan and Adrian, your feedback were definitely helpful
you have given me some ideas to try! As Tobias Mayer taught in a
class of his: Scrum doesn't fix problems, but it defintely surfaces
problems so we can deal with them.
- mars -
--- In firstname.lastname@example.org, "ryanpcooper"
> For the first type of stalled task, I would recommend having someone
> else continue the work. This is also an opportunity for some
> introspection. You should ask questions like:
> - Are you pairing enough? If so, it should be pretty easy to
> without the missing developer. If you don't want to do pairhave
> programming, you should develop other ways of ensuring that your bus
> number is > 1.
> - Are you stories/tasks too big? If they are small (< 1 day), you
> more options. Generally this makes it easier for someone else to gettask
> up to speed on the task quickly, or barring that, just start the
> over from scratch.turnaround
> - Why are you losing resources mid-sprint? Is there a way to prevent
> this sort of fire-fighting in the future, or allow for it in your
> iteration planning?
> For the second type of stalled task, you really need an estimate of
> turn-around time from the external dependency in order to make the
> decision. Again, this should prompt questions:
> - Can you reduce dependencies on external groups? (In other words,
> become more cross-functional)
> - Can you work more closely with external groups to reduce
> - Can you identify tasks with external dependencies in iteration
> planning, so you can resolve the dependencies as early in the
> iteration as possible? (If this is possible, I would recommend
> such tasks in "To Do" until external dependencies have beenresolved.)
> Last but not least, keep stalled tasks highly visible. If you have a
> task board, fluorescent stickies are useful for this. Have the
> owner/tracker of the tasks bring them up in daily scrum. It's easy
> "get used to" blocked tasks and slip into the habit of not attacking
> them as aggressively as you should.
> Hope that helps!
> Ryan Cooper