Agile Retrospective – Lessons Learned

MPj04034140000[1]The one phase that is most often neglected in agile development is the retrospective, fulfilling the same role as lessons learned in other methodologies such as Prince2. Only paying lip service to the retrospective will have noticeable effect on the delivery of the project it is in this phase that misunderstandings are outlined and process that have not went well are addressed.

Some Project Managers focus on this in a very structured way moving from one defined stage to the next, I have over time come to believe that a structure is important to focus the meeting but a strict agenda has never really achieved the best results.  What I want to outline are general principles that should be included in any retrospective, remembering that each section will naturally flow together and it is the PM job to bring them back to the necessary stage and maintain relevance and focus.

Lets look at what a retrospective should include:

Review of work completed in the last iteration

Critical to getting an overall understanding of how the project is going, depending on progress it becomes easy to highlight areas where their are issues or hopefully areas where the team (includes the Developers, Project Manager and Customer) are excelling.  It is important that this phase is not about apportioning blame but at looking at the root cause of any issues so that they can be explored in more detail later.

This often highlights areas such as communication issues, over-commitment of work, resource gaps and other areas.

Outlining of personal issues and team issues

Continuing from the previous stage we would discuss any issues that have arisen in more depth, this phase also allows team members to voice concerns and issues, but in most cases to put forward ideas to improve the process. It helps to view these based on their impact and effect on two areas the individual and team.

It may be something as simple as a team member requires more information than they are being given or a team issue to do with the availability of resources. The main benefit of the separation is that it quickly outlines which problems require a localized or individual change and can be dealt with separately from the more global team issues.

Discussion on what worked well

A point ware people discuss the process and situations that worked well see if there is any way to adapt for this to become a embedded part of the process.

Agreement on what is to change

An agreement is made on what to implement from the point raised earlier in the retrospective. In most cases it is easy to reach a consensus on as the team by this stage understand the importance of the points raised. It is at this point that individual issuers are dealt with separately with the main focus being the changes that will most benefit the team collectively.

Plan for implementing changes

Finally a plan is put into place to allow the team to attempt to embedded these changes, this may be a long process or simple someone taking accountability for a individual element or new process.

Although this is a quick and high level outline of the basics of a Agile Retrospective it by no means is inclusive and is set to become the first of set of article dealing with retrospective and lessons learned.


Leave a Reply

Your email address will not be published. Required fields are marked *