Home | Login | Recent Changes | Search | All Pages | Help

SomeoneElseSignsOff

I have a somewhat naive, and very unoriginal idea about managing projects.

What if, for every tracked task assigned to a single person, the task could not be marked complete until someone else signed off. (for tasks assigned to a group, maybe someone outside the group could sign off)

In other words, you weren't done until you could find someone to vouch for the fact that you were done.

How would that work? Has anyone tried it or something like it? I've seen it with code reviews and approvals for code check-ins, but could it be expanded to each and every taskbox on the project plan?

--DaveLiebreich 2003.09.21

Let's think about why do we want these sign-offs: to find mistakes before the task is "finished", perhaps?

• What if the coder/designer did code reviews while we're writing the code? And swapper reviewers/coders often?
  
  
• what if the coder/designer wrote a little unit test, and then the code to pass the test, until the code does everything we need to do, nothing else, and every line of code is tested?
  
  
• what if the person (GoalOwner) who knows the requirements, possibly with the aid of testers and programmers, wrote the tests for a requirement before the code is implemented... and coding for that requirement is not finished until the tests pass and the GoalOwner is satisfied.
  
  
• what if the GoalOwner was available for questions about the requirements while the coding was being done?
  
  
• what if the code was built and integrated at least daily, all tests passing?
  
  
• what if anyone on the team could fix problems or do enhancements to any code in the system, as long as it was reviewed and all tests continue to pass?

These and other practices have actually been tried, in combination. Several teams that have done this have said that their defect rates dropped from 100's a month to around 1 or 2 a month?

See ExtremeProgramming for more information.

KeithRay 2003.09.21

Has anyone tried it or something like it?

Yes, of course. When I manage teams or projects I have two questions about any important deliverable:

• Has someone else looked at this?
• What does the user (customer) think of the results?

I apply this to any deliverable that will have to stand on it's own, with out the originator there to help out. By this definition, code is always important.

I wish I could claim credit for some kind of brilliant insight here, maybe even go declare a methodology and coin an acronym. I can't. Way, way back in the day, I had found talking about hard coding problems with peers to be useful, had really hated inheriting cruft with no context, and tripped over a module header format. So I was a bit biased toward the idea that how we go about making code matters in the kind of code we get when I read somewhere that peer reviews of some kind were the single highest impact process change in software development - productivity and quality. Then I found a book on that stuff, and tried it. The rest, they say, is history.

There's more to a "sign off" and a "hand off" than to a simple peer review, however that peer review gets named. There's value in a producer / consumer handshake, declaring satisfaction. I like making opportunities for lots of little victory dances. Coding can be frustrating. Some other activities in building systems can be more frustrating. Celebrations along the way are good reminders of progress. If creating opportunities for these celebrations, and for people to appreciate each other ("Thank you for this fine hunk of code." "Well, thank you for the chance to make something of use and value to you.") creates some kind of quality control effect on the deliverable, that's good to.

-- JimBullock 2003.09.21

When looking at enhancing (i.e., defining) their development process, we simply took the above, entering each requirement into the tool, and handling it in much the same way. This covered everything from requirements analysis through UAT. Since in the development environment physical passing of the folders was not practical (teams spread all over the place), the tool was used exclusively to sign-off and reassign, but since the process was well understood by then, this worked fine. The tool-assigned IDs were used to identify each requirement, and trace status throughout the project (these IDs were also carried on the project schedule, with WBS created for each accordingly).

Note, the process existed before the tool, but the tool made the process easier to implement. Sign-off was required for each phase, and all pertinent information was available (either in the folder, or in the tool) to verify that all was well...or otherwise. Even by the time the group was well on the way to CMM level 4, this basic process was still in place and working a treat.

RobWyatt 2003.9.22

Nice story, Rob.

I have never really understood how requirements and defects so often manage to have different production processes associated with them. I have thought for the longest time (meaning I can't remember when I didn't) that even green field development, that started with imagined requirements and no system in use, could reasonably handle defect repair with the same production process as addressing new requirements. There are, perhaps two process differences between defects and new requirements:

• A defect always exists in the context of a current system.
• A defect reflects a current commitment. A new requirement does not.

The relatively new defect tool from Fog Creak Software explicitly treats defects and new features as instances of the same kind of object. I think that fits. At least that's the way I've always handled things, with varying degrees of translation for incorrect methodologies and policies that I couldn't avoid.

-- JimBullock 2003.09.22