You can subscribe to our monthly newsletter here:
Editor's Note: This is a guest post by John Blanco. John Blanco is an experienced IT management professional with a proven track record in aligning IT strategies to core business objectives and delivering innovative solutions across an array of business disciplines (and is certainly experienced in sprint retrospective techniques!). As an accomplished strategist in IT Portfolio Management, systems design and implementation, product development, and business communication, John has utilized his skills across numerous industries and Fortune 500 companies including NBCUniversal, Scholastic Inc., Direct Brands, Merrill Lynch, iCentral Corp, Alliance Consulting, OpenMetrik Inc., Cablevision, Alyn Hospital, ORC, EMI and ADP Brokerage Services. John's opinions and innovative contributions to the IT field have been recognized and published in CIO Magazine and ComputerWorld.
. . .
In a scaled Agile approach, which guides both IT and non-IT teams in scaling Lean and Agile practices, we must go a step further to include the purpose of retrospectives for the program and portfolio teams. The team should reflect on how to drive more end-user value and adjust its behavior accordingly.
According to the Scrum Guide, a retrospective meeting is "an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next sprint." In simpler terms, retrospectives are the chance for the team to voice what worked well, what didn’t, and how to make positives changes during the next sprint.
In the preface of his book Project Retrospectives, Norm Kerth, the founder of the modern-day movement on retrospectives, offers us a humorous analogy from the classic Winnie the Pooh on the purpose of the key end-of-sprint event.
Without retrospectives, we become much like Edward Bear.
We repeatedly bump our heads because instead of inspecting and adapting we repeat our mistakes over and over hoping for a different result. We must stop the madness of checking items off our list and throwing ourselves headlong into the next project, and think for a moment about how we can plan and steer our teams in a smarter way!
The sprint retrospective is one of the most important, and often least appreciated practices in the Scrum framework. Yet, at its core, it provides a carefully monitored timebox, a means for teams to examine what’s happening, analyze the way they work, identify ways to improve, and make plans to implement improvements. In simple terms, the retrospective aims to review:
- What worked well this sprint that we wish to continue doing?
- What didn’t work well this sprint that we should stop doing?
- What should we start doing or improve?
The entire team should care about the results of the retrospective. Because this is a time for reflection, it truly requires the awareness and attention of everyone involved to be successful. Here are a few points to keep in mind as you plan a retrospective exercise:
1. Invite everyone.
Agile practices focus on giving teams and individuals ownership of their work and accountability to the team and organization. This level of responsibility, investment, and involvement increases the emotional connection that each person feels for the work. To further ensure the feeling of responsibility, we need the full Scrum team in attendance at our retrospective. This includes the development team, Scrum Master, and Product Owner as well as anyone else involved in designing, building, and testing the product.
Trust is at the core of this event and we need to “hear what people are thinking” if we intend to make a difference.
2. Free-form sprint retrospective techniques are wonderful, but a little focus is even better.
One of the best sprint retrospective techniques is using post-its and markers (or an electronic substitute) and asking people to list the best things that occurred during the meeting.
It is best to start with the positive as it celebrates success for a team that may have stumbled a bit. Heck, they might even feel a bit beat up.
The positives allow us to realize that we did accomplish something of value for our customers. After success is recognized, we move on to what didn’t go so well. The secret here is to sneak in some quantitative metrics.
Simply asking “What didn’t you like?” may be too broad. Answers like, “The coffee in the lunchroom is not good,” doesn’t exactly serve the purpose of the exercise. We want to encourage the team to focus on the things that we can control so that we have the greatest positive impact. Show the team how they did in terms of completing stories, handing off work at integration points, and reducing technical debt to center the conversation.
3. Everyone votes.
We love to make lists, but lists are not Action Plans. Coming out of a Retrospective, we want a concrete and actionable list of “start doing” and “stop doing” items. We never want to get into a situation where the team is dedicating time to uncover areas for improvement, but nothing seems to change. This leads to boredom, frustration, and finally disengagement.
After you’ve listed the item-candidates for change, have the team vote. Use stars or some other token and give each team member three votes. Have them mark the items that they feel have the most impact or greatest potential to make a difference. A little traction creates momentum, and focused momentum gets things done.
4. Document your findings.
The Scrum Master should leave the room with an artifact that includes the items for change, an owner, and an estimated time of delivery. Don’t make this a Dead Sea Scroll, but do have something that can be assigned, measured, and monitored. Action items like this are great to review at the end of - daily standups. I hate to hear the same problems raised at every retrospective–“Oh, you mean we were supposed to do something about that?” Yeah, actually, we were.
5. Vacuum with the lights on.
As a kid, my mom used to give me chores. I hated doing them, but a boy must do what a boy must do.
One of my chores was vacuuming the house. To make it bearable, I blasted Led Zeppelin or The Rolling Stones. When I finished, my mom would inspect the quality of my work. Keep in mind – I never did a good job. Jimmy Page always beat out the crumbs under the kitchen table.
Time after time I heard, “Johnny! The next time you must vacuum with the lights on!”
I never understood what she meant by that until years later, but it applies here. You cannot do a good job or learn from your mistakes without looking at what you are doing.
Similarly, Agile is designed to unearth people, process, and product improvements through a rigorous focus on continual improvement. Teams must pursue improvement in all areas including those that might be a bit embarrassing. During your retrospective, turn the lights on by bringing data into the meeting. Consider visual reports, like those in Targetprocess, to uncover the areas in which the team can hone their approach to speed up, release faster, or provide more value for customers.
The most important sprint retrospective technique: Trust. Trust. And more trust.
That’s what it’s all about. Remember, our goal is to create an environment where people are relaxed and have a sense of camaraderie. People work best with people they like working with. We are all unique and bring different skills and qualities to the party. Most importantly, it takes everyone and their unique contributions to make success happen. Every voice must be appreciated and heard if our goal is to improve people as individuals, which in turn improves our team.
Are you holding retrospectives at the team level? At the program level? Don’t let this ritual be forgotten.
As Thomas Edison said, “There’s a way to do it better—find it.”
If you’re looking for a better way to plan, track, and steer your Agile team—take Targetprocess for a test drive. We’ll show you our proven formula for managing work at the team level while providing real-time visibility to business level stakeholders.