Sprint retrospective irrespective

Unfortunately, when a team is under pressure, the important sprint retrospective is often the first to get bumped to when life is a bit more relaxed and under control. Even I have to admit that in my earlier days as a ScrumMaster I was guilty of skipping the retrospective on occasion. The irony is that this session is most valuable when the pressure is on and / or when things aren’t running as expected. As such, discipline needs to be maintained and the sprint retrospective should always remain a consistent event at the end of each sprint, irrespective of the noise surrounding it.

Reinforce Scrum’s values

It is important to remain cognizant of Scrum’s core values: Commitment, Courage, Focus, Openness, and Respect. Nowhere should these values be applied more rigorously than in the sprint retrospective. Without an atmosphere of Openness you will never get to the heart of the issues; without Courage, the team won’t be willing to confront problems head on; without Respect the team won’t present criticism in a constructive fashion and without Focus and Commitment, the team won’t care to resolve the issues. Everyone should keep these values in mind at all times.

What if we’re running one-week sprints?

I’ve been asked before by teams who are running in very short, one-week sprints whether they should perhaps only run a retrospective every two or three sprints (as opposed to on a weekly basis). Personally, I feel that one-week sprints are too short, however, if there is an insistence on shorter sprints, I don’t recommend skipping the retrospective sessions. Instead, simply run shorter retrospectives but make sure that they still occur every sprint.

Location, location, location

To create an atmosphere of openness, the location where you hold your sprint retrospective is important. A large, stuffy boardroom with a long, impersonal mahogany table isn’t conducive to creating the atmosphere you need and may end up turning your retrospective into more of an inquisition. Instead, I recommend a relaxed setting such as a coffee shop, a breakout room (if you have one) or even the kitchen area, which, due to its proximity to snacks and coffee can be a great choice!

Getting set

Ideally, you want your team arriving for the retrospective session prepared with a list of issues and suggestions so that you can get straight into it. To help facilitate this preparation, I recommend that you send an email prior to the session outlining potential areas to focus on. An example of key areas include.

• Communication
• Processes
• Scope
• Quality
• Environment
• Skills

Let’s now explore a sample of some common improvement actions that might be triggered within each of these areas:

Communication

• Fixing disjointed communication between the product owner and development team (especially if the product owner isn’t seated among the group).
• Removing disruptive and unnecessary communication between external stakeholders and the development team.
• Resolving dysfunctional communication within the team, typically due to an over-reliance on written documentation (and email) rather than face-to-face discussion.

Processes

• Upgrading software, hardware and network connectivity
• Confirming that the Scrum processes are well understood and clearly defined.
• Maintaining engineering standards relating to code quality, source control, and deployment processes.

Scope

• Making certain that significant changes to scope do not occur mid-sprint.
• Maintaining formatting consistency across all user story descriptions and acceptance criteria.
• Ensuring that the sprint planning scope is not ill-defined or too vague.

Quality

• Clearly defining and maintaining a consistent definition of done.
• Evolving test processes to enable more mature test automation.
• Ensuring that programmers are assuming ownership for the testing of their code and not leaving it totally up to the testers and/or product owner.

Environment

• Maintaining a collaborative environment that isn’t too noisy and disruptive.
• Providing ample air-conditioning or heating.
• Making sure that there are appropriate amenities (one microwave isn’t going to cut it for 50 people!).
• Ensuring enough white-board space and other collaborative tools.

Skills

• Providing adequate training when new technologies are required.
• Conducting induction training for any new team members.
• Obtaining relevant specialist consulting when required.

Output of the retrospective

When the juices start flowing, it isn’t hard to generate a long laundry list of issues to tackle. The trick is to not fall into the trap of getting overly keen and declaring that all issues will be resolved by the next retrospective! Instead, ensure that all improvement suggestions are documented, but aim to tackle no more than a few issues – perhaps one biggie and a couple of smaller ones. Nothing loses credibility faster than over-promising and under-delivering; so instead, do the opposite! Finally, take these agreed upon actions, write them up on a large sheet of paper and place it near the task board as a constant reminder for the team. Please use discretion with this ‘public display of action’ as writing, ‘Lock disruptive project sponsor in cage’ and sticking it on the wall might not do much for your future job progression!

Format of the retrospective

To keep things fresh, vary the format of the sprint retrospectives throughout the project. There are numerous approaches that can be utilized, however for the sake of brevity, I will focus on two of my favorites, nicknamed ‘Circles’ and ‘Bubbles’, respectively.

Circles

This first technique employs an affinity mapping variation. For those unfamiliar with affinity mapping, it is essentially a graphical tool designed to amalgamate loose, unstructured ideas into collective groups.

Before describing the actual technique, let’s identify the classic four questions often asked in Scrum retrospectives:

• What did we do well?
• What can we do better?
• What should we try next time?
• What issues do we need to escalate?

It is actually a preference of mine to simplify things even further by asking only two questions:

• What can we improve?
• What are we doing well?

Getting back to the actual technique, you will firstly need to draw a horizontal scale on the whiteboard. On the very left write the label Needs Improvement, in the middle, jot down the more neutral OK label, and the right is denoted with the more encouraging Going Well label.

Now in keeping with the Scrum sticky note tradition, hand each team member a bunch of sticky notes and ask them to start writing their thoughts / issues on them. Once complete, direct the team to start sticking the notes on the wall, wherever along the scale they feel each note fits best. Make sure that you time-box this step to avoid the dreaded ‘analysis paralysis’.

Once everyone has placed their notes on the board, it is time to align similar items to form groups. Next, use a nice thick marker (non-permanent or your issues will remain forever) to draw circles around the notes that reflect similar thoughts that are grouped closely together while ignoring the outliers for now. It will be rare for you not to identify a few common themes.

Once the groupings have been completed, it is wise to briefly discuss any outliers with the team as more often than not, these will be due to misinterpretation or lack of understanding rather than due to conflicting opinions.

Finally, as a team, address the circled groups in priority order (items further to the left will typically be of higher priority) and identify some actions to be followed up on in the forthcoming sprint to help address the improvement areas.

I like this approach for a few reasons:

• It avoids putting anyone on the spot (or in the spotlight).
• There is plenty of physical motion which keeps the team alert and active.
• It is tactile and visual which always makes life a bit more interesting.
• The team is able to immediately gauge the collective priorities by viewing the sticky note groupings on the wall.

Bubbles

This next option is definitely my preferred approach for the first few retrospectives that you run with a freshly formed Scrum team (when the members haven’t worked together before).

‘Bubbles’ works really well because it promotes immediate collaboration, helps everyone get to know one another in a non-contrived fashion and again, doesn’t put anyone on the spot.

So, how does it work? Firstly, you need to come to the session prepared with paper and pen for everyone in the group.

Now, this technique works best with an even number of team members however you can easily make it work with uneven numbers. For demonstration purposes let’s say that you have a team of eight.

Step 1 requires each person to individually document on their sheet of paper the three most urgent and important issues that they feel should be focused on in the upcoming sprint. I recommend a five-minute time-box for this step.

Next, get the individuals to pair up with a buddy sitting next to them (here you will obviously have four pairs but there is no problem having groups of three instead if you have an uneven number). Again, during a five-minute time-box, ask the pairs to decide, based on their combined individual lists, which three items should take priority overall.

You can probably see where this is heading by now, but in case you haven’t guessed, the next step is to join two pairs together so that you now have two groups of four. Once again, time-box this step, although you may offer up a little extra time as you now have groups of four debating the merits of their lists to determine the top three.

With this approach, the most urgent and important issues ‘bubble’ up to the surface.

The penultimate step is to form a single group of eight to determine which three issues bubble right to ‘the top of the top’. By this stage you should find that everyone’s inhibitions have been dropped and that a healthy, open debate can now ensue, following which you will have determined what should be focused on next sprint.

Don’t disregard all of the other valid suggestions that were uncovered in the earlier rounds of ‘Bubbles’. Instead, document them so that when you return for the subsequent retrospective, there is a healthy starting point to help get the ball rolling. Suggestions that were previously lower on the list may at a later stage become the top priority focus points.

Finally, the team can rinse and repeat the same ‘Bubbles’ activity above to identify and acknowledge the successful behaviors and processes that the team wishes to explicitly keep moving into the next sprint.

Seasoned pros

When you are working with a truly battle-hardened group of Scrum aficionados, my advice is to forget about any formalized structure for your retrospective – it will just appear contrived. When a team is comfortable in its own skin you will have absolutely no trouble getting the collective group to speak up and express their concern / joy with the status quo. Instead, simply go out for lunch or coffee with a pad and pen and shoot the breeze.

Retrospective attendees

The broader Scrum community seems to be a little divided regarding the question of whether the product owner should attend the sprint retrospective. Personally I believe that they absolutely should attend as he / she forms an integral part of the Scrum team. That being said, before your team becomes a well-oiled Scrum machine, there may be a few communication break-downs especially between the developers and the product owner. As such, if you observe any tension, I recommend that in addition to the ‘official’ retrospective session, the ScrumMaster should also conduct an informal one separately with the product owner.

Keep it fresh

Inspection and adaptation is the name of the game and the sprint retrospective is vital to ensure that your team is constantly improving. There are numerous techniques that can be employed for this session so feel free to vary the techniques to keep life interesting and fresh. Derby and Larson’s book, Agile Retrospectives offers a whole host of different options that you can employ.

Most importantly, whatever happens, don’t skip your retrospectives, irrespective of what is going on in the background!

 

If you liked this article, you can:
Subscribe to this RSS feed!

Find out more about Sprint Retrospectives by taking one of our CSM training courses.