Everybody is talking about how "Agile" makes you succeed.
However, Agile is not a silver bullet. When using an empirical process, there are many failures on the way to success.
In this blog, I want to share the failures from which I have learned so that others may also learn.
The retrospective should be oriented towards a meaningful result, as you want something to get better. However, many teams struggle with the notion of Continuous Improvement being the team's responsibility, and so their Retrospectives are derailed.
Unfortunately, it is not only the teams who derail a Retro, but also well-meaning Scrum Masters.
Here are some problems that indicate your Retro may not be meeting its purpose:
Yes, especially in transitioning
organizations, there is often a lot to complain about. Even in
well-running environments, we can complain about many things. However,
the purpose of the Retro is not to provide a ranting forum, but to elaborate one thing that should be modified.
Often, teams zoom in on one thing that
concerns them and their work, ignoring the big picture. Maybe the first
thing a team should work on is something that only remotely concerns
them, but affects the organization at large? It's just a maybe. But give room to
the thought, in order to prevent local optimization. Think Lean: "Optimize the Whole!"
Over-zealous Scrum Masters may be determined to set not only the topic for the Retrospective, but also
steer the team towards accepting their solution to the problem. A Scrum
Master has the full right to add an observation to the Retrospective,
but they must realize they are facilitators, not actors!
There is a tool called "Retromat"
out there on the Internet which might encourage over-ambitious Scrum Masters to
fire off a wild pandemonium of effects in an attempt to make the Retro
memorable. Unfortunately, the Retromat simply randomizes a set of
methods without providing a continuum. This distracts, rather than
focuses the team. A Scrum Master should be aware that Retrospective tools are intended to focus the team on the issue at hand, not on the method itself. While the Retromat itself is not bad, care must be taken to choose appropriate methods suitable for the session context.
A good Retrospective must be sufficiently open so that everyone can
name their biggest concern and gives everyone a voice in the solution
process, but quickly provides a funnel towards a single workable change.
The facilitation of the Retro should support this process as naturally
as possible, while still keeping focus on a meaningful overall outcome.