Maturity Models: How Useful Are They?

Maturity Models: How Useful Are They?

If you hire a consulting company to help to improve your IT agility, the first thing they will propose is that they conduct a “maturity assessment”.

An Agile maturity assessment is a big win for a consultancy, because it is a largely academic exercise, and so it is easy to do. The result is a report, which scores your organization on a chart (usually accompanied with a proposal for Agile transformation assistance).

For each category of the chart, your teams are rated from a range of beginner to advanced, depending on what “practices” the teams are using and what “attitudes” the teams exhibit. Here is one such model from Thoughtworks.

One problem with an Agile maturity model is that it presents a prescriptive idea of what “ideal” is. Yet, Agile often looks different in different organizations, and for good reason.

For example, a company that builds embedded software that controls expensive machines cannot test quickly and often in the same way that one could for a server based Web application. Actually, they could, but it would require a very large investment in automation to achieve that; the cost/benefit tradeoffs need to inform the decision. Blindly scoring someone on a maturity model is a simple-minded approach.

 “Any fool can know. The point is to understand.” - Albert Einstein

Whichever maturity model one uses (there are many competing ones), it is important to not be too detailed or prescriptive, but instead focus on higher level concepts. For example, while unit testing was considered a crucial element of Agile years ago, today the focus has shifted to automated acceptance testing, as systems have become larger and more complex and integration testing has become more crucial than unit level testing.

Either way, having frequent automated tests are crucial and are a sign of “maturity”, but specifying that they should be mostly unit level or integration level is something that should be decided on a case by case basis—not something that is scored.

This points to one of the things that is often left out of maturity models: integration. The focus is often on team level practices, but in my experience, the stumbling blocks that IT organizations tend to face today are the cross-team ones.

The stumbling blocks that IT organizations tend to face today are not at the team level, but at the cross team level.

Focus Effort Where it Makes the Most Difference

An important thing to realize is that if one were to do all the things that are recommended for building and releasing software, one would probably go out of business. Software assurance practices are like insurance: you have to decide how much you need, based on your risks, and hope there is still enough left over to fund investment.

No alt text provided for this image

This is why one should focus on the problems that your organization is actually having, and look at which practices might alleviate those. If you try to implement every practice in a maturity model, you will spend a-lot of unnecessary effort, and you will extend the time to when you start to receive tangible benefits. This is a Theory of Constraints approach: determining ways in which your teams are being held back, and instituting practices that overcome those.

Some teams perform really well by using only some Agile practices—not necessarily all. It depends on the team, their environment, their customer market, and what they are building.

Forget “Maturity”—Decide How You Want to Work

Another problem with maturity models is that the term “maturity” is a bad metaphor. Humans mature through stages. However, teams do not need to. A team—or a collection of teams—can often leapfrog stages of “maturity”.

No alt text provided for this image

For example, referencing the Thoughtworks maturity model, if a team is using manual testing, it can decide to start using automated testing for all new work, and progress straight to the level of fully automated regression testing—at least for new functionality. All they need to do is discuss how to do that, and start doing it, and gradually refine their approach. They do not need to “take baby steps” or go through interim levels of maturity.

Indeed, I have found that teams can adopt a surprising number of new practices in short order, if you coach them through considering those and the benefits.

A Model Is Not a Plan

Maturity models are useful for considering ways to improve, but they are models. They are not effective as a scorecard, because teams can often perform really well even if they are low in “maturity” in some areas. A maturity model is also not a good “plan” for what to improve: you should look at what is holding people back, and create a unique plan for the situation.

It is also a waste of time to assess maturity for all of your teams. A more economical, faster, and effective approach is to find out which are the best performing and worst performing teams, check in on those to observe how they work, look at some of the code and the tests, look at many of the various build jobs, look at quality metrics and incident root causes, and form a picture of how the teams are working together as a system. Assessing the “maturity” of each and every team is not necessary, and will cause you to lose sight of the root causes and what is really constraining your organization’s performance.

Jason Ely, PMP?, CCMP?

Managing Partner at Strativ Consulting & Adjunct Instructor of Business at George Mason University

5 年
Frank Rios

Enterprise Agility Coach, Leader in Organizational Efficiency, Effectiveness, and Process Optimization

5 年

Assessing “maturity” of Agile assumes achieving a certain level will increase success. The ones I’ve seen tend to focus on events/ceremonies and engineering practices, which have little to do with the agile mindset (which is the core of agile). One such assessment focused heavily on the Scrum events and if you did all of them every sprint, you were considered “level 5”, whatever that means. I know of lots of Scrum teams that go through the motions of Scrum and are by no means “mature”, but according to this assessment they are.

Rick Vance

Transformational thought leader who successfully helps organizations solve business problems thru lean-agile mindset.

5 年

"Embedded software controlling large machines?".? I believe the conversation starts with "what problem(s) are we trying to solve?", rather than just jumping into an assessment of "maturity".? If quality is the main problem, then daily huddles and estimation are not likely to help.? If throughput and bottlenecks are the problem, then improving unit testing is not likely to help either.??

Chris Palmisano

Program Management | Delivery Management

5 年

Excellent article, Cliff! I agree that the semantics of the term "maturity model" is inappropriate. Nobody is going to high-five you because you have "mature" agile practices - nobody cares. The objective is to deliver better outcomes; better products and services. Hopefully this Agile stuff helps us do that. Where I do see value in conducting "Discoveries" (a better term IMO) is in helping organizations create a culture of continuous improvement. It's not about being level 5 mature, it's about having a healthy skepticism for the way we work, and striving for improvement. So yeah, a fool with a tool is still a fool. Point taken. But I do think there's some value in having a framework (gasp) for evaluating the effectiveness of how we are working. So long as that tool is not treated as the end, but rather a means toward a much bigger end.

Scott Barnes

Business Operations Optimization, Standards Integration, Board Advisor, Mentor, Investor

5 年

Cliff, maturity models, in general, should not be a one size fits all. Implementing a model that is right (ie: supports the "how you want to work" concept does, in fact, help you focus on making the most difference. Empirical, by definition, we should observe and adjust as necessary. In that vein then, a maturity model helps us record our observations and pinpoint where we need to make adjustments. It should be nothing more and nothing less. I appreciate the thoughts in your article and don't see them as being disconnected from a model that represents a collective mindset on where help is needed and where it isn't.

要查看或添加评论,请登录

Cliff Berg的更多文章

  • They Know a Collapse Is Coming

    They Know a Collapse Is Coming

    The CIO of Goldman Sachs has said that in the next year, companies at the forefront will begin to use AI agents as if…

    78 条评论
  • Agile – I Told You So

    Agile – I Told You So

    I think it is no longer controversial that the Agile movement is in decline. When I made a post about it a year ago…

    51 条评论
  • The Most Brilliant Programmer I Have Known Couldn't Work at Google

    The Most Brilliant Programmer I Have Known Couldn't Work at Google

    During the late 1980s I worked at a 30-person startup. The company was founded by the two fellows who had been the lead…

    31 条评论
  • The Most Guaranteed Way to Improve the Bottom Line

    The Most Guaranteed Way to Improve the Bottom Line

    Culture eats strategy for breakfast, but it’s leaders who generate the culture – leaders at all levels, not just at the…

    2 条评论
  • Empowerment, Not Self-Organization

    Empowerment, Not Self-Organization

    Have you heard people say something to the effect of, “Self organization is not really entirely self organization”? I…

    11 条评论
  • Join a Community that is About Learning

    Join a Community that is About Learning

    Things like leadership, product development, technical practices in DevOps, and more. Free workshops for learning.

  • Anyone Can Learn DevOps

    Anyone Can Learn DevOps

    Are you looking for ways to expand your skills, to be more effective in your organization? One way is to learn more…

  • Use a Capability-Focused Approach — Not an Agile Framework

    Use a Capability-Focused Approach — Not an Agile Framework

    Article here: https://www.agile2academy.

    3 条评论
  • Why Team Performance Is the Wrong Thing to Focus On

    Why Team Performance Is the Wrong Thing to Focus On

    Many companies today are obsessed with teams. The “old” approach of static departments and hierarchies is out.

    12 条评论
  • Leadership Is the Key Skill Today

    Leadership Is the Key Skill Today

    Join our free “Intro” to our acclaimed course, Constructive Agility? for Leaders. (Formerly Agile 2 Foundations) It…

    5 条评论

社区洞察

其他会员也浏览了