At the conclusion of a lot of projects, we conduct retrospectives in order to gain a deeper understanding of the success factors of the project, discuss what could be improved and how to incorporate these into future projects.
How many of these focus around the actual design elements of the software developed? I have not heard of any projects which have had a post-development analysis, so I can only conclude that it is through introspection that good developers learn and improve. I wonder why teams have not done this retrospective analysis, or if they have why I haven’t heard of it.
I am approaching the conclusion of my current project, so I will be keen to try a technical-only retrospective, where we take a look at the various patterns we employed, and how effective they were in solving our problems.
Hi Sarah,
Saw your comments re the Silicon Stilettos meetup.
I was half expecting an introduction there also.
Otherwise what the hell were we there for : ).
I suggested to Zuz before I left that there should be a speaker at the next event, to make the meetup much more relevant.Then the people that will genuinely want to go will go. It was supposed to be about Entrepreneurs and not PR people. Mind you I currently do PR (but am more technical then PR-do several roles in one) and don’t necessarily see it as a bad thing either as they will tell people about it.
Just thought your comments were very relevant.
Ina
I like these a lot — I call them technical retrospectives. I’ve also used them at the start of a project or when coming into a new team to get to know the codebase and the way the team thinks about it. On my most recent project we tried to do technical retrospectives every month or so and to take the learnings forward into the next release.
Pingback: Technical/Code Base Retrospective at Mark Needham