Running retrospectives can be hard work. The outcome can be affected by the dynamics of the group, how controversial the topic of the retro is, and work pressures external to the session. Here are some rules that I’ve found useful when planning and running retrospective sessions.
We’ve recently hired our first group of graduate developers, and they’re currently undertaking a graduate programme where they will work with various technical teams in different disciplines. As a member of the Perl group, I’m obviously hopeful that they’ll enjoy their time using Perl, and that they might be excited enough by using Perl, and the work we do with it, to want to stick with Perl after they finish the graduate scheme.