But 9 women can’t make a baby in 1 month. Despite popular belief, there isn’t a direct relationship between coder-headcount and productivity. Developing software is a creative and often complex process. It’s not data entry.
The other day Gus was asked by a very senior executive why his team of 16 people were far more productive than another team of 150. Both teams work at the same company. The short answer is the larger team is following a waterfall approach in a bureaucratic and political environment, while the smaller team has achieved agility in an organisation enclave. Process has a lot to do with productivity. Ironically many processes, apparently designed to increase productivity, are actually impediments to throughput. They’re more concerned with putting ticks in boxes and producing intermediate artefacts than they are about delivering business value with production quality software.
Jeremy Miller lists many of the scenarios that slow down a traditional team using waterfall:
- Waiting for missing requirements.
- Struggling through ambiguous requirements.
- Not having timely access to the business people.
- Delays from sequential hand-offs between disciplines.
- Testers and developers disagreeing over the interpretation of a requirement.
- Testers receiving code and not knowing what or how to test the completed software.
- Having completed code, but not being able to quickly deploy it for testing.
- Rework because requirements were misunderstood.
- Slow response time when the business people change their minds.
- Assumptions about requirements or architecture being overturned.
- Elaborate documents that quickly become obsolete.
- Code that was written because it will be needed later ; it never was.
Skills and practices also affect productivity. Who’s more productive? The developer using test-driven development and continuous integration , who checks in code and integrates with others many times a day, and who collaborates with testers performing exploratory testing in parallel. Or the developer who codes for days (if not weeks) before checking in and integrating with others and then hands-off to testers for manual ad-hoc testing, bouncing back and forth as he fixes bugs until the code is working? I bet it’s the first developer.
Give me an agile process in a lean environment any day.