Over 5 years ago I blogged about the need to be able to assess the agility of agile teams. In my entry "Aim High" and again in "What to Measure?" I talked about a framework for this assessment.
In the years since I wrote those articles, a lot has happened. I have (mostly silently) worked on these ideas, while small amounts of controversy have swirled around the subject.
- Obie Fernandez's assertion of a need for a Rails Maturity Model
- Bob Martin's Certification Rant
- A debate over the merits of Scrum Certification
- Another rant about scrum certification
- A debate over whether certification is desirable in an agile setting
- Turmoil within the Scrum Alliance
- Is Scrum forking?
- A copyright debate over the definition of Scrum?
Since my initial posts, agile ideas have progressed a lot, recently culminating in the definition and adoption of Kanban. If you aren't familiar with Kanban, this miniguide from infoQ is a must-read, and this infoQ article by Mike Bria is pretty good as well.
This RailsConf keynote by Neal Ford about creativity and constraints has influenced (and is influenced by) some of my thoughts on this subject, although tangentially. Combining the thoughts about constraints in this keynote, mixed with the thoughts about constraints as mentioned in the InfoQ minibook, I think we can begin to talk about constraints as a 'funnel' moving through increasing levels of a maturity model that can be used for agile assessments.
I'm going to talk about this over several blog posts. I hope they are somewhat controversial, in that I want to get these ideas out there and have them vetted against other smart minds; I want to have them honed to a fine edge.
In preparation for these blog posts, I want to give you a few questions to think about:
- How is an 'assessment' different from a 'certification'?
- Why would a successful agile team want an 'assessment'?
- Who is the 'audience' for the assessment of an agile team?
Where am I going with this? Well, I believe:
- that a certain amount of dogma is good in any methodology, as sticking to the methodology through a projects 'rough times' is what tests its suitability, but the dogma battles I have been seeing are at the wrong 'level of concern' in promoting agile adoption.
- the many flavors of agile methodologies are simply varying the elements of software development practices that are constrained, freeing other elements to vary according to the project's specific needs. If we can figure out a reasonable list of what those constrained elements are, we can classify our methodologies.
- like training wheels, more constraints are useful on emerging teams, loosening those constraints as the team matures.
- a team focused on its own self-improvement is going to naturally seek the feedback to make that improvement possible.
- a metrics-based evaluation system, performed by the team itself, or possibly by an external assessor, is one source of that feedback.
I hope you keep reading, and I hope you contribute to the dicsussion
Comments