I’m on board with the Agile approach to software development and I have a strong history with process approaches to improvement (ISO-9000, CMM, CMMI, TSP, etc.). That said, I have always believed that the quality of the people doing the work is the biggest factor of success. The software estimation technique, COCOMO reveals this because “personnel attributes” dominates just about all COCOMO estimation models.
I think David Starr over on Elegant Code hits the right note in pointing out how this manifests itself in his post on Measuring Craftsmanship. His post starts with a distraction by arguing against the idea of measuring Agile maturity. I say distracting because I think it’s possible to agree with his message about the importance of craftsmanship no matter how you feel about the idea of creating an Agile Maturity Model.
The emphasis needs to always be on the people doing the work. In particular, I like his idea of “picking a guild” as a source for your skills criteria. Because of the way the software industry works, each organization might be its own guild, so I think it will be hard to agree upon the list of guilds and find a set of criteria most appropriate for each of them, but I think it is possible to create a map between certain practices and required skills.
For instance, if you are going to rely upon refactoring and emergent design, you better have strong design patterns skills. Same goes for tool usage. The practice of continuous integration requires build tool skills. Your team’s approach to software assurance also dictates the skills you need. If you rely heavily upon automated testing, then you need skills with automated testing tools and patterns that enable design for testability. If you rely more upon inspecition, mastering the skills of Spineliis Code Quality and Code Reading should be expected.