One of the tenets of agile is continuous improvement. Not any kind of continuous improvement, 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 is in this spirit of continuous improvement—driven by teams—that the following article presents the “Quest”: 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 reality…
In theory, theory and practice are the same. In practice, they are not.”
Agile Maturity Models
Thanks again to Martin Fowler, there is already an introduction to maturity models that’s worth reading: Maturity Model.
Maturity assessments get a bad rap, and deservingly so.
The terms “maturity” and “assessment” don’t help the situation because really, who wants their maturity assessed? Just imagine for a moment: would you, yourself, want to be judged by someone else, based on their own arbitrary set of criteria?
But terms and feelings aside, the bigger problem is 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 is really no “mature” state to shoot for—and even if there were, there is no one best way to get there.
Take Scrum for example. For one team, a sign of “maturity” may be how good the team is 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 overall progress. And when that is the case, teams will in turn find it reasonable (or necessary) to do things just for the sake of meeting criteria in the maturity model, if only superficially.
When a measure becomes a target, it ceases to be a good measure.”
—Charles Goodhart, Goodhart’s law
That said, to be fair, maturity models are not all bad. Some maturity models can be useful (the Agile Fluency Model, for example) as long as you use them judiciously.
All models are wrong, but some are useful.”
—George Box
Alternatives to Agile 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 periodic 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 will get to your own state of maturity. Not only that, you will continue to get better from there. No fancy maturity model required.
But in reality, as the size of an organization increases, it starts to make sense to have a simple continuous improvement framework that everyone can benefit from.
Enter…
The Quest Template
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 is a set of guidelines for you to consider as you create your own version of the template.
Guidelines
The template is for teams (first and foremost) and people who support teams.
The template has different columns for different purposes:
- A list of items (“quests”) serves as a continuous improvement guide (the team’s own guide).
- Colors (or some sort of Likert scale) show the team’s take on where it stands in achieving its goal for each item on the list.
- Arrows show change (getting better or worse).
- A symbol (star) shows the top items that the team wants to focus on.
- Another symbol (triangle) calls attention to items that go beyond the team’s control and require a concerted effort to address.
The template encourages autonomy and diversity over consistency; it empowers groups of teams (say, 3 to 9 teams) to come up with their own list of continuous improvement items.
The items are as high-level or as specific as teams want them to be: values, principles, areas of focus, general practices, practices within practices, etc.
The list of items is short and changes over time, so teams put their focus on the items that are the most meaningful and relevant to them and their current situation.
The items can be organized into categories, so teams can think both broadly (for example, “agile framework”) and specifically (for example, “sprint churn”).
Teams can capture the items that they have conquered (“quest badges”) and revisit them when they want.
Different groups of teams can choose to create their own version of the template.
And no, managers can’t use the template to judge or compare teams.
Continuous Improvement Catalog and Coaching
Next are some additional guidelines for a more deliberate continuous improvement practice:
Practice leads can curate a concise catalog of continuous improvement items from and for the teams; the catalog and its taxonomy keep items organized at different levels into categories (for example, management practices, engineering practices, organizational structure, organizational culture).
Practice leads can facilitate meetings with teams to fill the template the first time and update it on a regular basis (say, quarterly) using the catalog as a reference.
Practice leads can encourage teams to keep a broad perspective by having at least one continuous improvement item in every top-level category.
Practice leads can encourage teams to replace continuous improvement items that they have conquered with new items outside their wheelhouse; in the spirit of continuous improvement, teams should always have items where they consider themselves “amber” or better yet, “red.”
For every continuous improvement item, the catalog can give teams resources they can use or subject matter experts they can contact. And the other way around, teams can contribute to resources and sign up as subject matter expert to help other teams.
Different groups of teams can choose to create and curate their own catalog, or they can choose to do this together with other groups of teams.
Reference
Check out how Spotify used a similar template: the Squad Health Check. The article contains good insights and concrete tips.
Final Thoughts
It’s tempting to go with a prescriptive maturity model and roll out “agile” en masse across dozens or hundreds of teams. The Quest template is an alternative for teams seeking true agility—the “agile native” way.
With the Quest template (or your own variant), teams can embark on their own quest, think for themselves, and approach continuous improvement in a way that’s both creative and disciplined: Make your own resolutions and keep them, set your own goals and reach them.
