The Mythical Man-Month is one of those books which everyone who builds and ships software products must read. It was published by a long time, hardcore practitioner Fred Brooks in 1975. That’s old, you think? Surprisingly, a large proportion of the content is still absolutely relevant and worth keeping in mind. And I kid you not, a host of today’s practitioners are still light years behind in understanding some of the fundamentals of software product making that are discussed in this book. Hence with this article, I bring some highlights from the book to the fore. This maybe a refresher for some of you, and revelation for some.
Brooks’ Law : Adding manpower to a late software project makes it later.
This is the very essence of the book! Tell me, how many times have you been in situations where the project timeline has gone for a toss, and some folks start talking about “Let’s add two more people to it”? I am sure a handful of times!
In almost all cases, it would be wiser to trade the scope instead of venturing into more than what you can chew. Or else, you run the risk of compromising timeline or quality. Remember, adding resources will not help you bring a derailed project back on track. Sharper focus will.
That brings us to the next point.
Compromising on timeline : An omelet promised to be delivered in two minutes may appear to be progressing nicely. But when it has not set in two minutes, customer has two choices – wait or eat it raw. Same is the case with software customers.
At times, it would be wiser to compromise on the timeline than change scope. Provided you have been diligent in your prioritization and planning. Let me elaborate. If you have logically grouped the set of features that must go in a release by way of well thought out epics, unlikely that they will be effective without delivering the whole range. Say your project involved key changes in backend IT infrastructure, web application and mobile and Android team failed to turn in their work on time. It would probably be better to extend the timeline from 6 months to 7 months to accommodate mobile team’s release rather than skipping an important feature and pissing your users off for a missing feature on one mobile platform.
Of course there are times when there is a strict deadline, like an upcoming conference where you want to launch or a customer deadline that can’t be changed. In that case, clearly communicate to your team the reason you want to change the scope and get their buy in before you fiddle with it.
That brings us to project delays.
Add little to little, and there will be a huge pile
In many work places, small delays in short term deliverables are not taken seriously. This can have a cascading effect on your entire release. While it is impossible to accurately predict the exact effort needed to complete each task or module, the overall project plan should not be jeopardized due to isolated delays.
To me, the key is to improve the estimates Sprint by Sprint and come to a stage where aggregate project plan becomes more accurate. One approach is to challenge the estimate during planning by suggesting. Be prepared to suggest a way, but be ready to accept another which can do the same.
It is also important that Product Leaders understand what goes into shipping a finished product and not just make a dev estimate. Keep in mind that QA, E2E Testing, Bug Fixing, Documentation, Deployment, Setup, Supporting – all take time. Expect the overall time to be as much as 5-6 times of the dev estimates.
Despite all this work, there will always be things to be discarded.
The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done.
It is important that the team understands the need to discard some of the work done at regular intervals.
If you are a chief builder of any kind in your team, it is your responsibility that experiments are conducted in smaller chunks so that you don’t drop out things in huge chunk which may kill the morale of the team.
This is just a glimpse. You should read it if you haven’t yet. Seriously. Go. Read it!
Thought Farming 