by Jeremy Jarell

Meet the “The What/So What/Now What” Retrospective Format

The “What/So What/Now What” retrospective format is a variation on the classic “What’s Working/What’s Not Working/What to Try Next” theme that many Scrum teams are already familiar with.

But rather than forcing the team to place each item into one of three buckets, this format treats each bucket as a state that the item must flow through to resolution. Not only does this avoid the headache of trying to decide where some items “fit”, but it also makes retrospective items feel more like story items moving across a Scrum board which can make the process feel more natural as it guides the team towards a resolution.

What can you expect to get out of this exercise?

As an outcome of this exercise, you should expect to see the team deal with action items that are more closely tied to issues that arose in the sprint. This is because each action item, which appears in the “Now What” column, will be derived directly from a retrospective item.

You should also expect this format to excel at bringing to light small problems that would otherwise go unnoticed. These small points of friction that aren’t typically large enough to remember during a classic retrospective are more easily captured and analyzed using this format.

When would you use this exercise?

This format is a bit more advanced than the classic retrospective format so wait to introduce it until the team has had several successful retrospectives using the “What’s Working/What’s Not/What to Try Next” format. This way you can be sure that the team is getting comfortable with the idea of introspection and addressing items before switching up the underlying format.

There are also a few symptoms that can tell you if you’re ready for this new format. For example, you may notice that the team is struggling to remember items during the retrospective even though you’ve witnessed many small pain points during the sprint. This can happen because the team has already addressed the larger and more obvious items and has simply learned to live with the smaller items.

Another symptom may be that many of the items the team is bringing up have started to resemble “observations” rather than true pain points. These are items that don’t fit neatly into a “What’s Working” or “What’s Not Working” bucket but still need to be discussed.

If you notice that your team is starting to struggle to fit items into one of these buckets, then this may be a sign that they’ve outgrown the classic format.

How to do it?

Completing this retrospective consists of a few different parts, some of which consist of gathering information while others consist of analyzing that information.

Gather the Information

The goal of this retrospective is to discuss observations that are causing friction for the team but are too small to be called out during a classic retrospective. To this end, the Retrospective Wall is a great tool for gathering this information.

Retrospective Wall

To create a Retrospective Wall first carve off a section of wall or whiteboard in the team space and place sticky notes and markers nearby. Then, each time a team member notices something that they want to discuss during the retrospective encourage them to write the observation down on a sticky note and add it to the wall.

These observations may be things they’ve noticed that are creating friction, something that doesn’t seem to working as well as it could be, or even a good thing that they don’t want to forget to celebrate. Whatever the reason, adding it to the Retrospective Wall keeps the team from forgetting about it.

If you’ve encouraged your team to place items on the wall as they notice them—and even added a few yourself to lead by example—by the time your next retrospective rolls around you should have a great selection of topics to kick things off.

Dot Voting

<If you find you have too many items to get through in a single retrospective, try Dot Voting to narrow down the topics to the ones your team is most concerned with.>

Analyze it

Once you’ve selected the items that you want to talk about move them to the “What” column. Then, starting with the top item, begin discussing each one. If possible, provide examples from the most recent sprint to help jog the team’s memory and to provide context.

Next, move the item to the “So What” column. Here you can discuss the effect that the item had on the sprint and the team. For example, what happened as a result of the issue…or what didn’t. And, most importantly, what did this mean to the team?

Finally, move the item to the “Now What’ column to brainstorm things that can be done about it. This may include catching the issue before it occurs or just responding to it if it’s outside of the team’s control

Note that you’re not committing to action items at this point—that will come later—so feel free to brainstorm as many ways possible to handle the issue. Also know that some items that are purely observational won’t have “Now What’s”, but that’s ok. If those items don’t fit in this column don’t force them…just leave them in the “So What” column.

Creating Action Items

By this point in the retrospective you should have a pretty good feel for which items are the most important. Hopefully, you’ll also have a good starting point for action items for each high priority item.

Although you may have uncovered a wealth of issues, resist the urge to fix them all. Instead, choose no more than 1 to 2 action items from the “Now What” column to address during the next sprint. This can ensure that your team can truly focus on those items and improve your chances of resolving them.

Some items that you want to tackle in the “Now What” column may just leap to the forefront. But, if you have a lot of candidates from this column with no clear winner, feel free to use another round of Dot Voting to help your team zero in on what matters the most to them.

To improve your odds of fixing the underlying issue make sure that your action items are specific. Don’t accept simply “get better at x” and instead demand specific steps of how the team will try to improve the issue. If possible, even ask the team to define metrics that will help them understand when they’ve met their goal. These may be clear metrics that actually measure an improvement or simply an observable end result that the team should see. Either way, defining the end state should help make it clear to the team how they’ll get there.

What to Do with Survivors

Once your team gets comfortable with the Retrospective Wall you’ll find that you’ll often have more discussion items than you can get to during a single retrospective session. If you’re lucky enough to encounter this situation then here are some ideas to help you handle it.

Timebox the Retrospective

Don’t let the retrospective run indefinitely to address all items and don’t try to fit all items in a single session. Creating scarcity around the number of issues that you’ll be able to discuss forces the team to prioritize those issues that are most important to them. In addition, if you let the session run indefinitely then you’ll likely find that the quality of conversation around the later items will be low and unproductive.

Cull the Wall

Don’t leave items that don’t make that retrospective session on the wall indefinitely. This can create clutter and too many items already on the wall will discourage the team from adding new ones. Also, many of those items will grow stale and become no longer relevant by the time they’re finally brought up. Don’t worry, if any of the items you have culled are truly important then they’ll be brought up again.

Promoting the Survivors

 

In the past I’ve sometimes implemented a “survivor policy” with teams who are new to this format. This means that items that don’t make their initial retrospective can “survive” on the wall until the next retrospective. If you decide to do this, make sure that you visually call these items out either by switching the color of retrospective sticky notes from one sprint to the next or by moving them to a special section of the Retrospective Wall.

Initially, this can help ease fears that simply dropping these items will result in problems never being fixed. However, after the team has had the opportunity to see items survive from generation to generation they tend to notice that those same survivors are rarely chosen for discussion in the next retrospective. This is because the surviving items have either become irrelevant or are simply not as important as those items that have been added since. If you find yourself in this situation then this can be a good opportunity to suggest that these items aren’t worth keeping and help guide the team to the answer of dropping the items after each session.

 

Wrapping Up

Combining a Retrospective Wall with the “What/So What/Now What” format is a great next step for teams who are comfortable with the classic format, but have addressed many of their major issues and are starting to run dry on topics.

 Before your retrospective becomes too stale this can be a great tool to freshen it up and start to address some of the issues that are lurking just beneath the surface.

If you’d like to more about my thoughts on retrospectives, or agile in general, you can find me at my website www.jeremyjarrell.com, or on Twitter at @jeremyjarrell.

About Jeremy

Jeremy Jarrell is an agile coach an author who helps teams get better at doing what they love. He is heavily involved in the technology community, both as a highly rated speaker as well as a syndicated author whose articles and videos have appeared in numerous respected industry publications.

Picture credits to: Jeremy Jarell and Agile Portugal 

---

In case you are interested in Agile Retrospectives I am at the moment preparing a 10 Days FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us on the format of Guest Blogging please contact us: info@oikosofy.com.

by Stefano Porro

The mutant Star Fish is my personal customization of the famous retrospective exercise called Star Fish. It adds to the typical three questions of the original exercise: What Went Well? What did not go so well? What should be improved? Another question focused on the team: “Why is important to me work in this team?”

What you can expect to get out of this exercise?

This exercise helps, like the original one, to identify problems and opportunities for the team using a simple visualization method. And moreover it permits you to identify the individual needs of the team members. While the original exercise focusses (correctly) on the team, this customization helps the team to also understand the individual needs.

Typically, we have five sections

1. Stop: In this section, team will bring the activities that don’t bring any value – waste

2. Less: Here team will bring the activities needed to be reduced because they require a high effort but don’t bring as much value as they expect

3. Keep: Activities that the team wants to keep and already performed. These are activities where effort and value produced are balanced

4. More: Activities not so often performed but very valuable. The team could decide to adopt these activities more often to boost their performance

5. Start: new activities decided by the team to bring more value. We can say these activities are experiments.

Now we add another section and we can call it as we want: WII-FM (What Is In For Me), Coolness, Amazing. Name this section with a word (or a little sentence) that can help the team members to understand that this section is made to gather their individual sentiments and needs. Because we are working as a team, and a team is made by individuals!

When you would use this exercise?

I suggest to use this exercise with teams that are new to Scrum (or Agile, generally). When people are new to Scrum, they are looking for their motivation. Focusing the exercise to both team performance and individual needs can help them to create a climate of “self-motivation”. They will understand that we are working as a team but we will never forget the single persons in the team. When a team starts with Scrum, team members are looking for a motivation to start this journey. In this way we ask them for it explicitly.

How to do it?

First of all draw a picture like this:

 

I’m sure you all know how to use this schema (except the new section).

Anyway, let’s see quickly how to use this retrospective exercise.
Ask the team to use about three minutes to gather, individually, ideas for the STOP section (they will use post-its to dump on the flip-chart). After that, use 10 minutes to make the members read loudly from their post-its and to align all team members, discussing about those ideas.

Repeat the same for the LESS, KEEP and MORE sections.

For the START section ask your team to vote for a single subject. In this way you can make them focused on a single topic, probably the most important to them. So study a strategy with the team so this idea will be well implemented. The strategy is helpful because to know if an implementation is successful, you need success criteria.

Luis Gonçalves says that the order in which you put the sections in the flip-chart is important (as important as the order in which you ask for them) and I totally agree. In addition, I put START and WII-FM in the two bigger sections (at least for an optical illusion) and I underline the words. In this way the team will concentrate more on the positive things. A little bit of psychology.

So, we have gone trough the START and we proceed almost to the closure of the retrospective.

At this point the team would have talked about the team process: now it’s the moment to talk about the individual needs and performance. Ask the team members to write something on post-its in five minutes (give them a little bit more time) and after that ask who will be the first to present his/her post-its.

Team members have to read loudly from their post-its and then explain their meaning briefly. After everyone reads his or her ideas, the Scrum Master will re-analyze all the post-its to understand if all things are clear. The action from these post-its its won’t be implemented for the next sprints, but they’ll give the team the possibility to explain what they are looking for to know about Scrum and the possibility of the Scrum Master to adapt his work in a twofold manner: team performance and individual performance. For example the Scrum Master could identify people who are having problems in the company so he or she can act quickly to avoid transitions.

This exercise, moreover, helps not to lose the focus on WHY we are using Scrum, and this is a very important thing to remember. Developers wouldn´t be so impressed by numerical motivations (ROI, etc.) but you, as a Scrum Master, must find the right key to motivate them. And in this way they’ll help you to discover the key to their success.

About Stefano 

Stefano is from Turin, Italy. He has worked in IT projects since 2001 and he feels lucky because he does what he loves. He learned about Scrum in 2007 when the company where he worked decided to adopt Scrum. For the first two years he was part of a Scrum team. And he was fascinated about the role of the Scrum Master because he always loved to help team members. For him, becoming a Scrum Master, was a natural evolution.

You can find Stefano Porro on Twitter @StefanoBowen and connect with him on Linkedin.If you prefer email, feel free to contact Stefano at stefano.porro81@gmail.com.

You can follow Stefano’s blog http://agilekarma.com/author/stefano-porro/ to know more about his work and his ideas.

Picture credits to: Stefano Porro and Bill Sutton

---

In case you are interested in Agile Retrospectives I am at the moment preparing a 10 DAYS FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us on the format of Guest Blogging please contact us: info@oikosofy.com.