Our well-meaning agile coach’s maturity model was based, either deliberately or subconsciously, on Shuhari, a Japanese martial arts concept involving three stages of mastery: “first learn, then detach, and finally transcend.”
Many well-meaning agile proponents have devised various scales to measure agile maturity, not unlike the Capability Maturity Model (CMM). A Google search for “agile maturity model” returns a fair number of results, including a blog post whose title, “Yet Another Agile Maturity Model,” suggests their unwillingness to disappear. The intended goal of such a model is to help managers, developers, and coaches assess the effectiveness of their company’s transition to agile methods, and to highlight which practices need further development.
We have no problem with the notion of a team wanting to understand areas in which they need improvement. But we also think most teams have a sense of what they’re doing poorly. A good coach can spot these same problems in short order, although it usually takes longer to understand root causes.
Practice-Driven Scale vs Goal-Driven Scale?
At one company, an agile coach introduced a five-level maturity model, very much like the CMM. The scale was backed by a checklist oriented toward goals, not practices. At the lowest maturity level, the goal was basic education and understanding of agile. At the highest level, the expectation was that the team continually assessed and improved themselves. Well, that’s agile, right? All practices, principles, and values aside, if your team isn’t continually seeking improvement, you’re not agile.
While the intention for the model was noble, unfortunately it ended up being used for nefarious ends. Although it was dreamed up by a respectable agile coach in one organization, an executive in another organization appropriated the scale and began to use it to grade teams. Insidiously, the perception of agile shifted from a team-centric mechanism to a top-down governance scheme.
The thing that worries us most about agile maturity models is the idea of consistent scale. Standardization is a good idea, and indeed we always seek some level of standardization within an agile team (see our Coding Standards card for an example). But across teams, not so much: it’s simply pointless to seek the same progress on the same scale with different people all working to the same end state.
It is hard to imagine that software developed for different types of products, by teams with varied experiences, for deployment in different regulatory environments, or for different markets should operate in precisely the same way or conform to the same metrics. It is rather unlikely that two different teams would optimize the same way, let alone all of the teams within a corporation.
Still, it is not wrong for a company to want to measure the accomplishment of its people. What if we rate according to proficiency at agile practices like TDD or pairing? That measurement certainly has more meaning than counting lines of code per week or “stays later than his coworkers.” But it can also be damaging if, for example, you unfairly pit the Python team doing greenfield development against the C++ team struggling with a large legacy code base. It may also be meaningless: A team might have produced the best possible code using TDD and yet still fall down when it comes to delivering on customer expectations.
The most useful measurements of a team’s ability are necessarily customer facing. Look at Running Tested Features (RTFs), defect counts, consistency of delivery, and customer satisfaction metrics, all directly related to how well the team can deliver quality software. Measure the trends over several releases. And remember that it’s still meaningless to compare these numbers across teams—it provides no value to the customer. It will definitely not improve the team’s capacity, and may even demoralize them.
Instead, to understand your maturity, look inward. Your goal is to improve yourself and your team, not keep up with the Jones’s team. The empowered, energized team is best characterized by the self-awareness of need and the desire to improve both team and product.
One scale that seems to have some meaning (though no certification body and no way to standardize) is Shuhari, a simple—but romanticized and mythologized—concept. Our well-meaning agile coach’s maturity model was based, either deliberately or subconsciously, on Shuhari. Both scales are focused on stages of learning.
Shuhari is a Japanese martial arts concept (also encountered among players of Go and is actually built upon three Japanese words, thus three stages of mastery, that roughly correspond to the phrase “first learn, then detach, and finally transcend.”
At the shu stage, the student copies the master’s moves as perfectly as possible. The mentor corrects the student if the movement is imperfect, inefficient, or ineffectively performed. A student really has very little self-expression, but is being schooled in the fundamentals of the art. When the student has reached a solid level of mimicry, he has learned what to look for in form and balance and style and posture. He is competent enough as a novice, yet his knowledge is more memorization and even muscle memory. He is aware of his movements and knows he is “doing them right.”
This is how we often began agile transitions. We started with strict workflow, strict practices, scheduled pair programming, rules, and strictures. Stand-up meetings were strictly three questions, and we sometimes limited attendance to only those producing the software (pigs v. chickens). We may have placed restrictions on hours worked per week. We programmed in pairs and conducted workshops on refactoring, TDD, planning, etc. The goal of the training and coaching was to deliver fundamental theory and guide students to proper form and practice.
When a team produces consistent results using rigid methods, they have completed their shu stage. It is better to reach shu than not to reach it. It is better still to go beyond the kinds of things that can be measured with a practice-oriented Agile Maturity Model.
A budding martial artist will move from the shu to the ha stage. In this stage, he or she understands the principles well enough to depart from rigid mimicry and try different variations. Because he knows the accepted forms and their purposes, he may notice the difference in effect between his experimental way and the way he was taught. If his departure works less well, he returns to the way of his teaching. If his variation works better for him, he may retain it. This stage involves experimentation and observation, and in time the techniques become his own.
In our agile transitions, we try to quickly reach a point where the team can retrospect and make measured improvements on its own practices. If those changes don’t pan out, they are abandoned or modified. A coach still provides value at this stage by helping keep the team mindfully measuring their changes and not falling back on old habits. The more a team becomes self-directing, the less they need a full-time coach.
In the ha stage, teams often will start to innovate in the way they close their feedback loops, the data they use in their big visible charts, and the way they design their software. They may adopt different tools and different protocols in dealing with each other. The ha stage will include some successes and some failures, but the team will be wiser with each experiment.
Meaningful retrospectives are critical if the team is to reach ha. Some teams will reach shu, then abandon retrospectives and cling to the rules. Such teams are practicing Scrum or XP (or what-have-you) mechanistically, and will rarely move forward. This stagnation may require a coach change to re-trigger the team’s interest in improvement and self-management.
As the team matures in the ha stage, it’s perfectly reasonable for them to depart from purely Agile concepts. They may adapt more techniques and concepts from the Theory of Constraints or Lean. They may adopt the Pomodoro technique or features from Getting Things Done. They may create or adopt new build and test tools. They may begin to adopt portfolio management and prioritization techniques they had never considered before. They may automate more of their processes.
Some leaders may take advantage of increased freedom to push their teams to return to pre-agile practices, all the while declaring themselves to be “post Agile” without ever internalizing the principles. They will abandon practice and principle alike. A coach can tell progress from abandonment.
In the ri stage, the martial artist has reached a point of mastery. Her reflexes and thinking are well-formed and she requires little conscious guidance to carry out combinations of movements. She is largely free from slavishly following old forms, in that the forms have become second nature (tacit knowledge). She is able to teach and to adapt to new situations easily.
At the ri stage of an agile transition, the team becomes capable of abandoning rules and strict forms. They can produce quality work, groom the code base, and satisfy customers because it is their collective will to do so, and because they have built and tested their own body of rules and practices. They may discover ways to transform their work system that their coaches never considered.
The ri stage is the goal of agile team, coach, and company who have sought to honestly pursue this type of work system.
Shuhari is the progression through these three stages. The Shuhari progression helps a team develop its ability to deliver value, but it makes the very term “agile” start to look pretty nebulous. Is a team that no longer follows the practices non-agile, or post-agile, or just advanced agile? How do we measure relative agility of one team against another? How do we reward teams who have become agile? How do we correct those who don’t get it?
Measurement and comparison, as we’ve mentioned, are not very important. The real questions are whether the quality of delivery is improved, and whether the organization as a whole is delivering value to the customers in an effective way. Far from blurring the term “agile” to mean merely “good,” Shuhari defines agile as one way to do good things well. When we find better ways, you’ll hear from us.
Jeff Langr has been building software for over a quarter century. He is the author of Agile Java and Essential Java Style, plus more than 80 articles on software development and a couple chapters in Uncle Bob’s Clean Code. He runs Langr Software Solutions from Colorado Springs and happily builds software as an employee of GeoLearning.
In addition to developing the Agile in a Flash card deck with Jeff, Tim Ottinger has over 30 years of software development experience including time as an Agile coach, OO trainer, contractor, in-house developer, and even a little team leadership and management. He is also a contributing author to Clean Code. He writes code. He likes it.