Agile Maturity Model – What’s Next?

The maturity model approach to describing organizations and processes comes and goes out of fashion. It is a repeating framework de jour. In the game of agile jargon whack-a-mole, the agile maturity model is poking its head up again.

Agile Maturity Model

Ellen Gottesdeiner, author of Requirements by Collaboration, tweeted (@ellengott) a few hours ago with a link to an article proposing a set of maturity models. She graciously passed on the opportunity to comment about the “agile maturity model” when pointing out her like of the collaboration maturity model. The article proposed the following as an agile maturity model:

Agile Maturity Model (AMM)

0 – Dormant

1 – Speed: Focusing on being expeditious.

2 – Reactive: Focusing on acting relative to change from the perspective of the moment rather than a longer timeframe.

3 – Responsive: Focusing on acting relative to change from the perspective of the moment balanced with a longer timeframe.

I didn’t find it to be a particularly useful model. Although descriptive, it won’t help your organization improve.

What Does Maturity Mean?

I wrote a series of articles a couple years ago that explored the CMMI and RMM – the capability maturity model and the requirements maturity model. These are two different models that use maturity as a concept for articulating different levels, or grades (or enlightenment, or rigor), with respect to organizational behaviors. At the time, there was both momentum and confusion around the notion of a requirements maturity model. CMMI is a description of an organization’s rigor in “saying what it does, and doing what it says.” RMM is an assessment of the level of critical thinking incorporated into the ways an organization is using requirements to develop products.

The problem is that people were incorrectly assuming that an organization “at level 4 CMMI” would approach requirements management at a comparably enlightened level. The problem is that they are putting entirely unrelated concepts into similarly named classifications. An organization could be at CMMI 1 and RMM 4 or RMM 2 and CMMI 3. That series of articles explored what it would mean to be in any of the combinations of “maturity” for those two models. Check out all the articles in the series if you want to put it all in perspective:

• Foundation Series: CMMI Levels Explained
• What CMMI Level Should We Use?
• CMMI Levels and RMM Introduction
• CMMI Levels and RMM Level 1 – Written Requirements
• CMMI Levels and RMM Level 2 – Organized Requirements
• CMMI Levels and RMM Level 3 – Structured Requirements
• CMMI Levels and RMM Level 4 – Traced Requirements
• CMMI Levels and RMM Level 5 – Integrated Requirements
• Don’t forget to take our One Minute Survey on CMMI and RMM.

Making a Maturity Model Useful

Why bother with a maturity model? Not so you can “keep score” relative to others – rather, so that you can improve your own organization. For a maturity model to be useful, you have to be able to do two things.

1. You must be able to determine where your organization is in the model.
2. You must be able to identify actions you can take to “improve” your organization relative to the model.

If you can’t measure maturity, and the model does not provide guidance about how to improve, it’s useless. One challenge with maturity models is that they risk becoming contextually narrow in their application. The more concrete a measurement or suggestion becomes, the less extensible it is likely to be. Ideally, your model would be broadly applicable to many organizations.

With an agile manifesto that emphasizes people over process, it is ironic to consider applying a metric that measures your agile process. So – goal #1 is immediately undermined. Goal #2 – improving your organization, is, however, very valuable.

Improving An Agile Process

I’ve worked in several agile environments, both as a practicioner and as someone helping to transform organizations to become agile (or better at agile). I’ve worked in enterprise software, helping large teams adopt agile processes; with a SaaS consumer product team, and in large IT departments with collections of teams adopting agile processes at varying paces. I’ve played on both sides of the fence (delivery/QA & product management/ownership).

Going from zero to sixty on agile is a big task. You can’t solve all of the organizational, practical, and interpersonal challenges at the same time. Or at least you would be more effective tackling and resolving each issue in sequence. In fact, you should solve the most important / largest problem first – then move on to the next, and so on. You can call it agile agile adoption, or you can call it eating the elephant.

One powerful use of a maturity model is highlighting the next-biggest hurdle you have to overcome. Unfortunately, most communication about maturity models is “look which hurdle we just overcame” – but the focus should be on “what’s next?”

When helping organizations be effective with agile processes, there are some clear “you have to overcome this first” challenges, that if unresolved, make other challenges irrelevant.

If you’re a software developer, I’m sure you’ve experienced the following scenario:

• A bug is reported.
• You fix the bug, and write some tests to prevent it from reoccuring.
• While testing, you discover another bug that was hidden by the first bug.

Fixing that second bug doesn’t do any good until you’ve fixed the first one.

If you’re a product manager or business analyst, think about it in terms of capability enhancements. Is a faster search important if the current search algorithm is not returning the right results? Get good results first, then make it faster.

You have to solve the biggest/closest/roadblockiest issue first. Then move on to the next issue. That’s how you should use a maturity model – as guidance about “what’s next?”

When assessing / improving your organization’s ability to be agile, you need to be addressing whatever is next.

What’s Next?

Let’s discard the “maturity model” notion and focus on “what’s next?” instead. And that of course starts with “what’s first?” Here’s how I’ve presented an agile hierarchy of needs to in the past:

1. Staffing the engineering team correctly. People over process is the right emphasis. If you can’t find people that are “good enough” you might as well go home. Doesn’t matter how agile you are if you don’t have the horsepower. You also need people who are excited to “do agile” – they like to communicate, they enjoy the project and team dynamics of an agile process. You’re also better off with specializing generalists – ideally, every member of the team can do any work that is needed. This is an efficiency play – you risk introducing bottlenecks when you have a specialist who is the “only one” who can do particular types of work – because you will not have a consistent mix of types of work from release to release.
2. Assuring Quality is in your team’s DNA. Arguably, this is part of what’s first, but there are a lot of teams that get cood at cranking out code, before they get good at cranking out good code. Continuous integration is the approach you must have. Test-driven development, spec-driven development, and other testing-integration approaches are extremely important, but are really reflective of different flavors of agile and quality, not different degrees.
3. Reducing overhead in the release process. There’s a cost associated with releasing a product. Once you get good at releasing, and are releasing good product, your next focus is on finding the right release cadence. There are three factors that essentially dictate your release frequency. The size of atomic deliverables (user stories and use cases, non-functional requirements, etc) your team is creating, the overhead (time and cost) of releasing, and your customer’s capacity to consume the releases. My anecdotal experience is that teams are usually constrained initially by the cost of releasing – dedicated hours to creating a build, code freezes, etc. Automating the build process (to reduce both costs and errors introduced while building) is first. Integrating automated build and automated test processes together is next.
4. Feeding the beast. Once you have an engineering / delivery team that is operating efficiently, you run into the problem of making sure they have enough important work to do. There’s pressure on product owners and product managers to schedule something because it is easy to define, not because it is important. It is also important that the team understand the context and importance of what they are doing. So you have to focus on making sure your product management team has enough capacity to keep the engineering team busy on delivering really valuable stuff. The “right” solution to this depends on how the problem manifests in your organization. Is your product manager spread too thin across multiple products? Too junior? Too bogged down in sales support or trade show attendance or or or?
5. Managing stakeholder expectations. A big challenge in changing an organization to become agile is in resetting and managing the expectations of stakeholders. Execs are used to having an annual budget exercise where they dedicate X dollars in the pursuit of Y objectives. We’ll set aside the reality that they’ll only achieve 1/3 of the objectives, at 2X the cost, much later than originally forecasted. We aren’t looking at the failings of waterfall, we’re looking at the risks of agile. There’s a ton of stuff here, from doing damage control to reverse perceptions that “people who want to do agile just don’t want to be accountable” or addressing the “we can’t tell you what X dollars gets you” message. Again – the particular solution is a function of how the problem manifests in your organization. Once your team is delivering valuable stuff efficiently, you have to make sure your management team is happy and engaged and knows what to expect.
6. Continuously learning from your markets. This is really what differentiates an agile organization from an organization with an agile development team. Agile processes do enable you to develop code more efficiently. If you aren’t taking advantage of the faster development, feedback loops, and ability to change that agile enables, you’re leaving money on the table. And one of your competitors will pick it up. There’s a whole community of MBAs that talk about business agility without once thinking about software development. They’re talking about an organization’s capacity for rapid response to changing market conditions. It’s what separates the winners from everybody else. And agile development makes business agility possible. As long as your team is able to identify and value industry trends, competitive threats, and market opportunities. When you’re good at this, you have an agile organization. And you win.

Conclusion

Any agile “maturity model”, irony aside, needs to be structured to help organizations progress through the stages of enlightened operations – continuously providing insights into “what’s next?” for those teams to grow.

I know there are many readers here with years of agile experience – how would you improve the list above, to better provide a framework for “what’s next?” When that framework is solid, we can do some wordsmithing and repackage it as a maturity model. Until then, just focus on “what’s next” – that’s all a maturity model should be used for anyway.