TL;DR: How to Measure Agility of Organizations and Teams

Is every organization suited to become ‘agile?’ If so: How to measure agility? And if not: Wouldn’t it be great figuring that out before embarking on a futile and expensive journey?

Back in October and November 2017, I ran a survey to identify contributing factors to an organization’s or a team’s agile maturity. In total, 86 people participated. Based on their answers, I aggregated a preliminary taxonomy of agility related factors.

This taxonomy was first presented on the Hands-on Agile Berlin meetup on November 30th, 2017.

On February 3rd, 2018, 20-plus people will join a hackathon to build an agility assessment framework based on this taxonomy. The goal of the workshop is to provide the first version of a tool that empowers agile practitioners to measure agility, be it an organization’s suitability for agile practices or a team’s progress on its path to becoming agile.

Measure Agility of Organizations and Teams — Age of Product

How to Measure Agility: The Current State

Measuring agility is nothing new. There are plenty of tools and approaches available, starting with Crisp’s Scrum Checklist to James Shore and Diana Larson’s Agile Fluency™ model. Measuring agility of prospective clients has become a valued presales tool for many consultancies, too.

What is missing today, though, is an open-source and thus widely available framework that any agile practitioner can use to get an understanding of her organization’s or team’s level of agility.

How to Measure Agility: Future Steps

On February 3rd, 2018, 20-plus people will join a hackathon to build an agility assessment framework based on taxonomy described below. The goal of the workshop is to provide the first version of a tool that empowers agile practitioners to measure agility.

The Agility Assessment Framework Workshop — Berlin, February 3rd @ ThoughtWorks

‘Agility’ could be an assessment of an organization’s suitability for agile practices, providing an idea of the necessary steps for an organization that decided to become a learning organization. Questions that come to mind are, for example:

  1. Where are we now?
  2. Where do we want to go?
  3. What are the necessary steps to get there?
  4. Design a plan how to get there

The Berlin hackathon will be an experiment. For example, I wonder if we can apply analytical thinking–such as measuring factors and calculating states—to complex social systems? Or will that approach turn out to be a dead end?

How to Measure Agility: The Original Survey Questions

The 2017 agile maturity survey comprised of four questions:

  1. What factors contribute to a team’s growing maturity in agile practices?
  2. What maturity levels do you see at a team level?
  3. What factors contribute to becoming an ‘agile’ or a learning organization?
  4. What maturity levels do you see at an organizational level?

In total, 86 people participated in the survey: 13 from the corporation I am currently supporting and an additional 73 participants from the Age-of Product mailing list.

How to Measure Agility: Preliminary Agile Maturity Indicators

From the answers, I derived the following taxonomy of indicators of agile maturity:

  • People and teams: Autonomy, Mastery, Purpose
  • Organizational Excellence
  • Technical Excellence
  • Communication & Collaboration

The slides of the presentation are available on SlideShare:

Let us dive deeper into the details of measuring agility:

People and teams: Autonomy


  1. Empower teams (Decisions, accountability)
  2. Focus on outcome
  3. Respect Scrum values (Commitment, focus, openness, respect, courage.)
  4. Safety to raise & discuss issues
  5. The team handles its own problems (No scrum mom.)
  6. Supporting each other as team members (Bonding.)
  7. Holding each other accountable (Agile is a team sport.)

Accountability (of the individual):

  1. Choosing tools & devices (e.g. software)

People and teams: Mastery


  1. Short feedback loops (User tests, customer development)
  2. Use of retrospectives
  3. Continuous team coaching (Guilds, code mentors etc.)
  4. Stakeholders live up to their responsibilities
  5. Hands-on experience over credentialism


    1. T-shaped people
    2. Active knowledge sharing
      • Continuous learning
      • No withholding of knowledge
      • Knowledge sharing beyond the product and tech realm
    3. Budget to attend conferences
    4. Center of Excellence for Agile

Team building:

    1. Cross-functional teams:
      • No dependencies w/ other teams,
      • End-to-end delivery capability
    2. Stable, long-living teams
    3. Support by an experienced scrum master

People and teams: Purpose


  1. Product discovery
  2. Product roadmap creation
  3. Release planning

Organizational Excellence


    1. Embrace and celebrate failure (Validate hypotheses by running experiments)
    2. Curiosity as a norm
    3. Undogmatic attitude, live Shu-Ha-Ri
      • Transparency:
      • Share information and data at all levels,
      • No more gated information or information brokers


  1. Focus on innovation, quality and business value (No more HIPPOism.)
  2. Supports of ‘agile’s way of working’ fully
  3. Enforces ‘agile’ as the core of the company culture
  4. Respect for roles, principles, and processes (The ‘real’ PO.)


  1. Managers to servant leaders
  2. Trust in people and teams
  3. Provides tools and facilities necessary to become agile
  4. Gemba and Kaizen become standard practices.

Organizational Design:

  1. Abandon functional silos for cross-functional teams
  2. Remove redundant middle management layers (Flatten the hierarchy)
  3. No more command & control, compliance driven management
  4. HR aligns with requirements of self-organizing teams
  5. The organizations morphs into a team of teams

Clear objectives:

  1. Shared vision among all actors
  2. Clear strategy
  3. Clear priorities

Business value focus:

  1. Customer centricity mindset
  2. Delivering business results
  3. Shifting the IT focus business needs
  4. From project budgets to product teams.

Technical Excellence

Engineering level:

    1. Built-in quality:
      • Code reviews,
      • TDD (Test automation, test coverage)
    2. Pair and mob programming
    3. Practicing Scrum, Kanban, XP.

Process level:

    1. DevOps: CI, CD (Deployment at will)
    2. Regular cadence of releases
    3. Identifying suitable metrics:
      • Lead time, cycle time,
      • Number of experiments,
      • Team health
    4. Open sourcing code.

Communication & Collaboration

Trust & respect:

  1. Benefit of the doubt for colleagues
  2. Safety to disagree
  3. Honesty
  4. Candid peer feedback.

Conflict resolution:

  1. Constructive disagreement (Disgree, but commit approach.)
  2. Non-violent communication.


    1. Zero tolerance for political games
    2. No scripted collaboration
    3. No incentives to withhold knowledge (Or information.)
    4. No finger-pointing, no blame-game.

How to Measure Agility of Organizations and Teams—The Conclusion

Measuring elements of agility at an organizational or team level is nothing new. This ‘agility assessment framework’ approach, however, is new as it aims to be the first open-source and thus widely available tool for all agile practitioners. It is unlikely that the first planned workshop will deliver more than a rudimentary prototype of the agility assessment framework.

However, it will be a start to gather more insights by applying the framework to real-life work situations and take it from there. Hopefully, we will be able to establish a community around the ‘agility assessment framework’ in the future.

✋ Do Not Miss Out: Join the 2,300-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.