Looking at past performance, understanding what was good and what wasn’t and acting on that knowledge is a fundamental activity in highly performing teams. Furthermore, it is the basis of intelligence – behaviour is adapted based on previous experience. Put another way some say the definition of insanity is repeating the same action and expecting alternative outcomes.
Lean talks about continuous improvement. This emerged from the manufacturing industry identifying opportunities for streamlining work and reducing waste. As Agile software development arose from Lean thinking it comes as no surprise that this value carries forwards. The Agile Manifesto repackages Continuous Improvement in the following principle.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
This definition is more explicit. It talks about the behaviours that a team should exhibit. In effect, it is equating effectiveness to the team adjusting its behaviours.
Over time frameworks and processes have been layered on top of the Agile Manifesto, but the concept of continuous improvement remains. XP or eXtreme Programming has a rule that states “Fix XP when it breaks”. The creators of XP are not assuming that their framework is a one stop shop for all eventualities. In fact, the rule’s definition especially calls out the use of the word “when” rather than “if”. XP will have to be adapted on a continuous basis.
Likewise, SCRUM calls out the regular ceremony called the Sprint Retrospective which formalises further the process of inspecting past behaviour and adapting it to be more effective as a team.
Whether you follow SCRUM to the letter, performing sprint retrospectives, or do something different, it is the team that is continuous improving. Most of the techniques for making these activities successful focus on having the team in the same physical location at the same time. So, what do you do if your team happens to be distributed, in different countries and working different hours.
The principles of a ‘restrospective’ or ‘inspect and adapt’ or whatever you happen to call it are generally the same
- Gather points for discussion about past performance
- Get a common shared understanding about these within the team and form a collective view of the most important things to act on
- Formalise the activities to be undertaken to improve team behaviours, performance and effectiveness
These for points hold true whether you are one team in the same room or distributed across the world in different time zones.
This should be the easiest thing to do in a distributed team. After all, in a sprint retrospective with a team sat around the same table there are still periods of time when each team members gather their thoughts individually ready to be presented back.
The time when a distributed team can come together is precious so one option would be to do the information gathering offline. Hopefully retrospectives come at regular intervals so they are not a surprise. The team can be gathering thoughts all the time and adding them to some sort of shared bucket so they are not lost and can be visible to other team members. No set period needs to be put aside for this – it can be a continuous process. Having said this, in most situations it can also be useful to remind your team member of upcoming retrospectives and to put side some time to collect their thoughts.
While it is possible to discuss the points being raised on messaging systems such as Slack, this should not be relied upon entirely. The team can discuss points when they are raised but there will come a point where an interactive conversation is necessary. You want to ensure that the whole team the opportunity to speak and to encourage the shy ones to contribute. You also want the team to be focused on this activity and not be distracted. Asynchronous messaging is good for some things but this is not one of them.
The specific format of this session is down to the team. Some may be happy with a conference call; others will prefer video conferencing. Keep the session interactive so that points can be clarified, misunderstandings reduced and allow all team members to share the “air time”. It requires effort to make this work. No one likes sitting on a conference call just listening and it is an easy place to hide. The team need to put in effort to made this successful.
The group session should be scheduled at a time that minimises impact. If you are in a situation where there is no convenient time for the entire team, then you may have to change the schedule each time so the inconvenience is shared across all geographic regions.
Deciding what are the most important points and what to act on is a team activity. Individuals taking the lead and prioritising some actions over others must be discouraged. Neither should the team be tempted to identify the highest priority actions offline. Not only is it likely that some team members will not understand what they are being asked, the opportunity to have the team get clarifications will have been missed.
Acting as a team
The final step is to formalise the actions so the team can act on them. Ideally there should be a predefined arrangement of how many actions that team should address and how they go about dealing with them. In a distributed team, it is important that the actions and owners are documented somewhere that can be accessed by everyone. It is not so important that they are written up as a group but it is a good idea to determine action owners collaboratively. This often surfaces further misunderstandings. Therefore, if you do this as a group you might be able to catch problems early.
Whichever way you choose to implement your continuous improvement this in itself is not exempt from improvement and the elimination of waste. In fact, as the primary vehicle to effect change it is arguably the most important things to inspect. Therefore, it should not be neglected and neither should it be assumed that once set up it can never be changed. Furthermore, it should be recognised that it requires effort from all involved. No amount of writing up a process or facilitation guarantees success when the team aren’t willing to self-improve.
A small note on tooling
The number one piece of advice I can give for organisations trying to build effective distributed teams is
Invest in communications
This is the obvious stuff like high speed Internet access that supports reliable audio and video conferencing but it also covers establishing the working environment where using this technology is seamless and frictionless. Finally, this investment should include the right tooling so all the team’s efforts can be placed on the task in hand and not wrestling the technology.
If you have ever been involved in a face to face retrospective think of this Google Docs template as a means of turning the post its and pens into electronic equivalents. It doesn’t hold your hands so whatever level of facilitation your team requires if they were in the same room, the same levels will be needed when working remotely. So, this means that if the team already has a commonly agreed approach to managing retrospectives this template will allow them to apply this remotely. It won’t help much with teams just starting out on a continuous improvement journey. Therefore, I would recommend this approach to teams that already have a productive retrospective mindset but who are now branching out to work remotely.
Retruim is an online tool that guides teams through the process of undertaking a retrospective. It is appropriate for both collocated and remote teams. What I like about this tool is that it allows you to choose from a number of well-known facilitation technique such as “Start, Stop, Continue”, “Mad, Sad, Glad” and “Lean Coffee” rather than forcing the team into one style. It also means that each retrospective doesn’t have to be the same as the last. It also formalises the Think, Group, Vote & Discuss stages.
Whilst this is good in principle care has to be taken when working remotely. There may be feeling that the first three stages can be done offline. However, it is the group stage where the team discuss whether items can be grouped which often elicits many of the valuable conversations. When using this tool for the first few times it is better to do all four stages collaboratively and then adapt the process as necessary.