Everyday Kanban

Discussing Management, Teams, Agile, Lean, Kanban & more

Reflections on maturity models

Seattle Lean Coffee sticky notes

In this week’s Seattle Lean Coffee we discussed the topic of maturity models. When I picture a maturity model in my mind I see a beautiful rendering of professional looking levels defined by specific practices that tell you if you’re in level 1, level 2, level 3, and so on. That may not reflect all maturity models but that’s my immediate mental reaction. And, these types of maturity models are something you want to love. You want life to be as easy as “if I do these 20 things” I’ll be a master of life! However, the reality is that doing those 20 things only allows you to say “I do these 20 things.”

What are maturity models really?

According to wikipedia, maturity, as it relates to maturity models, is defined as “a measurement of the ability of an organization for continuous improvement in a particular discipline.”  Maturity models generally contain an assessment and a set of levels that correlate to particular result sets. The article sources the International Journal of Society Systems Science  when saying “Most maturity models assess qualitatively people/culture, processes/structures, and objects/technology.”

How maturity models can unintentionally hurt you

I’ll be the first to tell you that, in my opinion at least, there are some baseline activities that will generally help people instead of hurt them. I’m thinking of things like visualizing work, using enabling constraints like work-in-process limits, and regularly attempting to improve. (See What is Kanban? for more) But, any model that tries to tell you that you’re in a certain level if you do specific tactics like estimating every piece of work or having a work-in-process limit on every column of your board are missing the mark.

If a model’s assessment, and the resulting levels, are more focused on process than outcomes, then you are in significant danger of losing sight of your original goal and seeing the levels and their desired processes as the target. Goodhart’s law warns us “when a measure becomes a target, it ceases to be a good measure.” If you’re measured on achieving L5 of a maturity model and your paycheck or other key conditions of employment are affected by your ability or failure to achieve this, you’re going to achieve it whether or not its really the best thing for the organization.

“I achieved my goal but not my aim. That happens a lot, we honestly translate aims to goals. And then we do stupid things in the name of the goal get it the way of the aim. We forget the aim sometimes and put the goal in its place.”

Mike Tveite – blog.deming.org

Using maturity models for good

Much like efforts to estimate story points, I think the value is in the discovery rather than the actual number or level that’s assigned.  Much depends on the assessment. If you aren’t trying to figure out how well you’re doing at following a specific process then you want an assessment that focused on outcomes instead of how you reach those outcomes. You leave the choice of how to the people who need to do the how. The assessment, in addition to being outcome-focused, needs to have outcomes that you agree are critical to business health. Otherwise, why bother?

Once these conditions are met, you can take the assessment and start processing the results. You can spend some time in advance coming up with ideas of what you might want to do if you have undesirable results in certain areas.  However, I wouldn’t suggest treating it as a list of commandments. Instead, I’d look at it as a list of suggestions…  ideas that have worked for others in similar contexts that you might consider. Then, after the results of the assessment are discussed, bring in the people who took the assessment and harness collective brainpower to see if there are even better ideas that might be appropriate to your context. Then you have the bones to decide on, and design, experiments that you want, or may want, to carry out.

When I teach continuous improvement concepts to teams and organizations, I propose the use of models when you don’t know what else to do. Maturity models fall into that bucket. They can be used to help you get started, to initiate learning with the goal of growing beyond the need for them at some point in the future.

I’m currently starting to use the Agendashift™ program in my work as it has an outcomes-focused, framework-agnostic assessment. I’ll post more about what I find and think as that progresses.

What do you think about this topic?

I’d love to hear your thoughts on maturity models. This is by no means an exhaustive post on the topic and I am sure there are some pretty strong opinions out there about what I wrote and what I didn’t write. So, share yours by commenting below. Hate them? Love them? What is good about them? What is bad? Any particular ones you like? Why? Let’s have a conversation.

2 Comments

  1. To expand on this: a capability maturity model relates to how an organization responds to various situations. Do they have a plan or do they just panic? An assessment is more a measure of whether the group meets an established criteria for a goal. The maturity level reflects the capability of the organization, regardless of their goals.

    One thing that comes up in Kanban is that organizations attempt practices without having the capability maturity to handle them. Having an understanding of their current capability means that they attempt practices that are appropriate so they can have the greatest success. If, for some reason, they are hung up on achieving a higher maturity level, then they will have to improve their capability such as through improvements of policies, for example. If they attempt something like enterprise-wide scaling without having that maturity (a mix of mindset, knowledge, experience of practices, and cultural coordination) then their scaling is likely to fail.

    So, the question asked in an assessment might be “Are you doing Kanban?” — which I think it a much harder, dicey, and more controversial question. The question asked in establishing a maturity level is “What kind of Kanban activities/practices is your organization ready to do?” and “Are they ready to do more?” Maturity level relates to appropriateness.

    • “One thing that comes up in Kanban is that organizations attempt practices without having the capability maturity to handle them. Having an understanding of their current capability means that they attempt practices that are appropriate so they can have the greatest success.”

      I like this way of thinking. I also like the concept of maturity being measured by how well you stick to things you know will help versus falling back into unhealthy patterns when things get crazy.

      I think its very easy to use maturity models poorly, though most, if not all, were made with good intentions. I think we should only be asking about the maturity of kanban implementations if they have already identified that having a mature kanban implementation will help drive their desired outcomes. I am biased and think that generally it will. But, I don’t want anyone to get in the habit of making those assumptions. It’s so easy to forget the point. So, I think these process-focused maturity models can add value as long as they are supported by a theory, at minimum, that the process will help become more mature around delivering desired outcomes. Now, outcomes and capabilities… need to think more if those two are generally meaning the same thing but with different labels.

      I appreciate the conversation! Let’s everyone keep it going!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2018 Everyday Kanban

Theme by Anders NorenUp ↑