|
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 |
|
|
|
|
|
|
|
|
|
|
Reviving, or
reintroducing, 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 and post
implementation reviews (now reinvigorated and elaborated by Norm Kerth as
‘retrospectives’) deserve to be part of the toolkit of every professional
software development team. They act as catalysts for change - transforming
software quality and team performance. Done well technical reviews are the most
effective software quality control, far more effective than testing, but more
than that they: tell
the author about potential improvements that can be incorporated 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) 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
real process improvement happen. Retrospectives are the basic, 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 (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 |
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
© Copyright OSEL 2010 |
|
|