Retrospective activities for Gathering Data: “Learning Matrix”

One of the under-emphasized aspects of Scrum is the importance of the sprint retrospective. We all know about the stand-ups and the various planning meetings, but not all teams take the retrospective as seriously as they perhaps ought to. And it’s a bit of a shame, really. The retrospective is where the team can make tweaks and adjustments to a their process and really take ownership of it. Ownership leads to accountability, accountability leads to results.

If you’re looking for resources, I recommend “Agile Retrospectives” by Diana Larsen and Esther Derby – the exercise I’m about to describe comes straight from Larsen and Derby’s book. If you’re not looking to dive into a full-blown retrospective process (for some teams, it might seem a little bit too “New Age”), here’s a quick exercise you can try next time you hold a sprint retrospective: the “Learning Matrix”.

The Exercise:

The basic idea of the exercise is this…mark out a 2×2 grid (can be done on a whiteboard or some flip-chart paper) like this:

 

The four quadrants (going from top-left, clockwise) are:

• “Smiles” – things we liked
• “Frowns” – things we disliked
• “Bouquets” – appreciations/thank-yous
• “Light bulbs” – ideas/things to try

How it works:

1. For 5-10 minutes (depending on the length of the sprint), the members of the team identify items/issues/topics that fall into one of the 4 quadrants, recording each onto a Post-it note.
2. After the time period has finished, each team member presents his/her stickies to the team by posting them onto the grid and giving a brief description.
3. Close out the exercise by allowing some time for the team to discuss what they’ve discovered

What to do next:

Try to identify a few key items for the team to focus on for the next sprint. It’s probably important to emphasize that we’re talking about identifying “a few key items”. Depending on the size of the team and the length of sprints, realistically you can’t expect the team to be able to attempt too many of these “process experiments” and be able to focus on what they’re really here to do – deliver great software. The other reason I think it’s a good thing to limit the number of things that we’re tweaking in the process is that it’s just “bad science” – too many variables in play while you’re trying to verify your hypothesis.

Dot Vote!

One quick and easy exercise to try for prioritizing the items and deciding what the team wants to focus on is the “dot vote” (“Prioritize with Dots” in Agile Retrospectives). For this exercise, each team member is given a number of coloured sticky-dots. The exact number allocated depends on the number of items on the board and how many items you want to select, but pick a number, try it out…tweak it as you see fit. Team members place their sticky-dots on the items they see as being highest priority – they can put all their dots on a single sticky-note or spread them out – it’s entirely up to them. The items with the most votes are the ones the team will focus on next sprint. Ties can be resolved with a team discussion and/or revote.

Some observations/thoughts:

“Idea Generation” vs “Idea Evaluation”

I think one of the keys to effective brainstorming is to separate the “idea generation” process from the “idea evaluation” process. This can be tough – particularly as most of us in software development are “solution oriented” – but it pays off. This is why I think it’s important for the team to start the exercise with 5-10 minutes of “me time”, rather than launching straight into a free-for-all discussion. I also think it’s important to hold off on the idea evaluation process until each team member has had a chance to present his/her ideas

Facilitation skills

One of the skill-sets that I feel often goes under the radar but is hugely important, particularly for Agile teams is having good facilitation skills. To keep the retrospective on track, there is typically somebody (usually the Scrum Master) facilitating the meeting and keeping the team on-track and focussed on the task at hand. As the facilitator, it’s important to understand the impact your behaviour can have on the process and the team’s level of comfort and trust. For example, you might naturally be a take-charge, “I’ve got a solution for your problem” type of person, but as facilitator, you will need to take care to ensure that your “style” doesn’t negatively impact the team’s ability to have open and honest discussion in a high-trust environment. Another example where this may be an issue is if you’re in a position of “traditional” (read: “org-chart”) leadership – depending on your leadership style and/or how the team relates to you, you may or may not be best suited to the role of facilitator. Bottom line: if you don’t think you can do it (and not everybody can) – find somebody else who can fill that role.

Priorities

It should be common sense, but it’s worth repeating. If everything is top priority, then nothing is. Be really diligent about focusing on what really matters to your team.