We just finished conducting a short course on product reviews, inspections and walkthroughs. A very interesting question was asked about the “quality fade” effect on reviews.
This is a summary of how we responded:
After peer reviews, inspections, walkthroughs (and various other types of review) have been in place for some time (generally more than a year) their effectiveness tends to wane. (a similar effect has been recently written about quality fade in factories)
Reviews can be a funny type of beast – they are the bane of many developers’ existence and a useful tool for others. They are a vital weapon in our arsenal to fight poor quality systems. Yet they are seen as a “nice to have” or “old fashioned” by many software engineering organisations. Management love them because they don’t think they cost much (though they often do but make up for it later) and because they give management insight into development capability (and lack thereof). They can also easily be misused e.g. to highlight and embarrass specific developers.
A counter to this if your management team wants to use them like this is to make it well known that if peer reviews are the only place that we can identify poor performers, then it’s pretty obvious management don’t have very use oversight of the development process.
But back to the relevance of reviews. They are good for:
Identifying defects
Identified improvements
Communicating scope and issues between team members and others
Building organizational capability and insight
Training new staff in domain and process expectations
Enable authors to gain different perspectives
Enable corporate knowledge to be captured and built into checklists
It is this last point in which a key mistake is often made. If the checklists are used, they need to be up to date. Without periodic improvement than can be seen as outdated, irrelevant, and time wasters.
Someone needs to be made responsible for making the checklists readily available and then updating (even if infrequently) the checklists and data used for peer reviews.
As I mentioned last time, reviews need preventive maintenance to ensure they remain effective and useful to the business. By setting someone as responsible for the review improvement action, you can eliminate the problem of everyone caring, no one doing.
One of the most important activities is to hold a Root-Cause workshop to get at the underlying issues. Be sure to invite both review enthusiasts and adversaries. By facilitating a constructive session to identify and understand what they think and their perspective, you can get the issues out on the table.
Rather than just a whinge session, you can establish ideas and actions on how review effectiveness could be improved. Prepare an action plan out of the workshop – for further investigation of issues and/or potential solutions.
Some underlying problems might be:
New staff are not adequately trained
Checklists and used but never updated
Time to conduct reviews and followup are no longer included in estimates of development
People are now simply too familiar with reviews and are just going through the motions.
Points-of-view or perspectives are no longer used effectively and everyone just focuses on finding spelling areas
Staff don’t know why data is collected and are running informal sessions at their desks
Staff perceive it takes too long for little benefit.
Once you have developed a plan forward, hold a rebaselining session. This is where you let everyone know of the refocus on reviews and what it means to them.
Show the team members some of the statistics – declining defect rate, increasing functionality delivered, reducing cycle time to customer delivery – this should be readily available to everyone – on the noticeboard or wiki/internal website if the company culture is suited to it. Get a clear assessment of what team members feel could be improved and obtain a commitment from everyone e.g. part of their monthly/quarterly/annual goals/KPIs?
By building the renewed focus, you can capture team members’ attention and build on it for future improvements. Some other ideas could be:
Can we automate the process? E.g. collection and calculation of defects, stats, status
Use a data projector and PC to review in real-time
Use a workflow system to gather comments - this also ensures reviewers actually read the document/code before the meeting
What to do with telecommuting, geographically dispersed, outsourced reviewers?
Can you use Online/net meeting
Remember, these are just tools that will help your reviewers – tools will not solve problems such as lack of motivation – people might get excited for a time, but they’ll then revert to their original behavior. It is critical to get to their behavior so change will be enduring.
コメント