Brief Reply to Comments on the Agile Maturity Model (AMM)

This is a brief reply to Scott Sehlhorst’s / Tyner Blain’s comments on the Agile Maturity Model (AMM).

The article proposed the following as an agile maturity model:

More “observed” than “proposed” as indicated by emphasizing the notion of “grounded in reality”.

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

By being descriptive of “evolutionary stages”, it offers insight around “what next” in the journey. The model does not prescribe “how” to improve (or make the journey). How to improve involves adoption, which is outside the scope of the model.

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.

Reality is messy and models are mere abstractions of reality, while models inform, they cannot be considered in isolation. Notice that it is “You” who is judging “where your organization is in the model” and “You” who is to “identify actions you can take to ‘improve’ your organization”. Thus, a model ought to be “grounded in reality” and is context-aware but not context-sensitive (that is, “guidance” without “becoming contextually narrow” but remaining ” broadly applicable”).

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.

The AMM does not suggest “a metric that measures your agile process”. To measure your Agility, measure your Responsiveness (people and business system, that is, structure and processes, etc.). Agility also pre dates the manifesto by far (see the blog for more).

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?”

Indeed, this is what is expressed by “evolutionary” as used in “evolution stages”, it offers insight around “what next”.

Its “adoption” (as the author says “agile agile adoption”) that focuses on how to achieve the “what next”.

That’s how you should use a maturity model – as guidance about “what’s next?”

AMM meets this (in the proper hands) but nothing can be used in isolation.

The author offers an “agile hierarchy of needs” (that he has “presented” “in the past”), which includes:

  1. Staffing the engineering team correctly.
  2. Assuring Quality is in your team’s DNA.
  3. Reducing overhead in the release process.
  4. Feeding the beast.
  5. Managing stakeholder expectations.
  6. Continuously learning from your markets.

If one examines the description carefully, you will see that:

  • Steps 1, 2, and 3 generally relate to the AMM’s Speed stage as “efficiency” and “efficiently” are mentioned in the article.
  • Steps 4 and 5 generally relate to the AMM’s Reactive stage as “make sure your management team is happy and engaged and knows that to expect”.
  • Step 6 generally relates to the AMM’s Responsive stage as “business agility”.

Without further commenting on the steps (as there are many aspects on which to comment, both positive and negative), this further proves the common pattern expressed by the AMM (via observation and grounding in reality).

Advertisements

2 thoughts on “Brief Reply to Comments on the Agile Maturity Model (AMM)

  1. Thanks very much for extending the conversation! I agree with your mapping of the 6 steps to the stages you identified.

    The distinction that mattered to me was that I feel like knowing the difference between a company’s place in steps 1, 2, and 3 helps me immediately have an idea for what to work on next. You can think of it as decomposition of the stages you identified.

    When I think about how I’ve used maturity models in the past (both in mechanical engineering and software development contexts), I find that there is some value in using them for ‘conversational shorthand’ to make communication more efficient. For me, the level of detail in the ‘stages’ breakdown does not decompose the continuum of what’s next in a way that makes it easy to know what’s next. I don’t disagree with the elements you called out, or the sequencing – just the level of detail.

    When I think about who might use an agile maturity model, I expect it to be either people who don’t understand the space, but want to “keep score”, as well as people who are having conversations across organizations. And I think having a next level of detail would really help someone who doesn’t “get” agile to (1) start to understand, and (2) get a feel for how much growth (or untapped potential) remains for his particular team.

    I think it would be great if you were willing to follow up with detailed thoughts about the steps (both positive and negative) I threw out there. Do you think it is a more useful level of detail? In the right sequence? Missing something? Are any of the steps significantly less important than the others (such that they should be excluded)?

    Thanks again for responding to my thoughts, and for starting this discussion!

    • I don’t disagree with the elements you called out, or the sequencing – just the level of detail.

      I appreciate your clarification, however, the details (“level of detail”) are indeed generally very contextual!

      When I think about who might use an agile maturity model, I expect it to be either people who don’t understand the space, but want to “keep score”, as well as people who are having conversations across organizations. And I think having a next level of detail would really help someone who doesn’t “get” agile to (1) start to understand, and (2) get a feel for how much growth (or untapped potential) remains for his particular team.

      While a maturity model might describe “degrees (or a pattern) of evolutionary stages (of essential elements) toward a goal”, such a model may be used or abused (as I mentioned “perverted” in my original blog post) — especially if “people who don’t understand the space” try to “‘keep score'” without the guidance of someone who does “understand the space” (and thus can better leverage a maturity model)!

      I think it would be great if you were willing to follow up with detailed thoughts about the steps (both positive and negative) I threw out there. Do you think it is a more useful level of detail? In the right sequence? Missing something? Are any of the steps significantly less important than the others (such that they should be excluded)?

      The AMM is derived from observation and focuses on being descriptive around the “evolutionary stages”.

      The six steps appear more focused on being prescriptive around adoption. The six steps don’t seem to address scalability and sustainability. Adoption, scalability, and sustainability are beyond the AMM discussion herein.

      Agility is not a Technology (vs. Business) concept, it applies to Business (Product Management) & Technology (Product Engineering) with Management & Teams (as you mentioned in your step 6).

      Agility is fundamentally about Responsiveness (people and business system, that is, structure and processes, etc.).

      Agility pre dates the Software Development manifesto by far (see the blog for more) (also as you mentioned in your step 6).

      Respectfully, comments herein…

      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.

      Consider people for both Business (Product Management) and Technology (Product Engineering), and maintain balance (between Business and Technology). Agility is not a Technology “thing”. Staffing the product management team correctly is just as important as staffing the engineering team correctly.

      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.

      Consider both Business and Technology, and maintain balance. Agility is not a Technology “thing”. Consider Quality around Process (efficiency) and Product (effectiveness). Consider Principles and Values not merely Practices. Assuring quality in product management is just as important as assuring quality in product engineering.

      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.

      Consider both Business and Technology cadences, and maintain balance (Vision & Roadmap and Releases, etc.). Ultimately, consider optimization in product management as well as product engineering.

      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?

      Consider both Business and Technology, and maintain balance. Saying “once you have an engineering / delivery team that is operating efficiently” presumes that product engineering was not “operating efficiently” and is honestly somewhat insulting. Why not say “once you have a product management team that is operating efficiently” and suggest that product management was not operating efficiently! Ultimately, consider Business and Technology being responsive to each other and to the market.

      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.

      Consider both Business and Technology, and maintain balance. Saying “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” presumes that product engineering was not “delivering valuable stuff efficiently” and is honestly somewhat insulting. Why not say “once your product management team is steering the product efficiently/effectively, you have to make sure your engineering team is happy and engaged and knows what to expect” and suggest that product management was not “steering the product efficiently/effectively”! Ultimately, consider Business and Technology being responsive to each other and to the market.

      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.

      Consider both Business and Technology, and maintain balance. Notice, by not focusing on the “market” until this step, you have an optimized and responsive Technology or product development team with a Business or product management team that may not be prepared to steer (relative to the marketplace) such an optimized and responsive Technology team — a potential receipt for disaster! Imagine giving a sports car to someone who is accustomed to driving a “more basic car”! Enterprise Agility = Agility of (Business + Technology and Management + Teams). Furthermore, the statement “agile development makes business agility possible” is highly debatable (and beyond this AMM discussion). You may have more-Agile Business or more-Agile Technology but remain a less-Agile Enterprise, especially if there is a lack of balance.

      Suggesting a focus on Product Development first, then Product Management next, perhaps lacks an authentic awareness and appreciation for Agility (Values, Principles, and then Practices), Enterprise Agility, and the pragmatics thereof.

      Respectfully, hope these comments are of value.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s