Nowadays, for too 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 to everyone that AMMs are different from Agile Check-Lists (e.g. classic example of Scrum Check list by H. Kniberg) and this can often 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 place attributes in buckets that represent different states of maturity, with one state, following another, sequentially.
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.
Note: Translation of the text in red: “(Пере)выполним годовой план за три квартала!!!” = “Will meet/exceed the annual plan in three quarters!!!”
2 – Attribute-to-Maturity Level relationship is conditional, at most: Placing agile attributes in maturity buckets implies that attributes in higher-maturity buckets have more weight 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 interrelated systemically and impact one another in ways that is not apparent, to a naked eye. 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 be more advisable to treat every identified agile attribute as a system variable, that is on-par with other system variables, while assuming that it has upstream and downstream relationship. In many situations, instead of spending a lot time and resources on trying to improve a downstream variable (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 the 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).