Joe Little does a marvelous job recruiting speakers for the Agile-Carolinas meetings. This month was no exception. Israel Gat from BMC Software discussed “Leading the Disruption”. This presentation focused on releases 2.3 and 2.4 of their distributed system management software. Near the presentation’s end Brooks’ Law was mentioned and the question posed, “Does Brooks’ Law still apply?”
Why is it so?
Jerry (Gerald M.) Weinberg chose to use Brook’s Law in Quality Software Management: Vol 1. Systems Thinking to demonstrate non-linear feedback systems. Combining Fig 5-1 (page 78) and Fig 6-4 (page 93) gives us:
Brooks' Law
I describe how to read Diagram of Effects here.
In essence adding manpower affects the system by:
- Creating more communication paths. The number of communication paths is (n*(n-1))/2 where n equals the number of team members. This says increasing from 4 to 6 members increases communication paths from 6 to 15.
- Adding new team members creates a training load on the existing team members. This in turn reduces the productive work finished.
These problems get exacerbated when managers decide to add “extra” manpower just to be sure the project doesn’t slip any more.
Communications and Sharing Information
Tools to support software development methods have changed since Brooks’ Law was introduced. We now have information radiators for sharing information in parallel. By simply walking around your office it’s possible to learn information about the project. Additionally wikis, build systems, source code management are types of information magnets. They hold pertinent information that can be searched, sorted and reviewed.
There’s a sliding window of opportunity where manpower can be added to a project and not negatively impact the schedule. This window closes when the additional productivity achieved by adding more staff isn’t enough to offset the lost production due to training them. According to Israel Gat, BMC Software staffed the two releases with 80-95 developers compared to other companies who staffed similar sized projects with 25-35 developers. This staffing level resulted in product delivery in 4.5 – 5 months instead of over a year. This rapid delivery creates problems for the downstream organizational activities such as marketing, sales, revenue recognition and the back office. BMC Software recognizes this problem and is currently working on synchronizing the activities.
How to Beat Brooks’ Law
The state that invokes Brooks’ Law is “late”. To beat Brooks’ Law all you have to do is avoid having late projects. What are some ways to avoid late projects?
- Staffing – BMC Software avoided late project delivery by aggressively staffing when they started the project.
- Cross functional teams – This keeps the project delivery from being derailed when something happens to a “key” developer.
- Incremental and iterative development – Customers rarely need all the new functionality at once. Delivering the highest value functions sooner relieves the pressure for a “big bang” delivery. The customer can decide to stop the project early if/when their needs get met.
- Fast feedback – This naturally flows from incremental and iterative development. Every two to four weeks the customer provides information on how well the development is doing at meeting the customer’s needs.
- Continuous Improvement – At the end of each delivery cycle, set aside time to learn from the cycle’s activities and events. What went well? What could be improved? Select something from the “What could be improved” list and work on it the next delivery cycle. Be sure to ask at the end, “Did we implement the improvement?” Some things take more than a single delivery cycle to get right.