I very much appreciated the concept back in my JAPH days. Shortly after starting as head of software engineering (for a Rails shop), I introduced the role of Iteration Pumpking.
The Iteration PumpkingAs Pumpking, one developer is given responsibility for the overall quality of the iteration. The Pumpking is expected to comment on any suspect commits (e.g. violations of coding standards, poor coding practices, missing tests). The Pumpking has complete authority to re-open tickets as they see fit. The Pumpking calls for code review where appropriate.
The most important result of the Pumpking role is that overall code quality has improved simply because everyone knows that all commits are being reviewed. It is human nature to try a little harder when you know that others will be reviewing your work.
Another important aspect of the role is that any developer can (and is expected to) serve as Pumpking. Each Pumpking brings a different point of view. A change in perspective always helps the code and the individuals being reviewed.
Serving as Pumpking is especially beneficial in improving the skills of weaker coders. An iteration might suffer for keen reviews with a weak Pumpking, but not nearly as much as having an NNPP actively committing code changes. Weak Pumpkings are forced to step back from their normal practices and examine, with a critical eye, the work of others.
The Pumpking role evolved rather nicely. As is always best when trying something like this, the initial scope of the role was left vague. With each subsequent Pumpking, the role grew more defined. At some point, someone even developed tools to facilitate the role. The team, one at a time, grew the role to best meet its own needs.
I do wonder about trying this with teams of weaker developers. To be sure, there were some weak team members in my group, but the team as a whole skewed toward the proficient portion of the expertise spectrum. Something to consider in the future.