Rarely do even Big Ideas emerge any 
longer from the solitary labors of genius.

        Robert Reich: Tales of America 1987

 

 

 

There are two components to projects:

• The Mechanism of the Project--such as the processes, procedures, tools, 
  organization chart, task assignments, methodologies, languages, etc.  These 
  are the "static" or mechanical components of the projects.  They are also the 
  usual target of "process initiatives"
   

• The Organism of the Project--the people, how they think and feel, what 
  motivates or demotivates them how they work together (or not, sometimes)

 

I contend that most of our attention in software process is focused on the Mechanism components. 
I think this focus is mistaken, and does not produce the highest returns on effort. 

In this article, I identify a list of considerations we must bear in mind as we create software teams.  They are:

•  Relatively low social need on the part of the developers

•  General lack of team training in their background

•  Differences in mental models and cognitive processes, which results in differences in system understanding and solution (which is the whole purpose of systems development)

•  Difficulties and lack of training in human-human communication (which is a tad ironic given that many software developers are extensively trained in machine-machine communication)

•  The fact that people are different, and software developers are not trained to recognize, understand, and work with different kinds of people

I also identify what we need to do to effectively build teams.  These processes and functions are, incidentally, built into all our technical team development programs.  They are:

•  Participate in only one (real) team--limit the investment energy to where it really counts

•  Create a shared goal set--consisting of to need to be fulfilled, the vision of the solution and the process to arrive at the solution

•  Develop a common language--and this is not just a programming language, but includes dialects for technical problems, customer interaction, team communication, decision making, and many others

•  Co-locate--if it is at all possible.  Consciously adjust behavior (languages, decision mechanisms, etc, if it is not possible)

•  Experience a collective discomfort--but do it in a controlled way

•  Experience some success(es)--that are directly attributable to successful team operation

•  Develop shared leadership capability--across the team

•  Talk it up--"brag" on yourselves.  Let yourselves, and others know what you are doing, how you are learning, and how you are being successful

•  Ask for what you need--from the organization in terms of resources, influence, and authority

•  Make sure you profit--from a successful result, both as individuals and as a team

This list is taken from our proven model of team development (the "Five P's") that is a feature of many of our technical team programs.  Several thousand software developers have benefited from these programs and have achieved stunning productivity improvements.  

If you are interested, please contact me and I will help you conduct an analysis of your team based on this model.

 

The Organism and Mechanism of Projects