A retrospective in software development methodology is a look back at a project cycle. Usually, a retrospective refers to a formal meeting held at the end of a development cycle. Retrospectives provide context for where you are, and can help you figure out where course adjustments might be needed.
I’m going to start a series of project retrospective blog posts. My intent is to go a bit beyond the standard “lessons learned” aspect of a classic case study by discussing ways to address those lessons learned if I were delivering on the same requirements today.
I understand there’s some risk in this. The very nature of talking about “what I’d do different today” is a dynamic target. The answer could be different tomorrow, when you’re reading this. Perhaps that’ll be another chance to revisit the topic.
In these posts, I’m going to go over my own project history and do a full post-mortem on whole project deliveries. In order to protect potential client property, I’ll generally avoid identifying the client I did the work for and/or any publicly known project name. Teammates familiar with the projects will be able to identify them, but that’s ok.
Whenever working on a longer-term, non-trivial application, it’s inevitable that before the project is completed, technical debt sets in. Most commonly, some of the components are obsoleted by newer versions of tools used in the project, and there’s no immediate need or budget to update it. As long as those tools are still supported, it’s generally de-prioritized as a problem for another day. Longer term, everything is eventually obsoleted.
Another inevitable part of code development is the classic “if I had it to do over again” aspect. This is a big-picture extension on the old “Make it work, make it right, make it fast” practice. The first time through a project, there’s always “make it work” moves that end up being what gets delivered, without opportunity to get to the “make it right” / “make it fast” cycles. If I had the project to do over again, I’d “make it more right” or “make it faster” by doing ‘X’.
Likewise, every project cycle has its ups and downs in terms of team interaction. Some times folks are on the ball, and the code flows. Other times, there’s what we call blockers… things that hold up progress.
A blocker could be any number of things.
A common blocker is missing or incomplete requirements. It’s hard for a programmer to teach a computer to do work if the programmer doesn’t know how to do that work.
Another common blocker is access or permissions. A programmer might have a requirement to develop code that depends on another service. If that’s the case, the programmer might be able to build an abstraction of that service, but eventually will need permission to access that service in some form to do integration testing.
In this case, I’ll still take the classic retrospective approach. I’ll address the following questions:
- What did we set out to do?
- How and why did we deviate from plan?
- What worked?
- What didn’t work?
- What would we like to do next time?
- How could we improve what worked?
- How will we minimize the risks of what didn’t work?
- How will we address any technical debt incurred?
Some retrospectives avoid management in order to avoid addressing these questions politically. In better situations, some representative of management and/or project stakeholders are included in order to get a more complete view of the project.
In my posts on the topic, it’ll just be my perspective, and I’ll be addressing the questions holistically. Having completed the projects and disbanded the delivery teams, with minor name changing to protect the innocent, politics need no longer apply.
I’ll admit, there’s some self-gratification in doing these post-mortems publicly. I’ll be able to show off experience, and hopefully grab the attention of folks who’d like to produce similar projects. My hope is to inspire more of the latter and spark up the conversation around how to apply similar solutions (preferably with the “desired state” improvements).