Wednesday, May 18, 2011

In praise of Micro-Reviews

SFBayAreaMicrobeers

The test plan was a work of art.

One hundred and twenty eight and three quarter pages of sheer brilliance.

It started with the IEEE standard and then added two bedrooms and an extra bathroom. Functional tests, stress tests, usability tests. Server backend and client frontend. Risks and mitigation strategies. Network diagrams and functional decompositions. Cross references to the functional specs, design specs, and even the team member's dietary requirements. Weeks of investigation and writing.

We proof-read it, revised it, formatted it, reformatted it, and sent it out to the entire project team for their review and feedback. And, because we knew that everyone already had a heavy workload, we allowed a full 48 hours for their review.

With as much pride in our workmanship as a ship builder, we sent it out for review and waited for the glowing reviews.

After 48 hours we received......nothing.

We decided that given the size and complexity of the plan that we would give people more time. So, we sent out an email to the entire project team and asked everyone to review the plan in 24 hours.

24 hours later we received......nothing.  

At this point, since the wholesale approach wasn't getting us anywhere, I decided to talk to one of the reviewers on a retail level. I tracked down Zyg, a senior member of the team and asked him why he hadn't reviewed the plan. His response was:

"Dude. I don't have time to read Charlie Sheen's tweets and you sent me a novel. It's like I ordered a glass of beer and you ran me over with a truck of Budweiser."

At that point, we still felt like shipbuilders, but of the Titanic.

Then, he offered an interesting deal. He said:

"Look, I'll try to help. I don't touch the GUIs, but I'll review the section that covers my server side code, so we can both get something out of it. I'll tell you where your tests suck, and maybe we can pre-empt you QE guys logging a hundred bugs where my code sucks. OK - how long is the section in that monster you wrote on my part of the code?"

So there it was. The answer was micro-reviewing.

Our goal was to collect technical information from people who were the subject matter experts for a variety of technical areas. So, why not let them focus their energies on those areas in which they were the experts? And, not burden them with having to read and review the entire work?

To be sure, this was not a perfect solution, as we still wanted input from people on the entire plan, that is, on the overall strategy and how the tests all fit together. But for that higher level view we could concentrate on the team leads and managers. And we could still divide and conquer, as we would now have review coverage for most of the discrete functional areas, thanks to our micro-review approach.

OK. That problem's solved. Now I own Zyg lunch...at the local microbrewery. 

(This is a somewhat fictionalized story - Zyg really does exist, but not in software development, dude.)