At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Continuous improvement is one of the fundamental principles of agile ways of working. Improvement at a team level is often realised in the practice of a team retrospective. The purpose of a retrospective is to inspect current ways of working, relationships, tools, and processes and translate insights into tangible actions or experiments.
Having a retro as a team isn’t enough. Inspection without adaption is pointless.
If you regularly talk about something but nothing happens as a result, you might start to feel something like ‘What is the point of highlighting anything as nothing changes anyway’ and when this happens, the pillars of empiricism begin to fall. I.e. there’ll be a lack of transparency – leading to little or nothing to inspect – and no adaptation as a result.
In his book Team Mastery, Geoff Watts has created a set of cards highlighting key milestones teams tend to reach along their journey of team mastery. Putting retrospective ideas into practice is a fundamental card included in the self-improvement chapter.
Milestone Card 1 from Geoff Watts book Team Mastery
Below is an overview of a system that is in place for team Encode, that allows us to log, track and check off all of our improvement actions.
The first step is ensuring we spend time in our retrospectives turning ideas and insights into tangible goals and actions. To ensure this happens we have a dedicated space as part of our retrospective canvases that prompts us to log actions. Either as part of the conversations generally or towards the end, as a team we look at what we might be able to do as a team to improve whatever it is we have raised in the retrospective.
From here we use Confluence to log actions, insights and even general ideas. For each retrospective we have, we keep a record in our team space, which includes a link to the canvas we used, the date the retro was held, the participants that were present in the session and any actions we took.
- Tangible actions tend to have an owner and are created in Confluence as a to-do item that we can tick off once complete.
- Sometimes we don’t know the solution to a problem when we are in the retro, it may need further discussion or something that we might want to keep an eye on and monitor, or sometimes something is too big and needs to be broken down. For these general ideas/ insights, we add text as an overview or a snippy of the board, to the confluence page and then use Jira epics for the action.
- In effect, we create mini-initiatives that have tasks that flow through the team board in the same way as we do for product development. This allows us to utilise our workflow and tasks are visible and flow through the team board. Thus prompting a discussion topic as part of our daily scrums and together ensuring it meets AC and the definition of done.
The parent page of the confluence space, our Improvement Plan page itself, includes a Task Report widget that looks at all incomplete to-do items from all child pages of that section and lists them together.
We also include the epics if we have them that show tasks and the statuses of anything that has been added as Jira tasks. The benefit of showing them all in one place is that actions can be grouped and reviewed regularly as part of future retrospectives/ team discussions.
I find this a great way to help ensure ideas are put into action and proven to be effective. Upon reviewing our ratio of actions carried out as a team in 2023, 76/79 actions were completed equating to 96% of all improvement plan actions being complete.