Archive for May, 2009
-
Why I Encourage Small Teams
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?
-
Hitler Loses It
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.
-
Why Do I Do This Stuff?
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!
Frequent Topics
Agile Agile SD Certified ScrumMaster Coaching Collaboration Communication Conferences Daily Scrum Design Excellence Design for Six Sigma Extreme Programming Games Innovation Games Lean Legacy Code Links of the Week Measures Movies Pair Programming Personal Planning PMI Practices Presentations Product Owner Quality Refactoring Retrospectives Rugby Scrum ScrumMaster SIMSOC Spain Team Test-Driven Development Testing Tools Training Transitions Travel Voice of the Customer
Calendar
Recent Comments
- Kenneth van Rumste on Scrum Roles Defined
- Carlton on Scrum Roles Defined
- Kenneth van Rumste on Scrum Roles Defined
User Groups
Archives
- May 2011 (1)
- February 2011 (1)
- January 2011 (5)
- November 2010 (3)
- October 2010 (6)
- September 2010 (5)
- August 2010 (4)
- July 2010 (6)
- June 2010 (2)
- May 2010 (2)
- April 2010 (5)
- March 2010 (3)
- February 2010 (5)
- January 2010 (7)
- December 2009 (8)
- November 2009 (2)
- October 2009 (6)
- September 2009 (9)
- August 2009 (7)
- July 2009 (4)
- June 2009 (3)
- May 2009 (3)
- April 2009 (5)
- March 2009 (6)
- February 2009 (6)
- January 2009 (7)
- December 2008 (10)
- November 2008 (11)
- October 2008 (10)
- September 2008 (4)
- August 2008 (5)
- July 2008 (5)
- June 2008 (8)
- May 2008 (5)
- April 2008 (3)


