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.
