One aspect of our process that is more on the Plan Driven end of our Agile / Plan Driven scale (see Agile AND Plan Driven) is our documentation and review process for requirements, design, threat modeling, and other non-code artifacts.  Being a large team, we need ways to communicate and get feedback from individuals and teams that are not co-located.  This leads us to a heavier review process than what a small, Agile team could utilize.  We try to document ‘just enough’, but we have to do a fair amount to be successful.

But we also can get carried away with what I call ‘on paper’ collaboration.  For example, a developer has the task of doing some design work for a subsystem that is to be used by another team within MBF.   His input is a scenario and a short list of requirements.  Here’s an approach that he might take:

• Consulting with a couple people on the team, he industriously sets out to write a document describing the design with a class diagram and high level API description.
• Twenty pages and three days later, he sends it out in e-mail for internal review with the immediate team. 
• Two days later, the individuals on the team provide him some feedback.  Changes are needed, so he updates the document.
• The document is sent out for internal review again, but only one day is required for turnaround.  It is internally blessed.
• The document is then sent to the other internal team that is the primary customer of this subsystem. 
• Three days later, feedback is returned (the other team is busy, after all).  It turns out that the design partially hit the mark.  But more changes are required.
• Two more days pass for another iteration and review of the document.

How much time has passed to do this ‘on paper’ collaboration?  In my scenario, it took roughly 10 working days to get an agreed upon API and design for this work.  We are currently working on a 7 week development cycle for our milestone.  Taking 2 of 7 weeks to sort this out is pretty expensive.

A better approach is to collaborate in person and then follow up with a document summarizing the collaboration.  Taking this approach for the design task, it might look like the following:

• After a half day of consideration, the developer calls a meeting with all interested parties to discuss the API and the design.  The customer team is represented in the meeting.
• The group meets for an hour to white board (physically or virtually) the design and discuss issues with the API.   The group generally agrees with the approach.
• The developer then writes the document that further describes the design and the API.  He is able to write it more quickly due to the fact that more brain power was applied to the problem and because the audience for the document now has more information about the problem. 
• Two days later, the document is sent out for final review.
• One day later, the original group meets to finalize the design and API. 

By using ‘in person’ collaboration, the developer should be able to deliver the documented design in less than half the time of ‘on paper’ collaboration.  While in person collaboration may require more meeting time, the feedback loop is much tighter and corrections are made earlier in the cycle. 

In summary, we need to evaluate how to make all of our processes as lean as we possibly can.  Using the highest bandwidth communication approach available is one way to put a process on a diet.