Reviews & Retrospectives 

O X F O R D   S O F T W A R E   E N G I N E E R I N G
C o n s u l t I n g   S o f t w a r e   E n g I n e e r s

Home

 

 

 

 

 

 

 

 

 

 

Get the best from two fundamental software development best practices:

 

 

 

 

 

Everyone knows about technical reviews and post implementation reviews. And everyone knows they could be better. What is not so well understood is how much better they can be, and the remarkable effect this can have.

 

Both technical reviews, which range from traditional walkthroughs, through to the remarkable Fagan Inspections, and post implementation reviews, now reinvigorated and elaborated by Norm Kerth as ‘retrospectives’, deserve to be part of every professional software development team’s toolkit. They act as catalysts for change - transforming team performance and software quality.

 

Done well technical reviews are the most effective software quality control.  With a well documented return on investment of up to 10:1 they are far more effective than testing, but more than that they:

 

- tell the author about potential improvements

- tell developers and others that the item is ready (or not) to be made available for use

- tell team leads and managers that the task to produce the item is complete (or not), triggering earned value recalculation

- reveal novel solutions or design excellence (‘undefects’ or ‘profects’) that can be used elsewhere

- help developers within the team and from other teams to synchronize their work as they share understanding of the progress of work

- help reviewers develop shared appreciation of de facto standards and a good work

- enable less experienced developers or developers new to the organization to learn from the more experienced and experts

- share technical understanding among developers and reduce dependencies and bottlenecks

- provide early and ongoing data about the quality of the systems being developed

- provide data about the process and practices  used to develop the system

 

…which is very good for such an apparently simple practice.

 

In a similar way retrospectives do far more than harvest lessons learned, but they are difficult and need care to get the best from them: a project’s history is more difficult to review that a technical document, the need is often less clear and apparently of little immediate operational value, and much of the feedback can be difficult to capture, diffuse and take longer to have effect.  One commonly heard comment about retrospectives is ”we used to do them once, but nothing much changed so they stopped.”  But, planned carefully, with the right people involved (not necessarily who you think) and with good facilitation they will transform your organization. That’s what they’re for.  They can:

 

- identify development and management opportunities

- reveal what the team really achieved

- capture the learning of the team and project

- repair damage done to the team by the last project

- show that there are solutions to development and management problems, that there are better ways of working…

…and make them happen.

 

In effect making genuine process improvement happen. Retrospectives are the basic and fundamental process improvement tool. If you are interesting in developing your software capability start with these.

 

Few software organizations can claim to get all the benefits from these practices. Often the processes are not fully understood or have degraded to the point were they cannot deliver the results they should, they can be seen as a waste of time (which they are if they’re not working). And even when they are working their benefits can be difficult to evaluate, making them a target for cost cutting and schedule reductions. Measuring effort or time saved can be difficult - but it can be done.

 

We believe these practices are fundamental to good software development and should be used by all development teams what ever development approaches or technologies you use. If you want to get more from these practices we can help you with:

 

- evaluating the effectiveness of your reviews and retrospectives

- providing support to correct failing reviews or retrospectives

- introducing, or reintroducing, them to your organization

- provide independent and objective facilitation (which is critical for retrospectives).

 

 

To find out what reviews and retrospectives are about and how they can improve your teams’ performance, your organization’s development capability and your software quality contact us

 

CCS May 2009, March 2010

 

 

 

 

 

 

 

 

 


Home

 

© Copyright OSEL 2009 - 2010
This page was updated on 22/03/2010
Comments about this website to
info@osel.co.uk