Achieving Closure on Projects and Avoiding the "bus factor" Effect

Problem

I often found small engineering teams with many features to implement ending up having each engineer working in almost complete isolation. This can be efficient in the short run, when a team needs to move fast, and it can also be empowering, since an engineer can control the full scope of a project. But single-engineer projects also mean their authors automatically become the maintainers. Things worked fine for the first 2 years, but after 3 years in that model, a given engineer may have produced ~12 projects and would most likely be pretty much alone maintaining them, thus not having any capacity to take on new projects. This get even worse when engineers responsible for key projects left the company.

Actions taken

The main realization was that we needed to close projects, and make sure that a given engineer would stop working on a project at some point. This of course implied having a clear definition of done, but the most efficient change was doing "project closure ceremonies". During those meetings, we would do a formal retrospective, describe what would still be left for subsequent milestones, review the documentation, and transition the maintenance to another engineer.

Lessons learned

Formally closing projects enabled us to celebrate achievements, transitioning the maintenance was an efficient way to spread the knowledge of the system, and more importantly enabled engineers to confidently move on to new projects without being tied to the past.

"Formally closing projects enabled us to celebrate achievements" "Transitioning the maintenance was an efficient way to spread the knowledge of the system"

You have to start a project with its closing in mind, especially the succession plan to other engineers.