Guidelines for evaluating an Agile Maturity Model
When it comes to any Agile Maturity Model (AMM), it is paramount to start with the business value with respect to the framework. The framework should clearly identify the business and software engineering issues it is trying to solve.
The framework should be simple to understand. It’s essence should be straightforward. Practitioners should be able to start applying the concepts and see progress. Days of training should not be a pre-requisite for adoption.
I am very reluctant to place any named method into different defined levels, unless the analysis is multi-dimentional. Let me be concrete. When an IBM employee identifies RUP as a Level 2 method and Scrum and XP as Level 1 methods, it is an open invitation for skeptics to find immediate cause to reject the maturity model as biased toward company loyalism. This is not to say that we should not compare and contrast different methods. Larman compares methods by ceremony and cycle while Cockburn scale’s uses team size and criticality to determine a version of Crystal to use.
