For many organizations, Agile Maturity Metrics (AMM) have become a trusted way to measure improvements of agility at personal (individuals), team and organizational level.
However, it is not always apparent that AMMs are different from Agile Check-Lists (e.g. classic example of Scrum Check list by H. Kniberg) in ways that may actually lead to problems and dysfunctions:
Check-Lists are just a set of attributes that are usually viewed on-par with one another; they are not bucketed into states of maturity (other logical grouping could be applied though)
On contrary, AMMs usually place attributes in buckets that represent different states of maturity that follow one another, sequentionally.
With very rare exceptions (favorably designed organizational ecosystems), there are three potential challenges that companies face, when relying on bucketed AMMs:
1 – System Gaming: If achieving a higher degree of agile maturity is coupled with monetary incentives/perks or other political gains (for many companies that are driven by scorecards and metrics, this is the case), there is will be always attempts by individuals/teams to claim successes/achievements by ‘playing the system’, in pursuit of recognition and a prize.
2 – Attribute-to-Maturity Level relationship is conditional, at most: Placing agile attributes in maturity buckets implies that attributes in higher-maturity buckets are always more weight-carrying than attributes in lower-maturity buckets. However, this is not always a fair assumption: weight/importance that every organization/team places on any given attribute, while defining its own maturity, is unique to that organization/team. For example, for one team, “…being fully co-located and cross-functional…” could be much more important than “…having Product Owner collocated with a team…” For another team, it could be the other way around.
3 – Correlation between attributes is not linear, at system-level: Regardless of buckets they are placed in, many agile attributes are correlated systemically and impact one another in ways that are not apparent, until system modeling techniques are applied. For example, placing “Scrum Master is effective in resolving impediments”attribute in a maturity bucket that comes before the maturity bucket with “…Organization provides strong support, recognition and career path to Scrum Master role…” attribute, dismisses the real cause-and-effect relationship between these two variables, misleads and sets false expectations.
To avoid the issues described above, it would more advisable to treat every identified agile attribute as a system variable, on-par with others, while assuming that it has upstream and downstream relationship with other system variables. In many situations, instead of spending a lot time and resources on trying to improve a downstream variables (e.g. trying to understand why it is so difficult to prioritize a backlog) it is more practical to fix an upstream variable that has much deeper systemic roots (e.g. finding an empowered and engaged product owner who has as a right to set priorities).
Below, is the list of agile attributes (a.k.a. system variables) that are logically grouped (check-list) but are not pre-assigned to levels of maturity (all flat). Some examples of suggested system-level correlation between different attributes are provided (cells are pre-populated).
Please, click on the image to download the matrix to your desktop, amend the list of attributes if you feel that your situation calls for modification, and then use “Dependency on Other Attributes?” column to better visualize system-level correlation between the attributes are of interest to you and other related attributes (some examples are provided).