Yesterday, I was having a conversation with a colleague about an issue she was struggling with.  She was describing to me how management sometimes has the notion that if we just double the project, say from 10 people to 20 people, we will get double the output.  In the classic Mythical Man Month by Fred Brooks, he made the bold statement that resources do no combine linearly.  Brooks documented his observation with a formula that describes, in part, how the exponential increase in communication pathways as the team size grows, is responsible for his observation.

     Communication pathways = [n * (n-1)]/2

In my colleague’s example, the number of  communication pathways increase non-linearly from 45 to 190 after the team doubles in size.  Or if you want percentages, changing the team size from 10 to 20 is a 400% increase in communication overhead.  Wow!  I would call that communication overload.

As a response to this observation, Agile teams and projects almost always try to keep the team size around 8 plus or minus 2.  When team sizes exceed this, it is impossible for people to maintain a network of communication links with all the participants.  

OK, mister big shot consultant, how do you deal with big teams of, say, let’s pick a number, a hundred people? My first answer would be to subdivide the hundred people into smaller units each with 6 to 10 people, or create about about 10 to 12 teams.  Of course, now you have the added difficulty of coordinating that many teams, but no one said management was easy.  However, would you rather coordinate 55 communication pathways between 11 teams or 4950 communication pathways between a 100 individuals?

My colleague, Mike Sutton at Wizewerx pointed this out on his blog.  It was just too over the top not to link it myself.

On a more serious note, this parody illustrates how easily it is for leadership to become disconnected from the people doing the actual work.  Communication is one of the central values of XP and Scrum and is necessary for feedback (another key value of XP).  Having a daily stand-up meeting is worthless unless pertinent, relevant and timely information is communicated so leaders can make adjustments.  Waiting until you are in the bunker is the wrong time to tell your leader you haven’t been running the unit tests or the build is flakey.  When you are in a hole this bad, expect sparks to fly.

I finally got a chance to listen to Software Engineering Radio’s podcast of Linda Rising about retrospectives after it was recommended by a friend.  If you facilitate retrospectives and have not listened to Linda’s interview, make the time to listen to this podcast.  It is full of interesting tips, tricks and techniques.  Linda made a comment about halfway though her interview which resonated with me and I wanted to share it with you since it helps explain my motivation to work with software teams and why I am passionate about Agile software development.  

During the interview Linda said, and I am paraphrasing here, that retrospectives are a way for people to break free from their old behaviors and become the people they want to be at work.  So many times in our careers, we play this role that is assigned to us by our peers or management.  Or we perform this role out of some misguided habit, even if it is not helping us.  In Linda’s opinion, through the ritual of a retrospective, we are given the opportunity to pause, reflect and decide what behaviors we want to take forward with us.  In this way, a retrospective can be both transformative to the individuals and by allowing the people to change, the organization is redefined by the actions of the reenergized individuals

This is one of the reasons of why I am a consultant – I want to give people the opportunity to be the person they want to be at work.   So often in our careers we are chained to our past behaviors and decisions we feel we cannot escape them.  However, I feel the only thing holding us back from change at our workplace is accepting that all the authority and power to change resides in us, we just have to choose it.  We don’t need our manager’s permission to change our attitude or start being helpful.  We just have to want the change and recognize change starts with us.  We just have to decide that we don’t want to carry around all those chains and links to the past.

When this is the case, then role of someone like me is to buy enough space for people to feel secure enough to take the first steps.  Most of the business and technical practices I recommend are about creating safety, trust and breathing room so the organization can be transformed not by me, but by the participants.  Now that is powerful!