One of the tenets of agile software development is continuous improvement. Not just any kind, mind you: continuous improvement by the people who do the work.
As Martin Fowler puts it, a key part of any agile practice is “the notion of thinking about what we’re doing and how we can do better, and it is the team that’s doing the work that does this, that is the central thing.”
And it’s in this spirit of continuous improvement—driven by teams—that the following article presents a simple tool that puts teams (not you and me) in charge of continuous improvement.
But first, for comparison purposes, let’s touch on another tool that’s meant to help teams improve: maturity models. In theory, it makes sense to use a maturity model.
In theory, theory and practice are the same. In practice, they are not.”
Maturity Models
Thanks again to Martin Fowler, there’s already an introduction to maturity models that’s worth reading: Maturity Model.
Maturity assessments get a bad rap, and for good reason.
The terms “maturity” and “assessment” don’t help because, really, who wants their maturity assessed? Imagine for a moment: would you want to be judged by someone else based on some arbitrary set of criteria?
But terms and feelings aside, the bigger problem lies in the very nature of software development: software development is creative work and, to complicate things further, creative work with a wide variety of technologies, tools, and practices that never stop to evolve. So there’s really no “mature” state to shoot for, and even if there were, there’s no one best way to get there.
Take Scrum for example. For one team, a sign of “maturity” may be how good they are at following the Scrum Guide. And for another, it may be how good the team is at not following the Scrum Guide, because they found other ways that work better for them.
Sure, you can always loosen up the assessment criteria of a maturity model and turn them into general principles. But then, the maturity model will become subject to interpretation and lose its benefits as a concrete, actionable guide.
And maturity models raise another problem: management love metrics (I do too) and will likely find it reasonable to use (not to say impose) a one-size-fits-all maturity model as a concrete way to measure progress. And when that happens, teams will, in turn, find it reasonable (or necessary) to do things just to meet the model’s criteria, even if only superficially.
When a measure becomes a target, it ceases to be a good measure.”
—Charles Goodhart, Goodhart’s law
That said, maturity models aren’t all bad. Some, like the Agile Fluency Model, can be useful—as long as you use them judiciously.
All models are wrong, but some are useful.”
—George Box
Alternatives to Maturity Models
True, continuous improvement is a basic principle that’s already baked into agile ways of working.
Whether you simply think of it as Reflect and Improve, or whether you dedicate a regular Retrospective meeting to it, you are technically all set as far as continuous improvement is concerned.
And so, one can argue that with the right people—the part you should really focus on—you’ll reach your own state of maturity. Not only that, you’ll keep improving from there. No fancy maturity model required.
But in reality, as your organization grows, it starts to make sense to have a simple continuous improvement framework that everyone can benefit from.
Enter:
The Quest
As an alternative to maturity models, consider the Quest template—a simple solution that puts teams in charge of their own continuous improvement practice.
Along with this sketch, here’s a set of guidelines for you to consider as you create your own template.
Guidelines
The template is for teams, first and foremost, and people who support them.
The template is organized into columns, each serving a different purpose:
- A list of items, or “quests,” serves as the team’s own continuous improvement guide.
- Colors (or a Likert scale) show the team’s take on its progress toward achieving each item on the list.
- Arrows indicate change, whether the situation’s improving or declining.
- A symbol (star) highlights the top items the team wants to focus on.
- Another symbol (triangle) calls attention to items beyond the team’s control that require a broader effort to address.
The template prioritizes autonomy and diversity over consistency, empowering groups of teams (say, 3 to 9 teams) to create their own list of quests.
Quests can be as high-level or specific as teams prefer—ranging from values and principles to areas of focus, general practices, or practices within practices.
The list of quests is short and evolves over time as teams complete quests and shift their focus to what’s most meaningful and relevant to their current situation.
Continuous Improvement Catalog
Here are some additional guidelines to foster a more deliberate continuous improvement practice:
Practice leads can curate a concise catalog of continuous improvement items from and for the teams. This catalog, along with its taxonomy, organizes items at different levels into categories such as management practices, engineering practices, organizational structure, and organizational culture.
Practice leads can facilitate meetings with teams to initially fill out the template and regularly update it (for example, quarterly), using the catalog as a reference.
Practice leads can encourage teams to maintain a broad perspective by ensuring they have at least one continuous improvement item in each top-level category.
In the spirit of continuous improvement, teams should always include items where they consider themselves “amber” or, even better, “red.”
For each continuous improvement item, the catalog can provide teams with resources to use and subject matter experts to contact. And the other way around, teams can contribute to the resources and volunteer as subject matter experts to assist other teams.
A Quest for True Agility
It’s tempting to go with a prescriptive maturity model and measure “agility” en masse across dozens or even hundreds of teams. The Quest template offers an alternative for teams striving for true agility—the “agile native” way.
With the Quest template (or your own variation), teams can embark on their own quest, think for themselves, and approach continuous improvement with both creativity and discipline: Make your own resolutions and keep them, set your own goals and reach them.
—
Featured Link: Check out how Spotify used a similar template: the Squad Health Check. The article provides valuable insights and practical tips.
