Strip away the marketing and at its heart being agile is about continuous change. The product offering is continually improved by incrementally adding valuable features; and the team continually improve by collecting and acting on feedback about how they are working together. Unfortunately in many teams, this mechanism doesn’t work anything like as well as it could, and retrospectives get neglected. At a certain point, this neglect causes teams to lose interest, and retrospectives are often one of the first things a team drops when they are struggling. One of the most effective ways to negate the value of retrospectives is to hold them too infrequently, so that many things require action, then to collect feedback on how the team think they could improve, only to fail to act on any of that feedback.
It is easily overlooked that projects are in many ways more about the people than the technology or anything else. The single thing that can build a team better than any other is motivation and positive engagement, empowering every member of the team and showing them that their actions matter. When a team come together to discuss ways they could work better, this is a huge opportunity to boost and productivity both directly by implementing more effective processes and ways of working, and indirectly by empowering the team to own their destiny.
I believe every team has an underlying rhythm to them; a natural cadence at which they operate. This cadence is affected by many things, some of the more influential ones being the timetable the team work around (meetings, office hours), their feedback loop (build times, test run times, story size), the internal quality of the product (code quality, architectural integrity), and confidence. Each of these feed into each other, for better or worse, and the combined effect will affect everything the team do. Making a small change to one factor can have a large effect to the overall, and leveraging this is key. Retrospectives are a time when the people closest to these things are able to take a step back and identify the changes that they think would have this impact.
A major problem that can happen if a team don’t have effective retrospectives often enough is that issues build up, both in number and size. When the team eventually do have a retrospective, it can feel like a “moaning session”, where the full time is taken just capturing lists of what is going wrong. This can further sap morale from the team, especially if not handled correctly. Personally, I believe setting a time limit for retrospectives is really harmful, because it imposes a top-down restriction on how the team operate, and stifles the team’s belief that they are empowered to make changes – the effect can be that teams feel like the facilitator is managing the team rather than enabling the team to manage themselves. In my experience the best way for retrospectives to run is for there to be so few issues, and so minor, that the retrospective is naturally quick and there is no need for a time limit – this also means that the team have very few impediments, and can be at their most effective. The way to get to this state is to allow the team every possible opportunity to remove these impediments, which will never happen if time is constrained and issues are allowed to build.
Every single retrospective, without exception, should result in action being taken – no excuses. If issues have been allowed to build up, it won’t be possible to act on them all effectively at the same time, but normally a team can identify the main ones. Again, avoid the temptation as a facilitator to impose a limit here by doing things like voting and selecting an arbitrary number of items – again, it gives the team the impression that they are being “allowed” to make limited change but they don’t really own it. Voting can be a way to clarify the relative priority of issues, but the team have to remain in collective control, not an external manager or facilitator.
Try to encourage small and discrete actions, things that will definitely be achievable – there is nothing worse than seeing retrospective actions wither and die while the team remain affected by the unresolved issue. Sometimes it is worth ignoring the biggest issue – for now – if it is out of reach, and preferring to act on something that is accessible. Sometimes making changes to these more accessible problems will make the bigger problem become accessible next time. It can be helpful to split a retrospective where the issues are bigger into two parts, with a break between – in the first part the team identify a problem, and in the second they reconvene to plan together how to tackle it. Either way, the outcome needs to be concrete actions that the team can commit to – too big and it won’t happen quickly enough.
Once a team have decided what actions to take, your job as a facilitator is to make sure it happens. I believe that retrospective items should be the among the top priority items – I believe that only immediate production incidents rank higher. My reasoning for this is that retrospective items often act as a global multiplier of the team’s effectiveness; it is not productive and frankly disrespectful to ask the team to work ineffectively longer than they absolutely have to. If you send the message to a team that effectiveness isn’t important, why should they feel like their contributions are valuable? Every time “management” or facilitators slow down or limit the team’s empowerment to drive their own improvement, expect a powerful negative impact. Retrospective items should be treated the same as anything else that takes time and effort – they should be assigned to the right people, and they should be discussed among the team at standups if that’s what the team do with other work items.
In some cases where I’ve come in to help a team who haven’t been getting the most from retrospectives (normally because they’re too infrequent and issues have built up), something I like to do is to push to the opposite extreme. The team hasn’t had a (worthwhile) retrospective in months, so I implement a daily retrospective. The first one is the trickiest – there are too many issues. I let the team vent a little, until there is a fairly clear high impact but accessible thing to work on – I then intervene and push towards action. I make sure the session ends with at least 1 clear action, assigned to at least 1 person, and the next morning we make sure that the action is progressing. The action shouldn’t be trivial – I sometimes see actions like “book a meeting”, which is so small it takes less time to just do it – if actions are too trivial, it devalues the exercise, and can seem contrived. The following day, another retrospective is held, opening by reporting on the progress of the previous action. Setting a tempo of little-and-often will encourage the team to set manageable goals and to hit them, and chip away at the problems. Sometimes just removing a couple of small problems give the team enough space to tackle something slightly larger, and the effects accumulate. Within a couple of days of this approach, it is clear to the team that they can make actionable changes, and the result is often that the there is a lot more enthusiasm for the next day.
A challenge with implementing these ultra-short cycle daily retrospectives is that management who are used to infrequent and long retrospectives will expect frequent retrospectives to take too much time. The flaw in that argument is that the reason retrospectives are needed in the first place is to improve throughput by working more effectively; it is much cheaper to have retrospectives, act on the problems, and work effectively than to ignore problems, suppress action to remedy them, and grind away ineffectively. The aim of frequent retrospectives is for the number and size of issues to shrink to almost nothing – meaning that the team are unimpeded. When there aren’t enough issues on a daily basis for a daily retrospective to be worthwhile, the team has won! At this stage, the frequency can then be dropped back accordingly.