3

I understand that Agile team should be self organized and self driven,

but is there a provision that I can have someone who will allot tasks to developers and ensure that all user stories will be completed on time??

For example if there are two persons in an agile team who are not self motivated to take up tasks and they will work only when task is assigned to them with a deadline, how can we deal this in Agile?

The problem I face is that no one is fixing the deadlines for the tasks and the team is under delivering for the last two sprints. It will be better if we can have someone who can fix deadlines. IS there a provision for this in Agile

Improve this question
4
  • What came out during your retrospective? Did the team have any ideas for how to address these problems? It sounds like there are probably multiple root causes...
    – Michael
    Commented May 21, 2014 at 14:29
  • Team said that under delivery is happening since deadline is not assigned for user stories
    – Vignesh Subramanian
    Commented May 22, 2014 at 5:39
  • Ok... so what was the action item your team decided on to help resolve this problem? To me it sounds like you need to do some more digging. My point is, why are you asking strangers on Programmers.se when you should be asking your team? There is no single right answer to this question, though some ideas will work better or worse than others. But if the context isn't exactly the same then your results will vary. Agile is as much about the journey as it is about the destination.
    – Michael
    Commented May 22, 2014 at 14:27
  • Even the team feels that it will be better if we have deadlines for every userstory!! But i dont think alloting user stories to people and setting deadlines when sprint starts is a good practice in agile i think we are so used to catching up with the deadlines
    – Vignesh Subramanian
    Commented May 23, 2014 at 4:06

5 Answers 5

Reset to default
3

Address this issue with the following techniques:

  • Daily scrum to review progress. If people aren't making progress at a reasonable pace it will become more obvious to everyone day by day.

  • If a problem is suspected the product manager or line manager can review recent stories and their points and see if there is an issue that persists over time.

  • Continual retrospectives to uncover the deeper issue and team dynamics that are impeding progress. There are frequently hidden issue which slow progress.

  • Put a low performing member on review and if they can't deliver what is consider to be the minimum, after several reviews let them go. Never a pleasant option but it should be considered an option in extreme cases.

Improve this answer
1

One of the principles of an agile team is to pull tasks, not assign them!

Sorry, but IMHO you do not have an agile team. You may throw the unwilling ones out of the team or drop agile.

The last try could be to let them decide: want you like to pull a task you that fits best to you or should I assign you the worst task I can find?

If that does not work, it's over.

Improve this answer
1
  • Downvoting, as no-one just 'has' an agile team, you have to start somewhere.
    – SpoonerNZ
    Commented Jun 2, 2014 at 15:51
1

Adopting Agile is supposed to be a team decision. It relies heavily on team members to make best-effort estimates about the scope/effort for a task. If you are having to force-assign tasks to developers in order to get things done, it kind of defeats the spirit of Agile development.

Improve this answer
2
  • I agree, but this doesn't help the initial poster's situation at all.
    – SpoonerNZ
    Commented Jun 2, 2014 at 15:57
  • @SpoonerNZ the point of my answer is that the team's workflow is broken. It is better to address the root cause rather than battle the symptoms. I like your answer as a general how-to on Scrum, but it does not answer the specific question asked.
    – metacubed
    Commented Jun 3, 2014 at 17:18
1

To answer your question directly, you can with a scrum master or senior developer dictating this, but shouldn't.

It sounds like you are at the start of an agile journey. It is the Scrum Master's job to enforce the rules of Scrum, which is exactly what you need at this stage. Over time the team will get better at discussing and distributing tasks, but will need some encouragement to start with.

As a scrum master in this situation I would:

  1. Ensure stories are split into tasks that are smaller than half a days work for one person, and estimated in hours at sprint planning. This means everyone can see progression (or none) quickly and clearly on a daily basis.

  2. Ensure that at the stand up every team member commits to deliver an appropriate amount of work. If they don't, ask them why they won't commit to more, and don't let them avoid it unless there is a valid reason. This is the crux of the issue. With a team I worked with in the past we even marked our daily committed tasks with a dot, so we could see if we under delivered the next day.

  3. At the stand-up the next day if people haven't met their commitment, get them to update the estimate to how long they think is remaining. Ask why they didn't get it completed and offer help from others, but make sure to do this with concern, not anger. Do not pass their tasks off to other people, but offer them all the assistance they need from other developers that could help.

  4. Use the burn-down chart as a discussion point at the stand-up and ask the team how we (not they) can get the top priority story (or the sprint goal) done, but do not allocate work to them yourself. You shouldn't really get hugely behind if the estimates are ok and you are following the steps above, but if you do it is a talking point for the retrospective. Is it distractions? Was it too much work in the sprint? Was it risky work you didn't think about enough? Absence? Learn from it.

I don't think you should allocate tasks any more formally than this, but at the early stages it is important to track them. Whether you link this to people (names on tasks) is up to you, but I prefer not to as it encourages team input into a task and a less individual mindset, and also reduces the feeling of being monitored as a developer.

Improve this answer
0

There should be someone who educates and helps the programmers on the team to understand and adhere to the team's agile practices and then holds them accountable for it.

This is the only way to have a true self sustaining, self-managing agile team.

Don't address the symptom, address the problem instead.

Improve this answer
3
  • "There should be someone who educates and helps the programmers on the team to understand and adhere to the team's agile practices": What to do if they do not want to adhere? You just invite them to leave the company? Would you do this even with experienced and competent people?
    – Giorgio
    Commented May 18, 2014 at 13:15
  • The question said: "For example if there are two persons in an agile team who are not self motivated to take up tasks and they will work only when task is assigned to them with a deadline, how can we deal this in Agile?" That does not sound competent to me. And define experienced?
    – MickJ
    Commented May 19, 2014 at 17:35
  • If the lack of motivation comes from a bad attitude or lack of experience, then the question is founded. If the lack of motivation is due to problems with agile (an experienced developer may have used other methodologies successfully and not be willing to switch), then IMO coaching is not going to solve the problem. Def. experienced: e.g. someone who has worked as a developer for twenty years in different projects, using different technologies and development processes.
    – Giorgio
    Commented May 19, 2014 at 18:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.