Through my experiences in coaching teams on Agile and Scrum, I have come to categorize their maturity level into the rough categories below. I almost hesitate to call this an “Agile Maturity Model” because so many of the levels do not reflect strong Agile maturity. If it were up to me, the maturity model would not start until you are doing “Full On Agile.” However, the state of the industry is not there yet, and for those who are doing “Full On Agile”, this maturity model is going to be useless anyway. So, with reservations, I decided to still call it a maturity model, and I reserve the right to evolve the model as the industry evolves its own Agile maturity.
Which level below describes your team?
Instructions — go down the model from top to bottom, and pick the first description that describes your team well — that is the maturity level of your team. Note that this is simply a model based on my own coaching experiences and knowledge(hence the name, Bradley Agile Maturity Model), so take that for what it’s worth. You can also apply this model to your Scrum team by evaluating your team against *both* the Agile Manifesto and the Scrum Guide.
- Full on Agile
- Here, the team and organization is essentially fulfilling all of the value statements and principles of The Agile Manifesto. If you can go down the list of value statements and principles, checking off each one as faithfully executed, then you are doing Full on Agile. These teams, often far from perfect, are in a constant state of improvement, and many who faithfully improve and adapt will go on to be very successful. Be aware, though, that even “Full on Agile” teams can have small pockets of dysfunction or Organizational Constraints that will limit its success. Further, teams will still be presented with challenges, but the difference here is they will generally confront those challenges in a self organizing way and much more efficiently than the maturity levels below. Some of these teams achieve hyper productivity levels on the order of 200-400% higher than when they were “Non Agile”(see “Non Agile” below). Be careful here…”Full on Agile” is not the “end state,” it is simply a reflection of the team’s adoption of a disciplined Agile approach. From here, the team tends to focus more on software development practices and less on process(only tweaks). At this point, it becomes a state of “Excellence on the March!” so long as the team doesn’t get complacent and decide to plateau.
- Agile on the March!
- Here, the team and organization are not fulfilling one or more of the value statements and principles of The Agile Manifesto, but they are fully aware of that, and they are faithfully moving toward it by adapting their Agile approach to be closer to “Full on Agile.” It can be a fairly slow march, so long as it is a faithful one. Once the march becomes a “crawl” or has stopped altogether, your team has fallen into one of the maturity levels below. As long as the team is on the march, its success will almost assuredly increase as well.
- Half Baked Agile
- Here, either the team has plateaued (no longer on the march!), or it has only partially implemented Agile due to lack of Agile knowledge. This happens a lot with “Roll Your Own Agile” implementations or Kanban, but not as much with faithful implementations of more highly disciplined Agile approaches like Extreme Programming and Scrum. The team’s success has also most likely plateaued as well. In a sense, if the team is keeping customers and the organization happier than it was at one of the maturity levels below, then this is not all bad. In my opinion, it’s just a greatly missed opportunity for improvement, and is essentially settling for something just north of mediocrity.
- Faux Agile
- Here, whether done consciously or unconsciously, the team thinks it has implemented Agile but is so far out of line with the Agile Manifesto that is really just “fake”(or Faux) Agile. The team and organization has essentially failed at implementing Agile. The main reason this occurs is a severe lack of Agile knowledge, or the presence of people who “think” they know Agile, but are really just charlatans. Some organizations also fall into the trap of the Methodology Facade Pattern. Once knowledgeable people arrive, it can be difficult to put these teams back on the march to Agile, because the team and/or org is so proud of themselves for transitioning to (Faux) Agile. It takes truth telling, fearless change agents to put these organizations back on the right track.
- Anti Agile
- Here, the organization and/or team have become entrenched in practices that are absolutely hostile to Agile, and are probably just software or organizational dysfunctions in general(unrelated to Agile). Further, the organization and/or team is unwilling or unable to make regular progress on improving the situation. Things like preventing communication with customers, very poor technical practices, having teams that are way too large, too many silos, constantly changing priorities, too much command and control micro-management, refusing to give teams the tools and support they need to succeed, and too many large Organizational Constraints are all possible causes. It’s a wonder these companies stay in business, and many of them turn out to be rated near the bottom in terms of customer satisfaction. My advice to anyone working in a place like this is to leave and find a better place to work — IMMEDIATELY!
- Non Agile
- Here, the organization and/or team has never strayed from their traditional waterfall or RUP methods, and doesn’t intend to. Their success might be surprising, but it will very short lived as other competitors zoom past them on the march to Agile. These places are becoming more rare, because most organizations at least “fake” going to Agile (see Faux Agile above), but they do still exist.
What maturity level do you think your team is at? Did I miss a level? What maturity level do you wish your team was at? Sound off in the comments!