how can we have a person to allot and track tasks in agile development

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.