Agile Retrospectives: Action Items

This is post #4 in a series dissecting agile retrospectives, see the introduction here

yin yang by cyberandy CC image from flickr

Action items are a pretty common and essential part of most retrospectives and are often considered the single most important part. This is, in my eyes, untrue, and this is where things will get just a bit philosophical for a moment.

Retrospectives are a great example of the essence of yin and yang, the precarious balance between light and dark, or in this case, thought and action.

Consider the earlier parts of a retrospective as focusing on thought, careful consideration and meditation on the current state of affairs. A life spent focused on the gaining of knowledge is a half life, for what is thought without action? On the other extreme we have movement, action and change, which can at first seem equally powerful and attractive, but after a closer look you see that action without thought is just as futile.

All the knowledge in the world may seem useful, but what use is all this knowledge if nothing changes as a result of it?

Equally, quick and decisive action seems fantastic, it can result in swift and tangible change… but what good is change, if nothing has actually improved?

What is truly required is a marriage of the two. You need the discipline and thought to meditate upon and understand your situation, and then combine that with swift action, so that you know that your actions are actually addressing the right problems.

No retrospective is complete without the act of retrospection (I don’t even know if that’s a real word, but you know what I mean) or without time dedicated to identifying actions in the light of the knowledge gleaned from this retrospection.

A general rule for all communication

One thing I tried to keep in mind when it came to action items has fast expanded to become a general rule for all communications that I think should always be at the forefront of our minds:

“Leave no room for ambiguity”

 Our lives would be so much simpler if everybody could follow this simple rule. If at the end of a retrospective a team cannot tell you who is responsible for an action item, when it is expected to be achieved, the problem the action is addressing and the change in state the action item is hoping to create then there is still too much ambiguity in the air.

What do I mean by the change in state that the action item is hoping to achieve? Another subject that I am passionate about is feedback. While I won’t get into it here, one of the components of effective feedback (in the case where the objective of the feedback to improve someone’s effectiveness) is to focus not on the negative present (i.e. whatever behaviour/observation you are discussing) but rather the positive future (the future state that you believe would result in a more effective performance).

This same thinking can be applied to the action items. If they are truly targeted at solving a problem identified by the team, then the team should know what problem a given action addresses and what change they action hopes to bring about.

Who – What – By when

The best way I know to meet these requirements when forming action items is to keep them SMART (http://en.wikipedia.org/wiki/SMART_criteria):

Specific

How ambiguous is your action? Is your team able to succinctly explain what the action entails?

Measurable

Ambiguity can rear its head in many ways. Imagine the team 2 weeks from now, if you were to ask them if they succeeded in completing the action, would they be able to give a definitive answer, or is the action worded in such a way that it’s open to opinion?

Achievable

Pretty self explanatory, but also make sure the entire action list is achievable. Each individual action may indeed by achievable in their own right, but put a hundred such actions together for a team of 10 people, and suddenly you have a problem. The best way to do this is review and prioritise all your actions at the end of the retro, make sure the team feels comfortable not only with each action, but also the list as a whole.

Relevant

This comes back to the first point in this post. Is your action addressing the right problem? Is it a problem worth investing the time to solve?

Time-boxed

Another change to remove ambiguity, when does the team want to complete this action by? What does end of the week mean? 11.59 on Sunday, or before everyone goes home for the day on Friday?

The only addition I would make to this is to add some clarity on the “who”. To put it quite simply: you are never allowed to volunteer anyone other than yourself for an action, ever. I explained earlier how the safety check provides the team with a visual guide to the heartbeat of the team at that moment, the aim of which is to create an awareness and understanding of the people around them, to instill some empathy into the team, so don’t go ruining all that good work by putting people on the spot and forcing actions on to them.

Reviewing the actions

Plan to leave a few minutes at the end of the retrospective to review the action items the team has come up with. Double check that everyone understands them and that each action is understandable and assigned to someone. Occasionally there can be some items that are assigned to “the team”, but as a general rule try to avoid this where possible. Remember, that being assigned an action item doesn’t mean that you are responsible for executing it, but rather you are just responsible for ensuring that it is executed (i.e. delegating to someone in the team and making sure the action is executed).

Also, at the start of the following retrospective, dedicate time at the start to review any previous actions. A retrospective is an opportunity to gain feedback and respond to it, and a very available source of feedback is how well the team has responded to previous actions, and how effective they have been.

The action cop

One pattern that has helped me in the past has been to assign an action cop. Now before I explain what an action cop is, it is important to understand that this is not something that I advocate that every team should do. In fact I recommend that you do not have an action cop, and only introduce one if the need ever arises (which, fingers crossed, won’t be that often :) )

The action cop is somebody who takes it upon themselves to chase up the rest of the team and make sure people are keeping on top of actions that they have signed up to. It is not the responsibility of the action cop to complete any of the actions, but just to encourage and remind the others of the responsibilities they have accepted.

About the Author: akash

2 Comments

  1. Pingback: Agile Retrospectives Part 1: Useful Tool or Empty Ceremony? | blog

  2. Pingback: Can’t keep up? A simple guide to give feedback. | MagmaLabs Techical Blog

Leave a Reply

Your email address will not be published. Required fields are marked *