A Panel Discussion - Collaboration?

We recently developed a structure for evaluating whether an activity was collaborative or not.  The four-step evaluation process is important because the same activity is collaborative in one context and overhead in another.  There are four areas of activities in all software development and maintenance organizations (and I do mean ALL) that are sometimes collaboration and sometimes not, but almost always sold as collaboration.  Today we tackle the first two areas.

Communication:  The exchange of information and ideas is a common activity in almost every human endeavor and is core to collaboration. A friend recently described a monthly meeting at her firm.  In their meeting, each project presents a set of slides and is “grilled” on status. Applying the four-step filter to evaluate an activity we can determine if the communication is part of a collaborative process or whether it is something else.  The filter:

  1. Is there a common goal – Yes, to provide status.  
  2. Is there interaction to create an output – No, nothing is being built or delivered.
  3. Is shared ownership of output – No. Everyone gets to share the pain of the meeting, but that is not really the point. 
  4. Bi-directional communication – Yes (ish), the meeting has time for discussion but most of the data flow are serial one-way statements. 

The “grill” meeting is not collaboration, clearly not all communication is not a collaboration.  An agile planning meeting is another example of a communication platform. Planning meetings in which team members share ideas, fears, risks and ideas for solving a problem are collaborative.  You can answer yes to all four questions in the collaboration evaluation. If, however, the planning session consists of a leader telling team members what they will do and/or how they will do the work, the session is not part of a collaboration.  

Workflow and Organization:  The flow of work through an organization can facilitate or inhibit collaboration.  Late in my senior year of high school and the summer before I went to university, I worked in a tire assembly plant.  In the part of the plant I worked in, tires were assembled, sorted, pressed/cooked, inspected and then shipped. The process was a classic assembly line process.  Applying our four criteria:

  1. Is there a common goal – Yes, to build and ship tires.   
  2. Is there interaction to create an output – No, each step in the process were separate and distinct with little or no interaction except in the lunchroom.
  3. Is shared ownership of output – No, other than the chart in the shower room showing performance against quality goals and days between injuries. 
  4. Bi-directional communication – Nope. 

A classic assembly line is not a collaborative process. The classic waterfall approach to software delivery or software methods in which team members play specific and non-overlapping roles fall prey to the same lack of collaboration. Note: Waterfall methods often added additional steps to create an environment for collaboration. The added steps tended to add cost without a lot of value.  The cross-functional team concept leveraged in most modern agile methods that rely on t-shaped people and swarming would meet all four of our collaboration criteria. Iterfalling (doing sprints but each person has a specific role) would not meet our collaboration criteria.

Logic tells us that all dogs are mammals but not all mammals are dogs.  All collaborative processes include communication and have a workflow but, just like dogs, if we flip the equation not all communication and workflows are collaboration.

The final two areas of activities in all software development and maintenance organizations (and I do mean ALL) will be discussed next.