Retrospectives What are they and how do they help teams adopt Agile practices?

Retrospectives – “What purpose do they server?”

Many small to medium size projects teams have successfully adopted agile practices such as Scrum but some agile teams do fail.  Often as not they fail because of factors outside their control but here are some common reasons why agile project teams fail that are within their control:

• Not implementing the whole process
• Scaling Factors not addressed
• Team not co-located or team governed like a Waterfall project)
• Team too big or team has strong functional role boundaries
• Team / Management not committed to Agile principles
• Roles not followed (Organization compromise on the Product Owner / Scrum Master responsibilities)

When we look at the Principles behind the Agile Manifesto we find that the first principle is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable

So a failure in the context of an agile project could be stated as an “unsatisfied customer due to late or sporadic delivery of valueless software”.

But Agile provides teams with the opportunity inspects and adapt the process to make changes that help overcome these changes. In Agile a Retrospective is used to help teams improve their processes and practices. Similar to a postmortem performed atthe end of a traditional project, retrospectives allow teams to quickly identify things

• They are doing well;
• They should improve; and
• Outside their control but are risks to the overall project

Here are some some practical tips and tricks for conducting an effective Retrospective along with some best practices for using Rational Team Concert to collect, manage and communicate the impact of the teams improvement activities.

Retrospective help teams improve and holding them at the end of each iteration has several advantages

• Standing meeting focused on improving team performance (every 2 to 4 weeks) at the end of each iteration or sprint
• Team prioritizes improvements and takes ownership over making changes
• Team knows where they stand. Retrospectives occur right after Sprint Demo so they have the feedback from the Prod Owner
• Quick-wins can easily be implemented rapidly where with traditional post-mortems happened at the end of the project with limited ability to make real changes.

Common issues that come up during team retrospectives include:

• Story estimates are not acturate
• Some members of the team are being pulled into other projects limiting their time
• Team missed Sprint due to resource issues
  • Team had several tasks (e.g., DBA tasks) that only one person on the team can perform.
  • During the sprint that resource worked very long hours to complete his tasks and became frustrated that other team members could not do more to help with those tasks.
• In another case say a team has was spending too much time dealing with failed builds. That team decided to implement continuous integration but the team does not want to risk disrupting their regular build process.