Agile Development: My New Approach for Retrospective Meetings
Retrospectives, or that annoying meeting in my calendar that prevents me from coding (as I used to think). Are they important to the development function? Who benefits the most?
When I was a contractor, I was obsessed with collecting story points by closing tickets. This wasn’t for bragging rights; I created a story-point game for myself, where I had to kick my butt week by week. If I had closed tickets for 300 story points in Feb, March had to be at least 301, and if I missed that mark, I was genuinely upset.
Because of the above, any meeting I viewed as unnecessary time away from coding used to grind my gears. I could understand the value in standups, three amigos, post mortems, and refinements, but retrospectives…I used to shake with rage when I saw it was on my calendar.
From my perspective, I knew what was or wasn’t going well on my team simply by being an active participant and engaging. This felt like unnecessary bureaucracy. I never considered that while certain things were obvious to me, they might not have been for a non-technical stakeholder or a more junior engineer.
When I started to think about things outside of my ticket-closing mentality, I started to think about the actual value of the retrospective, and that's when I started to see the bigger picture.
When my perspective shifted
I was contracting for a large agency, and we were under fire. Our company had made stupid delivery assumptions for the project, and before consulting any engineering leadership, they delivered that estimate to the board. This could be a blog in and of itself, but let’s not digress.
Now that the die had been cast, we lackeys were up to pull a rabbit out of the hat. This meant we had to constantly press to match our velocity with the expected delivery date, which, as you can imagine, was incredibly stressful.
One particular sprint was an absolute disaster. Everything that could go wrong went wrong: unknown package bugs, phantom production issues, and a major ticket misinterpretation, which resulted in an epic not being completed correctly (this wasn’t caught at QA either). We were under fire, and what we needed to do to create space was assault our backlog and get back on top (or at least that’s how I felt).
Reluctantly, I went to this retrospective; this was the first sprint we had with a brand-new product manager. I pre-packaged my sarcastic comments to the usual “what went well, what didn’t we like?” rhetoric. But something unexpected happened; he didn’t go down that route. Instead, he shifted the conversation to “moments of learning”.
As we went around the room, colleagues shared not just grievances but genuine insights into how specific challenges had led to personal and team growth. I listened, somewhat reluctantly at first, as a junior developer expressed how a casual comment I had made helped simplify their workflow significantly — a comment I had forgotten soon after making it.
This was my lightbulb moment. I realized that what seemed trivial or obvious to me could be revelatory for someone else. The retrospective was not just a forum for airing frustrations but a vital space for sharing knowledge and fostering understanding across the team. I began to see these meetings not as a barrier to my work but as an integral component of our collective success.
How I approach retrospectives now
Whilst I must admit the urge to code will always be a part of me as a developer, I now appreciate retrospectives and no longer view them as a time sink in my calendar. Meetings should naturally always follow the work, so I appreciate a successful meeting no matter the context.
However, unlike in the past, I now come more prepared for each session with notes on what could be improved and what we had achieved and learned. This preparation allows me to engage more constructively, encouraging others to see these meetings as opportunities for growth rather than obligations.
Retrospectives have evolved into strategic sessions where we can align our goals and expectations, significantly reducing misunderstandings and misaligned objectives. Moreover, these meetings helped us build a more cohesive team dynamic where every member felt valued and heard.
Conclusion
Looking back, my point of view has been altered and transformed into an advocacy for retrospectives.
This experience taught me the importance of being open to change and understanding perspectives different from mine. For those still on the fence about the value of retrospectives, I encourage you to dive in with an open mind. You might be surprised at the difference it makes, not just to your projects but also to your growth as a leader and a collaborator.
