Bad habits die hard, so they say. Because we get caught up in ticking off our daily tasks, we as humans just learn to “get on with it”, and rarely stop to take a hard look at how we are doing. As long as our tasks are ticked off, there is hardly any reason to do so, right? After all, we are getting through our task list, right? So why not just move on to another week of work. Otherwise known as “Routine”, we do, do, do, and never really stop. So bad habits perdure, and unless those bad habits are causing a major meltdown, they’re flatly ignored or unconsciously dismissed…”Keep Calm and Carry On” until it’s too late.
I remember training for a marathon. I used this training programme taking me through weeks of runs, a mix of short runs and longer stints. I ran using shoes unadapted to very long runs but i didn’t know it, they felt perfect. I ran through woods on uneven roads and paths (so much better than running on asphalt next to traffic jams, right?). I didn’t care, I was flying and hitting my targets. Until one week before the race, when I was hit with an injury so bad, it prevented me from taking part in the event. To this day I’m going through Physiotherapy (a year later). I didn’t fully measure the outcomes of my bad choices until it was too late, as I had no warning signs of injury. Had I received any feedback, I would have taken the necessary steps and wouldn’t be injured.
The history of software development is marked with failed deliveries, massive budget overruns, and we still see too many of these today. In the 90s, eXtreme Programming, also known as XP, appeared in the field of software engineering, and carried a number of values and working practices aimed at maximising delivery success: one of the main ideas was “Early Feedback”. This feedback is meant to ensure the team is on the right tracks and doing the right thing, on several levels:
- The first level of feedback is around coding, where multiple programmers check the same lines of code,
- Another level is on having a daily checkpoint ensuring all team members have an opportunity to share progress and flag any problem.
- Next level is getting feedback from end-users, ensuring that the solution is in line with what the users want or need.
- The last level of feedback is the Team Retrospective: a meeting at the end of a Sprint (iteration) where all members shut down their workstations, take a step away from the code they’ve built, and take a hard look at their “ways of working”. Team members ask themselves “What has worked well? What could have been improved? What can we do as a team to be more efficient in the next iteration?”.
You might ask why are Team Retrospectives important when other feedback loops ensure a safe delivery of software? Retrospectives ensure that teams are using an efficient working process from one iteration to the next, and give an opportunity to introduce better ways of working. These improvements can range from introducing a new practice, or implementing a better process that makes the team more efficient. It can be as simple as “Doing more show and tell sessions with the business”, or as random as “we should go to the pub on Fridays”. It can mark the end of doing something useless (4 hours for iteration planning?). It fosters creativity, by coming up with good ideas that benefit the delivery, and Retrospectives ensure teams adapt to new challenges they face from one iteration to the next. Any bad habit is flagged and removed before the next iteration starts. Teams conduct a Retrospective at each and every iteration, because some bad habits only show their tail later.
Team Retrospectives can be managed using different methodologies, and I have a preference for the Starfish method in which each team member proposes ideas in 5 compartments: “Start doing”, “Stop doing”, “Keep doing”, “Do More of…”, “Do less off…”. Each team member writes some ideas on post-its, and sticks them in the appropriate area of a white board. The team then discusses those ideas and decide what to implement in the next iteration. Some teams will vote for the best ideas to implement.
A note of caution: Extra care should be taken to not let unexperienced teams make rash decisions around their ways of working, and senior advice should be available if needed. Agile coaches with experience are best placed to help unexperienced teams safeguard key aspects of delivery so they don’t fall apart.
Because we are often told to be “Productive” rather than “Effective”, I’ve seen many teams skip this meeting altogether, convinced that they’re moving in the right direction, viewing the meeting as a waste of time (especially when we always have some unfinished work at the end of an iteration…). Needless to say, those were teams that were not hitting their targets, and where there were the most defects found in production, issues found too late in the delivery chain. Nobody thought to say “stop! we must be doing something wrong”. No developer in those teams was given an opportunity to propose a better process, no time was taken to take a step back and see things for what they truly are. “Just keep moving through the task list, because that’s all that matters…Keep Calm and Carry On”. When auditing an existing development team, it’s the first question I ask: “is the team doing Retrospectives?” because it speaks volumes about the willingness to be more efficient, or not.
In every field and every aspect of life, feedback is essential to ensure we are moving in the right direction, and to minimise the risks of failure before it’s too late. Agile methodologies such as XP and Scrum have several feedback loops built-in, Team Retrospective ensure a team is committed to be more efficient, more adaptable and more creative.