Adding people to a project

I don’t align with Fred Brooks’ Mythical Man-Month, and certainly not with his law, “Adding people to a late project only makes the project later”.

I asked Jeff Sutherland about it at our Agile Consortium Belgium in April 2010. Jeff demonstrated with data from major projects that Brooks’ law is plain wrong, that adding people can positively affect productivity.

In September 2010 I checked it with David J Anderson at a Kanban training I followed. He went through the roof because of such ‘laws’ that haunt our profession and also had the data to disprove Brooks’ law.

Well-oiled Agile Teams take in new Team members without a productivity relapse. Thanks to iterative-incremental processes and technical practices like Test-Driven Development, Pair Programming and automated integration and regression testing (aka ‘Continuous Integration’).

Proven experience

Beyond my personal conviction I then realized I’ve proved it myself. At an atom sized scale compared to Jeff or David J, but still…

My Team was responsible for the core (Java) application of a large media platform (digital tv), centralizing business logic and system interfaces. A major new Release was to be developed from October to December 2004. Our pre-game investigation had turned out this to be feasible.

Despite frequent reminders, important prerequisites were not met, limiting our Velocity. Beginning of December I announced an extra Sprint (January 2005). Unhappy and angry customer. Although settlement of our needs was still too late I didn’t want to be the showstopper again. And decided to add people… shown in this weekly chart:

But… productivity increased and we finished in time, as is shown on our Product Burndown chart:

Looking back, all parties around the table in December must have been very happy with ‘our’ delay. Because we were the only ones that delivered end of January… Customer happy. With a great recommendation.