This is the first of two responses to Tobias Mayer's Getting Trashed by the Lean Machine, his reaction to the panel session at the Agile conference in Buenos Aires last month. This first response deals specifically with the interaction between Tobias and Micah Martin, and Micah's comments which I copy here for convenience...

[...] My frustration is not specifically with Scrum but with the diminished focus on software in the Agile community. As Agile has grown it has become more of a project management topic rather than a software development topic. For good or bad, Scrum is the most prominent face of Agile project management and so it gets the blame. [...]

I've heard this sentiment a lot recently at conferences from the programming focused folks. The key problem is that their locus of interest surrounds programming and they want to be part of a community inventing better ways of developing software (in the tightest definition meaning programming). Meanwhile, many of us in the agile community are interested in better ways of developing software [projects and product]. This second interpretation of the purpose behind the Agile Manifesto leads us to look at whatever constrains our ability to deliver projects and products better, faster, cheaper, and with higher quality and higher value.

It's understandable that many developers want a focus on their own craft. And it is understandable that without this they quickly lose interest. As Tom DeMarco wrote, they are Dilbert delegating responsibility for their success to someone else. It's the blinkers on, just leave me alone to do my thing, approach.

While I have an solid belief that there is a lot more we have to learn about programming and software architecture and engineering, the reason the community has lost its focus on this activity is easily explained. Programming and programmers are not the constraining factor on improved performance!

In my Zen of Agile Management class, I teach participants about constraints. I then ask them, in a collaborative exercise, to speculate about the bottleneck in their organization and discuss how they would prove it and what they would do about it. In almost 3 years of teaching this class, over 4 continents, and around 12 occassions with groups ranging from 16 people to 250 people (at Javapolis in 2007), I have concluded that developers are the constraining factor on project and team performance less than 10% of the time. In some groups it is as low as 3%.

My belief around this is quite simple. Basic agile practices focusing on quality including collaborative working such as pair programming, and a strong focus on unit testing and early defect detection with continuous integration and test automation, have greatly improved software development to the point where initial software quality (i.e. bug insertion rates) is not the constraining factor on team performance. With immature teams, with sloppy development practices and poor initial quality (i.e. high defect insertion rates) development is the constraint. Agile has successfully fixed this!

So we can declare victory!

In this sense, the crowd who argue for a continued focus on better development practices are fighting the last war.

The rest of the community moved to other areas - most notably project management and business analysis / value-based software engineering. The community tends to get sucked to where the constraining problems are occurring. This is the natural and correct behavior. And it shows that many in the community interpret better ways of developing software in the broad sense rather than the narrow programming-centric sense.

So what next for the purely coding-centric minds in the community? I would encourage them to keep at it. As the wider community fixes the issues with project management, analysis and requirements, and improves the flow of value, the focus will swing back to engineering/development practices. In the case study from XIT, I show how we improved the productivity of a team at Microsoft by more than 3x and shortened their lead time by 90%. All of this was achieved without making any changes to how software was developed or tested. It was achieved by focusing on the bottlenecks  and the waste and eliminating them. What would it take to further improve the performance of that team? A renewed focus on development and testing practices.

So I truly believe the community will swing back to the developers and the testers. Meanwhile, they need to be patient. It's a compliment not to be the focus of attention. It reflects success. Embrace that success and stop complaining! Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Scrum, Extreme+Programming