"Essentially, all models are wrong, but some are useful." George E. P. Box, statistician and founder Center for Quality and Productivity Improvement at University of Wisconsin-Madison.
Word on the street says James Shore and Diana Larsen have developed an AMM (Agile Maturity Model) and are proposing standards and levels for Agile, along with all the attendant assessment and certification schemes.
Not true! And here's why: we've road tested and published a model focused on benefits and tradeoffs, not judgmental labels of maturity and immaturity.
About three years ago, we (James Shore and I) began a deliberate review of the ways we were teaching and coaching methods and techniques for incorporating Agile principles and practices in the work of teams. A series of experiments led us to create a draft model.
We vetted the model with reviewers and revised it iteratively until we felt it was ready–that is, useful enough–for broader distribution. In August 2012, Martin Fowler published our article describing the Agile Fluency model, "Your Path through Agile Fluency" on his website.
“We’ve observed that Agile teams develop through four distinct stages of fluency. Fluency is how a team develops software when it’s under pressure. Anyone can follow a set of practices when given time to focus in a classroom; true fluency is a skilful, routine practice that persists when your mind is distracted with other things.
For Agile, we’re considering team fluency rather than individual or organizational fluency. Agile development is fundamentally a team effort, and your organization’s success with Agile will depend on the fluency of your teams.
Team fluency depends on more than just the capability of the individuals on the team. It also depends on management structures, relationships, organizational culture, and more. Don’t make the mistake of blaming individuals for low team fluency, or assuming that one highly-skilled individual will guarantee high team fluency.”
In short, the Agile Fluency path winds through four variations on Agile teams that we've seen repeatedly across many organizations. We named the variations: Focus on Value (1 star), Deliver Value (2 star), Optimize Value (3 star), and Optimize for Systems (4 star). Our experience showed us that different organizations seemed to find a match for their teams and their business needs in each variation. We also noticed that teams that aspired to 2, 3, or 4 stars seemed to gain fluency in a predictable pattern of first gaining skill at teamwork and focusing on business and customer value, then building enough engineering expertise to deliver value on the market cadence, and so on.
People ask: Is the Path through Agile Fluency a Maturity Model?
Since that time, we've felt both gratified by our colleagues' positive feedback and challenged by assertions that we've created an Agile maturity model. Viewpoints on a new maturity model varied. Some cried foul! Some applauded! Had we inadvertently created a maturity model? It was never our intention. Imagine our dismay.
Probably the most well-known "maturity model" (MM) in software development is the CMMI (Capability Maturity Model Integration)–a mashup of the CMM and other MMs. Some folks assert that it's a framework for business process improvement, or rather a model for building process improvement systems, for development, acquisition, and services. "Without some insight into and control over their internal business processes, how else can a company know how well they're doing before it's too late to do anything about it?" ask the good folks at the website.
Well, maybe because, "The projects most worth doing are the ones that will move you DOWN one full level on your process scale.” (DeMarco & Lister, Peopleware) In addition, the focus on codified best practices has come under fire as a one-size-fits-all solution in a world where no two development projects or sectors of the industry are similar enough to warrant a blanket approach.
In a triumph of circular reasoning, another accreditation body (and seller of certifications) says, "Maturity is indicated by the award of a particular 'Maturity Level'." We wonder if they've noticed how ludicrous and self-serving that sounds?
In a mashup of all the definitions we could find, we find maturity models have:
- a focus on process improvement systems
- structured levels of “best practices” benchmarks for behaviors, practices, and processes
- uses including comparative assessments and aids for understanding those comparisons
By that definition, our model is NOT a maturity model. First, we describe equally viable stops along a path, rather than hierarchically ascending levels of good, better, best teams. The model is not meant to reflect process improvement, so much as indicators of shifting team focus and organizational investment. Second, while we did intend the Agile Fluency model would describe observable behaviors, including practices and processes, we certainly did not intend our observations to be used as an after-the-fact comparative assessment. Oh horrors!
Far from using the model as another tool with which to bash teams for their "lack of maturity," we wanted to create a technique for setting and achieving team-specific aspirations that are best fit for purpose in whatever situation your team finds itself.
Finding Your Destination on the Path
At XP2013 conference in Vienna, Diana said, "Venice isn't better than Munich just because it's further down the roadway, particularly not if you're looking for Oktoberfest! On the other hand, if you're looking for lavish carnival, Venice is your spot, and you'll be wise to spend the extra fuel to get there." In Oregon she says, "When traveling Interstate Highway I-5 south from Portland, getting to Ashland with its wonderful, year-round Shakespeare Festival is not better than Salem just because it's further on, if what you need is to do business in the State Capitol."
Similarly, a two-star team is neither more or less good than a one-star or three-star team. It all depends on context and, more specifically, fitness-for-purpose. Perhaps it would have been clearer if we had named our Path to Agile Fluency for locations in a park (though stars are easier to find in the icon libraries). We could have chosen names like: the parking lot team, the play ground team, the sports field team, and the hiking trail team. Choosing an area of the park depends entirely on your preferred activity. On the way to the playground, you'll likely have to park the bike or get off the shuttle in the parking lot, and you may have to take the path by the playground before finding your way to the sports field. However, continuing further on to the hiking trail makes no sense if you really wanted to enjoy the swing set and seesaw at the playground.
To use our Agile Fluency model effectively, we recommend as a first step that you let go of the idea of team maturity or of judging the team on anything other than delivering business benefit. Instead, take the time to understand both:
- what kind of benefits do you want and need from your team?
- what investments and trade-offs are you willing and able to make?
Stars or Park Locations?
One Star (or Parking Lot) - Do you really need a team that can focus on creating business and customer value? Do you need people who can collaborate on planning, prioritizing, and working to achieve value? Do you want to be able to tell at a glance whether or not the team is making progress toward your delivery goals? If that’s enough for you and will serve your purposes, a team fluently proficient at one star is your best fit. Invest in developing a strong, trusting, collaborative team and a work process design (like Scrum, Kanban, Scrumban) that focuses on prioritizing work by the value it will deliver.
If that’s exactly what you need, then plan for and invest in building a team culture. You’ve found the right destination. Stop here. But maybe that’s not the best fit for you. Then, consider investing differently.
Two Star (or Playground) - Do you need the value-focused benefits a one-star team offers and also have customers who demand low or no defects and predictable delivery on a regular, defined cadence? Then you'll need to invest in hiring or, more likely developing, team members who have skill in engineering techniques like continuous integration, TDD, pair programming (or pair everything), continuous deployment, and collective ownership (from Extreme Programming, Software Craftsmanship, DevOps, etc.). The trade-off of lowered productivity while the team gets great at its craft will be worth the cost, because the high payoff is critical to the business.
Most organizations we've worked with find sufficient value with two-star teams. However, many Agile coaches, thought leaders, and a few business people (including us) would like to see a more ambitious implementation. That may or may not be better for the team and the organization.
If that’s exactly what you need, then plan for and invest in building a team culture and developing team members’ technical skills. You’ve found the right destination. Stop here. But maybe that’s not the best fit for you. Then, consider investing differently.
Three Star (or Sports Field) - Do you need all the benefits of a two-star team plus the satisfaction of knowing that your development effort captures all the possible value in its product? Do you want a team (or teams) that understands your business and customer needs so well that they can contribute innovative product development ideas? Are you willing to give the teams continuous access to business knowledge and build trust between the software developers, product developers, and business strategists? Will you assign dedicated product manager/owner expertise (in the form of an individual or a sub-group) to every team for ongoing customer and product discovery? (Ideas from Lean Startup are helpful here.) The benefits of Three-star fluency are often sold as the "promise of Agile," in spite of the daunting challenges of changing organization structure, redefining management roles, and shifting administrative and operational procedures–which are all necessary to implementing Three-star Agile Fluency. (Tip: Mistrust any OD consultant or Agile coach who tells you this will be simple, fast, and easy or doable by a lone Scrummaster.)
If that’s exactly what you need, then plan for and invest in building a team culture, developing technical skills, and shifting your organizational design. You’ve found the right destination. Stop here. But maybe that’s not the best fit for you. Then, consider investing differently.
Four Star (Hiking Trails) - Do you see value in a development team that becomes an integral part of how the organization does business, offers innovative ideas for new products, and engages in conversations about direction setting? Do you want teams that can set aside their own prioritized work to make space for initiatives more important to the whole company? Are you eager to give team members a seat at the decision-making table because you trust they understand how every decision affects every stakeholder in the company? If you aren't a small startup, are you willing to make the investment in a wholesale culture change? Some folks call this "Beyond Agile," and we've suggested it's where Agile could be headed as the community continues to evolve its understanding of Agile possibilities.
The park location names may illustrate our intent better, but we find stars easier to remember, if you can also stay aware that more stars is not necessarily better for you, your organization, your situation. What's best is the right fit for your purposes and your ability and willingness to invest time, effort, funding, and social capital to accomplish the shift.
Plan Your Team Investments
Maturity models point us in the wrong direction, toward evaluation that measures activities rather than results. Agile, with its emphasis on delivering customer, and therefore business, value keeps our eyes on the prize: producing and maintaining high quality, useful, market-driven software. We’ve seen high returns for companies that identify the variety of Agile Fluency that fits their needs, then make the associated investments in culture, training, and structure. We hope the Agile Fluency model will prove to be one of those models that, while not entirely true, still contributes usefully. We offer it as way of thinking about and planning investments to create the conditions of Agile that best fit your development effort, business need, and customer value.
About the Author
Diana Larsen, founding partner of FutureWorks Consulting, focuses her work on Agile software development, team leadership, and Agile transitions. Deeply in tune with how work teams grow, adapt, and develop, she co-authored Agile Retrospectives: Making Good Teams Great, Liftoff: Launching Agile Teams and Projects, QuickStart Guide to Five Rules for Accelerated Learning, and the article, “Your Path through Agile Fluency: A Brief Guide to Success with Agile”