Retrospectives are one of the most widely discussed aspects of Scrum. There are virtual whiteboard templates, tools that attempt to automate information gathering, and entire books dedicated to different models and techniques for making retrospectives engaging and effective.
Yet, despite all this guidance, most Scrum teams default to the same format sprint after sprint: WWW/TALA (What Went Well / Take Another Look At). It’s easy to see why—it’s simple, familiar, and encourages discussion. But does it actually lead to meaningful improvements?
In this article, I’ll explain why WWW/TALA often falls short and offer a more effective approach to retrospectives—one that focuses on actionable changes and drives real improvement.
The Purpose of a Retrospective
Before discussing alternative formats, it’s important to clarify what a retrospective is supposed to achieve. A retrospective should:
- Generate insights about what’s working and what isn’t.
- Facilitate decision-making on how to improve in the next sprint.
- Create a psychologically safe space for open and honest discussion.
- Result in tangible changes that lead to better outcomes.
Without these elements, a retrospective becomes little more than a routine meeting that teams tolerate rather than value.
The Impact of a Strong Retrospective
When retrospectives are done well, they can drive significant improvements. Here are some real outcomes I’ve seen:
Process Changes
- Teams started breaking work into smaller items, improving flow.
- Sprint planning was restructured to focus more on team capacity and predictability.
- Teams experimented with shorter sprints, including single-day sprints, to test adaptability.
Cultural and Team Dynamics Shifts
- Team members stopped working in isolation and embraced collaboration.
- Pair and mob programming became common.
- The daily scrum was moved to a different time to reduce interruptions.
Structural and Organizational Changes
- Management adjusted policies to better support Scrum practices.
- The team gained approval to use different tools that better suited their workflow.
- Sprint reviews began including actual customers, leading to better product feedback.
These kinds of outcomes don’t happen by accident. They require a retrospective format that challenges the team’s status quo and encourages deep reflection.
The Effects of a Retro on a Scrum Team
Some key things I have seen happen with Scrum teams due to their retrospectives:
- They started making smaller work items which improved flow
- Management made changes to support the team’s practice of Scrum
- The architecture around the team was changed to remove obstructions to completing work in mere days
- Team members agreed to stop working independently of one another and collaborate
- Pair and mob programming
- Hackathons
- Single-day Sprints
- Changing when and where events were held, whether cameras were off or on
- Changing the way tools were used or going to management to get support for different tooling
- Management no longer insisting on “roll-up status” out of teams as a control mechanism
All of these things are possible, however unlikely, but I do not believe they happen when you WWW/TALA your retro.
Why WWW/TALA Falls Short
The WWW/TALA format may feel productive, but it has several weaknesses:
“What Went Well?” Prioritizes Celebration Over Improvement. Recognizing successes is important, but a retrospective’s goal is not to be a feel-good session—it’s to uncover opportunities for growth. If a team has a major breakthrough, celebrate it separately and let the moment stand. Don’t immediately follow it with “Now, what went wrong?”—that kills momentum.
“Take Another Look At” is Too General. This question invites a flood of complaints but provides little structure for making meaningful changes. It encourages teams to list problems without identifying whether those problems are:
- Actionable (things the team can actually improve)
- Systemic (recurring obstacles vs. one-time issues)
- Relevant (problems that significantly impact delivery)
Instead of using WWW/TALA as a default, teams should focus their retrospectives on areas where change is possible and impactful.
A More Effective Retro
Instead of an open-ended conversation, consider trying a focused conversation around the Scrum practice of the team:
Unpack the DoD. Where is it? Is it transparent (visible, accessible, easily-understood)? Do we actively use it, or is it buried on some Confluence page?
Unpack the Working Agreements. The Scrum Guide doesn’t explicitly define working agreements, but all teams have implicit rules about when, where, and how they work together. Retrospectives are the perfect time to revisit these. Would a single-day sprint be feasible? Try it and report back. Is the daily scrum interrupting deep work? Move it. Are sprint lengths too long? Experiment with shorter cycles.
Unpack the Events. Could sprint planning be more effective? Experiment with a new approach. Should developers run the daily scrum without the Scrum Master or Product Owner? Try it. Could sprint reviews include real customers for better feedback? Start working toward that goal.
Unpack the Tools. Are tools helping or hindering the team? Is Jira (or ADO) slowing things down? Would a lightweight Kanban board be more effective? Would a “shadow board” in Mural or Miro give the team more visibility and flexibility?
Unpack the Team’s Scrum Practice. Look at a visual representation of Scrum – are there elements the team isn’t doing? Most teams don’t use the Sprint Goal. Almost none use the Product Goal. Why? What are the twelve accountabilities of a Scrum Master? Are they happening, or has the SM been reduced to a meeting facilitator and status reporter?
The Purpose of Scrum
One of Scrum’s most powerful yet overlooked aspects is how it exposes dysfunction. The Scrum Guide states:
Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.
This means that Scrum reveals what isn’t working—both within the team and in the organization. The more a team tries to follow Scrum, the more they expose obstacles to agility.
Retrospectives should leverage this visibility to drive meaningful change. They are not just an opportunity to reflect but a mechanism for continuous improvement.
Make Your Retrospectives Count
WWW/TALA is easy, but it rarely leads to significant change. If your retrospectives feel repetitive or unproductive, shift the focus toward specific, actionable areas of improvement:
- Revisit the Definition of Done
- Challenge outdated working agreements
- Experiment with new ways to run events
- Assess whether tools are helping or hurting
- Evaluate whether Scrum is being fully leveraged
Retrospectives should drive action—not just conversation. If they aren’t leading to real changes in how your team works, then they aren’t serving their purpose.
Try it out in your next retrospective.
