“So we need to build cross functional teams where the developers can help out with the testing effort….”
“Wait a minute, are you suggesting our developers become testers?”
“I’m suggesting people help remove bottlenecks and help all the work get done faster. Testing is a bottleneck, so helping with the testing effort will remove the bottleneck to getting more stuff done faster”
“But if we do that, our developers wont be productive. I want them to be productive and focused on writing software!”
I’ve had this conversation, and many others like it with client over the years. The unnatural focus on developer productivity continues to boggle the mind.
There is no objective way to measure developer productivity
News Flash, developers are not widget makers in a factory, their productivity can’t be boiled down to a nice, clean, objective, numeric measure. We have all heard horror stories about companies who use “lines of code” as a measure of developer productivity. Thankfully, that practice has gone the way of the dinosaur. However, engineering leaders continue to search for that “one true metric” like Ponce de Leon searched for the fountain of youth. He ended up with mosquitoes instead.
Creating a local optimization does not optimize the complete system
It’s easy for me to rage against the developer productivity argument, but that’s not my point. My point is: As we look for ways to smooth the flow from “I have an idea” to “This idea is making money”, we look for ways to remove bottlenecks.
The bottlenecks are what prevent us from creating value as quickly as possible (concept to cash). One of the biggest bottlenecks of any development organization is the bottleneck that happens when 5 developers finish coding at the same time and there is but 2 lonely testers to try to validate the code. This in addition to the regression, the test planning, and whatever other duties they have on their plate. Heaven forbid they’re part of a “testing pool”, then it really gets gnarly.
When we optimize for the developers “productivity” rather than the system’s “flow”, we are intentionally creating a bottleneck and limiting the flow. Not good.
Developer productivity is not a business outcome
Lastly, when I talk to organizations about Agility I always turn the focus away from the particular terms and jargon of Agile, and more toward what we really want, which is positive business outcomes. Most businesses invest money into projects for one of three reasons:
- Save Money (automating business processes, less expensive platform, fewer people needed to maintain)
- Make Money (revenue generation opportunities, adjacent product market, vertical value chains)
- Reduce Risk (compliance, redundancy, disaster recovery, unsupported platforms)
Focusing on these business outcomes and creating the conditions to objectively improve them is a much better use of time, effort, money, and energy than optimizing for a software engineer’s so-called “productivity”
Until Next Time,
Stay Agile, My Friends