The Mythical Man-Month Is Not A Myth

Brooks’ law is a principle in software development which says that “adding manpower to a late software project makes it later”.  It was coined by Fred Brooks in his well renowed 1975 book The Mythical Man-Month.

There was a recent project where unrealistic timelines were imposed on a team and the project was running late largely due to the Cone of Uncertainty – commitments were made early when least was known.  The team estimated the project would complete in 12 months. However, the project needed to be complete much earlier than that.  As a result, the project showed all the symptoms of a “death march” from day one – desperate attempts to right the course of the project by asking team members to work especially grueling hours, weekends (and public holidays), often causing burnout and by attempting to throw (enough) bodies at the problem with indifferent results.   Interestingly, the project was still delivered in 12 months despite all the overtime and adding more resources.

As an observer from the outside, it amazes me how many people overlook the negative productivity impact of actually adding more resources.  On face value, we seem to think if we double the team size it will simply mean we would double the workload of the team.

In reality, it takes some time for the people added to a project to become productive. Brooks calls this the “ramp up” time.  Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them.  This education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully.  Each new worker also needs to integrate with a team composed of multiple engineers who must educate the new worker in their area of expertise in the code base, day by day.

In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even have negative contributions – for example, if they introduce bugs that move the project further from completion.

Communication overheads increase as the number of people increases.  The number of different communication channels increases along with the square of the number of people; doubling the number of people results in four times as many different conversations. Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.

To reduce cost on the project, a significant number of resources were obtained from an offshore location which made things more complicated and accentuated the above issues. Due to reduced communication bandwidth, collaboration was even lower with the offshore team.

A senior external  consultant was bought in to help the team with some new technology.  He commended  the (original) team about the high quality code which enabled him to do his work effectively and to extend and maintain the code with low cost.  However, all the hard work the team originally put in that resulted in high quality and clean code were being lost with the addition of the new resources.  The need for new resources to be coding from day one resulted in poor quality output.  Not only did this result in increased defects, but also increased integration issues.

In my blog Don’t rely on overtime to salvage a plan last month I wrote about avoiding daily or frequent overtime as it affects efficiency, productivity, morale and quality.  Asking the team for mandatory overtime is a symptom of a serious problem on a project and does not address the root cause.  Don’t get me wrong, you can work some short and specific overtime and this can often help get the project out of a tight spot. However, if you come into work frequently and say –

“To meet our goals, we’ll have to work late again”, then you already have a problem that can’t be solved by working more hours”. (Beck, 2004)

So with constantly increasing scope but with a unrealistic fixed schedule, quality was being impacted.  Corners that were cut due to unrealistic pressures imposed on the team and excessive overtime came back to haunt the team later.  They were finding or making more bugs than before resulting in more delays and greater integration issues due to poor quality of work being provided by the offshore team.

Overtime just doesn’t yield the results promised by Gannt Charts which provide an oversimplified view of the software development process by only measuring the quantity of the hours spent on tasks without also taking into consideration the quality of the time (yes there is a difference).

Sometimes the biggest gains in productivity come from stopping to think about what you’re doing, why you’re doing it, and whether it’s a good idea. We need to work smarter, not harder and have the ability to hear unwelcome news and then address the real issues.

When trying to add new team members to address a tactical and fire-fighting need, we need to realize that an incremental person who, when added to a project makes it take more, not less time – nine women cannot make a baby in one month.

IT is never 100 percent at fault for any massive project

If you read my previous blog post on Executive Support For Agile Adoption, I described how management support is important.

This topic is tocuhed on in Thomas Wailgum’s recent article in the CIO.com [5 Aug 2009], After a Massive Tech Project Failure: What IT Can Expect.  In his article he states –

IT is never 100 percent at fault for any massive project

Thomas’ statement is supported by the Chaos Report by The Standish Group whereby the top 10 reasons for project failures have nothing to do with Technology but more to do with business governance –

1. Incomplete Requirements
2. Lack of User Involvement
3. Lack of Resources
4. Unrealistic Expectations
5. Lack of Executive Support
6. Changing Requirements & Specifications
7. Lack of Planning
8. Didn’t Need It Any Longer
9. Lack of IT Management
10. Technology Illiteracy

Furthermore, the Chaos Report indicates that the three major reasons that a project will succeed are user involvement, executive management support, and a clear statement of requirements.  There are other success criteria,  but with these three elements in place, the chances of success are much greater.

Thomas’ article is not advocating agile (the word is only mentioned once).  What is mentioned is a common theme – be pragmatic, provide common sense and be practical.  Agile is pragmatic, common sense and practical.  And the first step to adopting agile is to have an open mind to it.  You can be skeptical about Agile, but remain open-minded.

CIOs who resist against changing implementation methods—holding firmly to the waterfall when agile is the best option—and killing projects and their careers

The advice for such massive undertakings, which CIOs and analysts talk up but many don’t follow, is practical: Think bite-sized project chunks and set proper expectations.

“For some reason,” he adds, “we haven’t learned as an IT industry about driving incremental planning and change, which, in my mind, would help to mitigate the high rises and high falls of project failures.”

Agile is about incremental planning and change. For example, Scrum is an Empirical Process Control whereby you exercise control through frequent inspection and adaptation. The idea is that you do some planning and then do what you planned, inspect what you did and then adapt your behaviour to improve on what you did. You are constantly going through cycles of learning and improving the way you work.

As part of this learning, we need to encourage our managers to –

embrace change and transparency—even if it hurts at first. “The corporate culture—the status quo—tends to be: ‘Everything’s good. We don’t talk about problems until they are near unrecoverable, because we know people don’t like bad news,'” ….. But there are always going to be problems—vendor issues, or architecture, compliance or performance problems.

Agile provides the framework to detect bad news early.  However, as mentioned in my last blog entry “managers need the ability to hear unwelcome news and should it occur deal with this effectively” as IT is never 100 percent at fault.

Like any illness, the earlier the detection the better as a cure can be found and applied sooner.  Leave it too late and the illness can be fatal and you inevitably end up doing the Death March.