AGILE IN ACTION

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.

The Agile Manifesto values individuals and interactions over processes and tools . You can do away with prescriptive process and achieve significant throughput if you have a disciplined, colocated and cross-functional team (that includes the product owner ), with people who communicate effectively, collaborate intensively and focus on delivering business value. In an environment where they are trusted to self-organise and make decisions, and where they receive feedback continuously, I bet these people will always deliver more than a traditional team ( more a group than a team ) in a command-and-control environment. Why? Because empowerment and ownership breeds responsibility, commitment, accountability and motivation. You’ll see delivery, early, often and regularly. Disempowerment and control breeds mediocrity, apathy, fear and demotivation. People turn up but they lack commitment and they don’t really take responsibility. You’ll see missed deadlines, a distinct lack of delivery, and ultimately you’ll smell the dead fish of failure .

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.