Team Tasking in a Retrospective

I was recently facilitating a retrospective with a team that I was coaching on adopting Agile principles and practices. We did a Starfish retrospective and then cycled through action items for the things we had posted on the wall.

For some of the items, it was clear who should be responsible for completing the task. As the coach, I took a couple, the project manager another one or two, someone else took responsibility for a technical task, and so on.

But for a few action items, we assigned the owner as ‘the Team’. We had an observer in the room hoping to learn more about Agile and retrospectives. He asked me afterwards how can we assign something to the whole group? Won’t human nature mean that no one will do it? Don’t we need someone individually assigned to the task in order to make sure it will be done?

The question struck me as a typical response for a manager struggling with the move from command and control project management to a style more focused on team empowerment and self-organization. Or stated another way, if we want teams to be free from command and control, they will need to be able to self-organize to accomplish improvements in the way they work as a team.

For example, when a team complains in a retrospective about something like ‘not enough knowledge transfer,’ they are really complaining about themselves as a team. I mean that in a good way, in that they have identified something that they need to improve on together.

As such, it’s really tough to whittle that down to a simple action item that can be assigned to a single person. Further, assigning a task like ‘pair more’ to ‘improve knowledge transfer’ to a single person would potentially allow the rest of the team to absolve themselves of responsibility, as in, “I don’t need to worry about that because so-so is fixing it.” This is the flip side of the human nature argument; assigning a task to single person may mean that no one else feels the need to work on the solution. And we consign one person to run around trying to guilt the team into pairing.

So, teams I work with frequently mark these kind of items as owned by ‘the Team.’ Note that action items owned by a team can still be measured and should be actionable. For example, In the example of a ‘pair more’ action item, we can use pair stairs to measure our progress.

This approach allows one aspect of an Agile project manager’s role in a self-organizing team to come into focus. It’s not about finding the one team member who the PM can assign tasks too, and blame when the task is not completed on time. Rather it’s facilitating the team in finding measurable action items and pushing the team at the beginning of the next retrospective to evaluate their own performance during the sprint. Even better, in this example, encouragin the team to update the visible pair stairs information radiator as part of each stand up.

The goal of retrospectives is to help the team improve. Some things can only be improved on if we have the whole team’s effort. That means we need to facilitate group tasking.