Retrospective Exercise: Vital Few Actions

Reading Time: 4 minutes

RetroValue ImproveThe aim of an agile retrospective is to define actions for the next iteration that will improve the way of working and help teams to deliver more value to their customers. The vital few actions retrospective exercise can be used within agile frameworks like Scrum, SAFe, XP or Kanban to have teams agree upon the vital few improvement actions that they will do. By reducing the amount of actions and improving their quality, teams will get feasible and valuable retrospective actions which help them to improve themselves in a sustainable way.

In agile shorter iterations are usually better, as they speed up the feedback cycle and enable teams to learn and improve quickly. In short iterations there is limited room for change. You don’t want to have many actions, preferably only 1 or 2. More is less, if you have too many actions then you will get less done. Teams should focus on the vital few actions that they can do in the next iteration.

Too many actions

The purpose of this retrospective exercise is to destroy those retrospective actions that would be delivering lower value, so that only the essential ones remain that would result in changes that will stick.

You would do this exercise if you have too many improvement actions. For instance when there are many actions coming out of an exercise in a team retrospective. In that case you would do this exercise before you finish the retrospective meeting.

Most retrospective meetings start by checking the progress on the retrospective actions. It can be the case that there are many improvement actions from previous retrospectives that are still open. If the teams appears to be insufficiently able to do their actions then my suggestion is to do this vital few actions exercise. Don’t spend time on defining new actions when there are open actions that can be done.

This exercise can be combined with other retrospective exercises from the book Getting Value out of Agile Retrospectives like the one-word retrospective, strengths-based retrospective or project collaboration retrospective. It can also be done as a stand-alone exercise in the retrospective meeting.

Destroying actions

There are different techniques that can be used to destroy retrospective actions to help teams to focus on the vital few actions:

Dot voting: Every team member gets a limited number of dots which they can use to vote on the improvement action. They can cast their vote by putting dots on the the action. Distributed teams can use Google docs or sheets or online collaborations tools to do the voting. Votes should be given to actions that provide the most value when done in the next iteration, assuming that those actions are feasible. Team members are encouraged to give multiple votes to an action, since that stimulates them to focus.

Remove the bottleneck (lean): The team is asked to look at the main flow in the iteration. They start from delivery and go back until the beginning to find the biggest bottleneck in their product development life-cycle. Next they have to pick one or more actions that help to reduce this bottleneck, and to throw away all other actions.

Devil’s and Angel’s advocate: The team starts by playing the role of the devil’s advocate. They pick one action which they think has the least value for the team by together bringing up reasons why it wouldn’t work or doesn’t solve their problems. When only a few ideas are left they change their role to the angel’s advocate to bring up ideas why these actions *would* work. Finally they would pick only 1 or 2 actions that they think would give the most value in the next iteration.

Kill actions: Team members are asked to destroy actions that they think have the least value. Initially every team member is allowed to give a veto against 1 action. I usually suggest that veto’s don’t have to be motivated, since by voting against an action a team members are stating that they do not support them and will not contribute to get the action done. Team members are allowed to give veto’s to the same action, this will help to identify actions for which there is no commitment in the team. When there are still too many actions left, another round is done until the vital few actions are left.

It helps to physically destroy actions that are removed,  for instance by throwing away the sticky note, wiping out the action from the white board or deleting the action from an electronic action list. This ensures that team members will focus on the remaining actions as those are the only ones which are still visible. If team members are unsure if they can do without the action then you can tell them that if it was a valuable action then it will pop up in a future retrospective.

You can refine the remaining vital few actions using results from the techniques described above. E,g. by discussing why people voted on an action, exploring the bottleneck or using feedback from the Angels advocates. Alternatively you can do a perfection game to improve an action.

Teams travel their own agile journey

One of the benefits of retrospectives is that teams are empowered to taken action. They can decide which actions they will do. Agile teams are responsible for their own improvement journey. By self-assessing how agile they are and designing valuable agile retrospectives teams can become agile and lean.

Agile iterations are short, so teams can only do few actions. Having a big list of actions doesn’t help, it is better for teams to focus and to assure that the vital few actions get done!

Are you interested to spice up your retrospectives using new exercises?

Here’s a list of exercises that you can do to get business value out of doing retrospectives. You can attend one of my workshops on Valuable Agile Retrospectives to learn how to adopt agile retrospectives and become agile in an agile way. Or download one of my books with retrospective exercises. Feel free to contact me if you want to discuss the possibilities.

(Visited 5,665 times, 1 visits today)

About Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.
Tagged , , , , , , , , , . Bookmark the permalink.

5 Responses to Retrospective Exercise: Vital Few Actions

  1. Rolf says:

    Ben,

    very helpful hint! For people who don’t like the “killing” / “destroying” metaphors, Fabian Schiller’s “priority race” might be a more positive decision-making activity (the best actions will win): http://itscertainlyuncertain.blogspot.de/2012/04/priority-race-game-for-effective.html

    There’s also the inverse problem: people absolutely agree something “must” be done, but there’s no option that looks like a clear winner. When resistance is rising, systemic consensing might be a helpful decision making technique: http://systemicconsensus.blogspot.de/2012/11/white-paper-systemic-consensing-first.html

    Cheers,
    Rolf

  2. Rolf says:

    Ben, I picked the wrong link to systemic consensing, can you please replace it by this one? http://systemicconsensus.blogspot.de/2012/11/white-paper-systemic-consensing-first.html

  3. BenLinders says:

    Thanks Rolf for your responses. I like the priority race, on the surface it looks similar to dot voting but the different way of visualizing the options and having them compete makes it valuable.

    Systematic consensing can also be useful. The zero option can help to come to a complete/unanimous team decision, but there might also be cases where not everybody has to buy in and agree.

    One other technique that I use in for instance CMMI assessments is thumb voting. Thump up means you agree, down you disagree, and sideways that you will go with what the majority of the group decides.

    Great contributions Rolf, again thanks!

    (link has been corrected 🙂 )

  4. Bill Wilson says:

    Hi Ben, I like this article very much. Not being in a software development/engineering environment, I don’t have any practical experience with Agile methods and techniques, and the only knowledge I have is from reading various blogs over the years. I’ve had kind of a minor academic interest in the subject, but this post has made me realize that Agile could make a leap from software engineering to other engineering fields. My particular industry (nuclear power) employs large numbers of engineers working on system performance, equipment reliability, components and engineering programs, design, projects … and every one of these groups at my company is looking for ways to achieve excellence. Agile could be the key. Thanks for opening my eyes to this!

Leave a Reply

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

  • Ben Linders – Independent Consultant Agile, Lean, Quality, and Continuous Improvement

    Ben Linders
    Ik help organisaties om effectiever software te ontwikkelen. Neem contact op voor mijn diensten.

    I help organizations to effectively develop software. Contact me to hear about my services.