Summary

Motley:  Reflection is for mirrors. We just finished a sprint. Why open up old wounds?

Maven: At the end of a sprint, do a demo for stakeholders, customers, and the team. Do a retrospective to reflect on what went well and what requires improvement. Continually improve the team from one sprint to the next.

______________________________

[Context: In a continuing conversation about Scrum, Maven is about to enlighten Motley on the most effective ways to wrap up a sprint, or short iteration]

Motley: At the end of the sprint, we followed the Scrum process. Everyone did a quick one minute summary of the work they accomplished during the sprint. We then chatted for 5 minutes on how things went. That's it. Don't tell me there's more. This is a lightweight process, right?

Maven: I guess "lightweight" means different things to different people. There are some best practices for the demo and retrospective. It is a valuable exercise to take time to reflect on the past sprint.

Motley: Reflection is for mirrors. What's the point? We just finished the sprint - why open old wounds?

Maven: Hopefully ripping apart flesh is not a good analogy describing your last sprint. It is extremely important to reflect on your last iteration. Let's take the demo. You may wonder why we bother demoing the work we just did. We met on a day-to-day basis and everyone was aware of what each other was doing on a high level. Well, the demo serves a few purposes:

• The demo allows stakeholders that may not be directly involved in the sprint to get a first-hand look at the progress the team made. Feel free to invite people not directly involved in sprint work.
• The demo allows your customer(s) to provide feedback on the work you did, allowing the team to fold in changes in priority or requirements into the next sprint. Remember, customers love to see working software. Solicit them for feedback and changing priorities and update the product backlog. Incorporate that feedback into your next sprint planning session.
• The demo is a chance for the team to celebrate their accomplishments over the past sprint. Seeing working software can really be a morale boost for the team.

Motley: One problem I have with all this is that I don't want the team spending a bunch of time creating demos for the end of sprint meeting when they could be doing real work. Seems like a waste of time.

Maven: Actually, that is a common misunderstanding. You are not out to create a really flashy demo to show off the product. You are simply doing a demonstration of the functionality you just built. There should be no extra gold plating just to look more impressive at the demo meeting. It's not about creating a glitzy demo.

Motley: But what if some members of the team did not work on software directly? They are going to feel left out at demo time.

Maven: Again, don't take the word "demo" too literally. A demo could be a review of a wiki page that was created, a tool somebody wrote, a document that is important to the product, a description of a consulting engagement, or anything else concrete that the team can see some created value from. The demo is typically a 1h meeting that occurs during the slack time between sprints. Make it fun. Bring donuts or burn CDs with interim builds for your stakeholders. Think of the demo as a team building exercise with a celebratory feel.

Motley: Ok, we obviously have room for improvement there. What about the retrospective? What's the point? We just finished the sprint, so we know what just happened.

Maven: The retrospective is a chance to do two primary activities:

• Examine what went well in the sprint. It's important to analyze those processes and team procedures that lead to success and to continue to do them. Having a clear idea of what is working ensures everyone on the team knows the best practices and allows you to encourage them to continue doing them. It is also a bit of a morale boost knowing that what you are doing is working. You also want to avoid turning the discussion into a negative whine/gripe session. Remember the retrospective prime directive:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

From <http://www.retrospectives.com/pages/retroPrimeDirective.html>

• Examine what requires improvement. Perhaps the biggest reason for a retrospective is to focus on continuous improvement, which is one of the principles of agile development. In Japanese, this is called Kaizen ("Kai" = change, "Zen" = good), where you look a system and consider the results and process to get to the results with a non-judgmental focus and goal of improving how you generate results. We want to look at how we can be more effective in the next sprint. Think about what you would do differently next time. Use any metrics you gather for quantitative analysis and use those measures to drive improvements (e.g. Were the estimates off? Why? How can we improve?)

Motley: So we have a quick chat and then improve for next time. Easy.

Maven: Well, there is a bit more to it:

• Clarify success. As a team, determine what success would have looked like for this sprint, and will look like for upcoming sprints. "Begin with the end in mind", as Dr. Stephen Covey says. If we apply Human Performance Technology (HPT) as we discussed previously, we can measure the gap between our current state and desired state, determine root causes, and implement interventions to help the team succeed.
• Ask everyone to prepare. A bit of up-front reflection prior to the retrospective meeting helps ensure the conversation is valuable.
• Give everyone a chance to speak. Chances are good that most people on the team are critical thinkers with a desire to improve. Ensure everyone gets a chance to contribute at least one thing positive about the sprint and one thing negative. Draw out the introverts - they have opinions too. Treat the exercise as a brainstorm - there are no wrong answers. As a last resort, make the comments anonymous.
• Create tasks for improvement areas. Write down everything that is said in the meeting, particularly areas for improvement. Create concrete action items out of the improvement areas with assignments and due dates. Put tasks on the next sprint if needed. Make sure the discussion leads to positive change.

Motley: Jeez, Mave. You always put so much structure on everything. Can't we simplify?

Maven: Actually, this is quite simple. Most of this is just small tips to make you more effective. Just remember to focus on what went well, and what requires improvement.

Motley: One other thing that still isn't clear to me though. What the heck was the point of gathering all the data during the sprint? The data seems as useless as most other metrics. You didn't even mention it as part of the retrospective. We spend a lot of effort capturing them, and then no one ever looks at it again.

Maven: Actually, there is great reason to capture the data. And yes, we do use it in the retrospective and throughout the sprint. It's getting late though. Why don't you head home for the day and we can pick this up in the morning.

Motley: Ah, I get it. That's code for you having to head home and do whatever geeky thing you do in the evening. Have fun washing your pocket protector!

______________________________

Maven's Pointer:  One of, if not the primary reason for short iterations in agile development is to ensure we get rapid feedback. We want to create a culture of continuous improvement of the product, the team, and ourselves. Although sometimes feedback may be difficult to accept, it is necessary for forward progress. Encourage feedback early and often on not just the product but all parts of your life. It is the best way to get better!

Maven's Resources: 

• http://www.restrospectives.com: A web site dedicated to the growing practice of looking back to move forward. The retrospective prime directive is found here.
• Agile Retrospectives: Making Good Teams Great, by E. Derby, D. Larsen, K. Schwaeber, Pragmatic Bookshelf, ISBN: 0977616649, July 2006