By Kealy Williams, January 17, 2018
We all want to go faster. Get there faster. Get done faster. Get through it faster. Just be faster. Software projects are no different. The deadline is set and then the race is on; hit the milestones, release the beta, get it to the customers.
In 1975, Fred Brooks told the world, “adding manpower to a late software project makes it later.” This is known as Brooks’ law and is penned in his book “The Mythical Man-Month”. He goes on to explain that trying to increase the output of an expanded team is crippled by the “added burden of communication” where “communication is made of two parts, training and intercommunication” [1].
Let’s take a look at intercommunication. If we simply look at how many lines of communication need to occur for every member of the team to talk to every other member of team we can apply a formula.
So, with that a 3-person team has 3 lines of communication, a 4-person team has 6 lines, a 5-person team has 10 lines, and a 10-person team has a whopping 45 lines of communication!
WHAT?! No wonder each member of a team can’t keep up with everything.
I’m guessing that Brooks never imagined a software development environment like we have created at Menlo Innovations. Our developers, (that includes me!), have implemented many if not most of the practices as described by Kent Beck’s Extreme Programming. Of those most important; team co-location, paired programming, test driven development, simple architecture design, and system metaphor. These practices and our culture allow for us to overcome Brooks’ Law and go faster by adding team members.
Yes. Go faster.
To be fair I haven’t defined faster. We can NOT double the team and go twice as fast immediately. That would be a miracle. Personally, I define faster with a simple question; did you get more done? Did you get more done than last week? Than last month? Than last year? But, how do you measure “more”?
For purposes of explaining what I mean by faster let’s measure in story points. (Menlo does not estimate in story points, we use hours. Please read this article to learn more about our time-based system.) Let’s take a team of 2 pairs and double the team to 4 pairs. Assuming the original pairs are at 100% efficiency and producing 400 points worth of stories, when the 4 people are added their efficiency goes down to 60% so they can still produce 480 story points. So, 480 is more than 400 making the team as a whole faster. So now let’s say that same team improves by 5%, the following iteration, they can now produce 520 story points. Again, they are getting more done thus are going faster.
Ok, so how does this happen? Quickly communicating, or intercommunication, as Brooks says, with a large group or team is often difficult, especially if all the team members are not in the same location. Then if you need to add more team members, the communication challenge increases. Traditionally team members might email or instant message one another, but this takes time and might not create a result for days or weeks. However, if a team is co-located and doing paired programming, as in Menlo’s environment, a conversation across the table is all that is needed. If the whole team needs to hear the conversation impromptu meetings or discussions can pop-up as needed. We have even simulated co-location for pair partners that are not in the same state by using screen sharing applications, speakers, and microphones.
Brooks second part of communication, training, typically means stopping a whole team for days at a time to hopefully educate them on a topic or technology in a classroom setting. At Menlo we have built the training directly into the work through paired programming and a culture where its ok to say “I don’t know.” When a new person is brought on to the project it is their partner's job to get them up to speed within the context of their assigned storycard. It is the new person's job to ask questions and facilitate their learning. As the pair works to accomplish their work the training happens on the fly. Most new developers at Menlo can say they were programming in production code within 20 mins of starting on their first day.
So, in the spirit of running the experiment, I encourage you to go faster. Brainstorm what might be slowing you down in the areas of communication and training, then try some experiments to overcome Brooks Law for yourself.
References
[1] See Brooks, Frederick P., Jr., The Mythical Man-Month Essays on Software Engineering Anniversary Edition (Addison Wesley Longman, Inc.: Boston, 1995), 18, 25.