This is very much a shared pain, though my experience is mostly outside the programming world.
I see it as a fixable pattern, but the inertia is strong.
- Lessons learned and retrospectives don't take place as often as they should
- The sessions themselves sometimes get a bit defensive, so the real nuggets get missed
- Even if a good session takes place, it ends up being static data buried in another archive
Taking an example from the construction world, I saw project after project suffer from poor planning and design. Common enough issues to warrant a moment of investigation, but not, then later being passed off as "black swan events". Because who would have thought the ground conditions would be suboptimal near a swamp?
There's something to take from the Health & Safety world. Talk about stuff. An organisation I worked for had a rule that every meeting, irrespective of purpose, had to start with a safety conversation. Something new, a reminder, a good story - just something safety focussed - and a reminder to look in the H&S system for updates and other stories. There's strong correlation between proactive conversations and reduction in safety incidents.
My thinking is that this approach should work across domains. I've done it with teams in the non-programming space with some success. A few minute knowledge-share at the start of stand-ups and regular meetings seemed to reduce the number of times known issues/challenges happened a third time. Just be prepared to lead the conversation with "I was looking through old lessons learned and saw <thing>... good reminder to <action>..." or something.
I often kept a personal "notes" file while I was working on a project/feature. I now think that what I should have done is check that file into the source tree, at the top level directory for whatever feature I was doing.
This is very much a shared pain, though my experience is mostly outside the programming world.
I see it as a fixable pattern, but the inertia is strong.
- Lessons learned and retrospectives don't take place as often as they should
- The sessions themselves sometimes get a bit defensive, so the real nuggets get missed
- Even if a good session takes place, it ends up being static data buried in another archive
Taking an example from the construction world, I saw project after project suffer from poor planning and design. Common enough issues to warrant a moment of investigation, but not, then later being passed off as "black swan events". Because who would have thought the ground conditions would be suboptimal near a swamp?
There's something to take from the Health & Safety world. Talk about stuff. An organisation I worked for had a rule that every meeting, irrespective of purpose, had to start with a safety conversation. Something new, a reminder, a good story - just something safety focussed - and a reminder to look in the H&S system for updates and other stories. There's strong correlation between proactive conversations and reduction in safety incidents.
My thinking is that this approach should work across domains. I've done it with teams in the non-programming space with some success. A few minute knowledge-share at the start of stand-ups and regular meetings seemed to reduce the number of times known issues/challenges happened a third time. Just be prepared to lead the conversation with "I was looking through old lessons learned and saw <thing>... good reminder to <action>..." or something.
I have my own personal formal debrief process for larger projects: https://github.com/EternityForest/THUNDERWARS
Usually if I notice anything of interest to others, it just winds up in a group chat.
I often kept a personal "notes" file while I was working on a project/feature. I now think that what I should have done is check that file into the source tree, at the top level directory for whatever feature I was doing.