A guest post from James Harvey at Box UK
Agile teams naturally get better over time. However, as teams bond and become more efficient, the risk of complacency brims to the surface. When you’re performing well, it’s all too easy to skip a Sprint Retrospective because you feel that you’re already good enough. This blog post explores why Sprint Retrospectives are always an essential part of team development, and how keeping outside of your comfort zone is the key to continuous improvement and success.
When a project team starts out for the first time, there may be some uncertainty and assumptions, and most definitely a period of time is required for the team to familiarise themselves with working with each other. During this period, running a Retrospective after every Sprint feels natural, and should yield many lessons learned that will drive improvements moving forward.
A successful Retrospective should take place in a relaxed environment, with the following questions addressed by the entire project team:
- What went well during the Sprint?
- What could’ve gone better during the Sprint?
- What could we do differently to improve in the future?
The first two questions are the easiest to discuss, as information on what went well and what didn’t go so well should be recent and easy to reference. Identifying what can be done differently can be a tricky one and is often overlooked, especially since these actions may not necessarily be related to the good or bad aspects of the Sprint. The natural human reaction is to leave what has gone well, fix what’s broken, and then leave it at that. Only the best teams identify areas for improvement independently of these issues; but finding new, better ways to do things is the key to a high-performance team.
One of my favourite aspects of agile is the idea of continuous improvement and, more importantly, the idea of improving for the project on which you’re currently working, rather than simply thinking about how you can better yourself for future projects. Using Sprint Retrospective meetings provides the perfect forum for communicating this message and allowing the team to discover for themselves what they can do better as a team. However, this shouldn’t be at the expense of acknowledging what brilliant things are already being achieved within the team.
It can be too easy sometimes to focus on what needs to change to get better rather than what can be improved to get better. Just because the team excels at something doesn’t mean that they can’t push it further! A good ScrumMaster will always find ways for even the most refined process to be improved. And a truly successful agile team is one who constantly evolves by never entering the comfort zone that’s brought on by sticking to apparent “tried-and-tested” methods.
Sticking to the Process
From my experience with agile teams, Sprint Retrospective meetings are skipped when a level of efficiency is hit because, “Hey, we’re already doing a great job so why do we need to find things that are wrong?” This is where the danger of entering the comfort zone starts to become a reality. Without doing anything wrong, you’ll find that the team will lose velocity, efficiency and drive, and enter a slump where the assumption is that work will get completed without any effort.
In fact, it’s after a couple of Sprints when a project team is firing on all cylinders that the real value comes out of Retrospective meetings. The challenge of improvement becomes greater, but the reward of achievement is also amplified enormously. I once heard the phrase “If you’re standing still, you’re moving backwards” and could never make sense of it. The more I’ve thought about it though, the more I understand how applicable it is to agile working. It’s all too easy to miss the point of continuous improvement, especially when things are going well. But to me, the potential for teams to constantly push themselves is one of the most exciting things about using the methodology.
To be truly successful, a project team will continue doing the things that go well, stop doing the things that don’t, and continue to find new ways to work that will ultimately make the team more efficient. Without wanting to labour the point, agile fundamentally works because of the consistency and routine that is built into each Sprint. A Retrospective meeting is an essential part of this puzzle and no Sprint should be considered complete without it.
To wrap up, here are some key things to remember:
- Make sure Retrospective meetings happen after every Sprint, without fail
- Focus on what went well and what didn’t go so well
- But don’t forget to also focus on what can be done differently to improve, independent from the above
- Ensure that each suggested improvement is recorded somewhere so you can track it through to the next Retrospective
Sticking to these simple points should mean that your agile team does not get the chance to enter the comfort zone. When this process is managed and sustained, it keeps things fresh; more importantly, it ensures that the project being worked on is laced with continuous improvement, leading to not only a brilliantly prepared deliverable, but a team that is extremely motivated and chomping at the bit for the next Sprint to start.
With a background that has taken him from developer roles through the Production Manager position he holds at Box UK today, James Harvey is particularly interested in agile methodologies and how they can be used to enhance client satisfaction. You can find out more about agile, or any other aspect of our operations, on the Box UK blog.