Copyright 2009 Corvus International Inc.  All Rights Reserved

Home      About Corvus       Contact Us       Articles/Resources       Clients          Affiliations  

The shoe that fits one person pinches another; 
there is no recipe for living that suits all cases.


Carl Gustav Jung,
Swiss Psychiatrist (1875 - 1961)

ACM DL Author-ize serviceThe business of software: Matching process to types of teams
Phillip G. Armour
Communications of the ACM, 2001


One size does not fit all...

In software development, we attempt to apply the same process to
different teams, doing different work, under different conditions

There are four different types of teams:

We can map these onto the Five Orders of Ignorance.  

Type of Team           0OI 1OI 2OI 3OI

Tactical teams...

are dealing with known quantities.  Their job is to execute what they know.  They deal with Zeroth Order Ignorance (see here) almost entirely implementing existing and known knowledge.  A good example of this kind of team would be the flight deck operations on an aircraft carrier. for this kind of team, being creative might be deadly--the ideal situation is that everything runs like clockwork, and there are no surprises.  The key elements to get right on these teams are: roles, responsibilities, and process (which must be very well defined and possibly even automated)

Problem-Solving teams...

deal with a lot of known quantities (for instance, they at least know there is a problem), but also with some unknowns.  These teams cannot have quite the degree of definition of process and roles that tactical teams must, since pursuing the answers to the problems, will often uncover unknowns that change the nature of the process.  So they deal with some Zeroth Order Ignorance (the application of known knowledge) and some First Order Ignorance (obtaining the answer to known questions).  An example of this kind of team might be a support or help-desk group.  Most of the time, they may have the answer.  On those occasions when they don't have the answer, they usually have a well-defined process for getting one.  Occasionally, they may encounter a situation where their defined process doesn't work, and they have to change it.  The key element to get right on a problem-solving team is trust.  The reason is that each member of the team must trust that the other members of the team will do what they must to achieve success.  A good example of this kind of team would be a fire-fighting team.

Creative teams...

require a lot more freedom of process.  The reason is simple: they are creating something that may not have been created before.  Therefore, the process for creating it, may not be well-defined.  Why?  Well, the simplest statement is from the Second Law of Software Process which asserts that you can't have a process for something you don't know how to do.  Therefore a creative team deals with some First Order Ignorance (resolving the issues they know they don't know) and some Second Order Ignorance ("discovering" the knowledge they didn't know).  The application of any process tends to limit options--that is its purpose--which is not effective if it limits the discovery of the most optimal answer.  The most important element for the creative team is freedom.  The team must be sufficiently free of the strictures and constraints of the existing organizational process to seek out new, more effective, more creative, processes.

Learning teams...

require more freedom yet.  The goal of this kind of team is often to break new ground, for explore in regions that other teams have never been.  Obviously, the process must be very unconstrained.  In fact, the output of such a team is often not a product, but a process--a better idea of what kind of process might work.  These teams are operating at Second Order and Third Order Ignorance levels.   The key requirement for these kinds of teams is shared mental models of the task/process at hand.  The team is trying to construct a consistent way of understanding something, and their ability to mesh their thinking processes is the most critical element.  Process definition in advance of the task may be entirely absent for this kind of team, and the early stages of work are the definition of what is essentially a boot-strap process to get the activity moving.

The challenge for software teams is that they are all of the above.  Sometimes a team is creative in requirements gathering and tactical in implementation, problem solving in testing and learning in architectural design.

How can teams function effectively across this wide range of styles?  Well, they must if they are to be successful.  Helping technical teams do this one of the most important things a manager and an organization can do.  


Matching Process to the Type of Team...