While large parts of Scrum can be adapted or even removed entirely to suit the team's requirements the one element that I don't think can ever be compromised is the Sprint Retrospective.
While the format will vary from team to team, and perhaps even from Sprint to Sprint within a team, it is the single most important ceremony, being the key to fixing whatever else has gone wrong.
Stand ups and Planning are arguably more important in their own right, but the Retrospective is the team's opportunity to fix imperfections, and that might be the difference between having Planning sessions that work, and ones that don't.
So what makes a Retrospective work?
Like almost everything in Agile, the right culture is imperative for Restrospectives to be effective.
The team needs to be confident that they can raise problems and concerns without fear of repercussions.
But assuming that you've got that side of things covered, the main goal needs to be to utilise a system that gets people to speak their concerns and feelings (good or bad). There are a lot of different techniques that are popular. I'm not going to go into them in too much detail today, but we will look at the best parts of one of the more common techniques.
Mad, Sad, Glad is one of my favourites because it always produces honest discussions.
If you're not familar with it, it works something like this... Everybody will individually write a series of post-its (or similar) that fit into one of three categories:
• MAD - things that have provoked strong negative emotion
• SAD - things that haven't gone as well as they should/could have
• GLAD - things that have gone well or have provoked positive emotion.
These will then best stuck onto a white board under the relevant heading, and the team will then discuss each point in turn (grouping similar/related points together as appropriate).
The big advantage that comes with writing post-its over adhoc conversations is that people can't shy away from speaking up based on other people's comments - once the post-it is written they are committed. You can easily imagine a situation where somebody stays quiet as a consequence of what somebody else has said, particularly if people have contradictory thoughts on a subject.
For example, perhaps Test felt that a feature was released without an acceptable level of confidence, but the Product Owner was happy with the quick delivery.
Whatever technique a team chooses to use, it's important that everybody participates, regardless of their experience or role. It always concerns me a little when people don't engage fully in retrospectives - while it's usually down to no more than a little shyness, it highlights a risk that their level of engagement within the team is sub-par, and casts doubt over whether they are truly comfortable and therefore able to perform at their best.
The other common failing that I've seen is not having enough time to fully discuss everything that's been raised, which often results in actions not being agreed on. Obviously, not every point raised will have a corresponding action, but it is important to spend the relevant time on each point. Generally speaking, things that are going well end up being brushed over and that's not necessarily a good thing:
The last thing you want to do as a team is stop doing the things that you're actually doing well.
Retrospectives should be seen as an investment into the next sprint, so should have the appropriate time allocated to them. How long is appropriate? Enough - but not too much...