Agile Maturity Model


The Agile Development methodology is pretty popular in the software development world. The main point of Agile is to allow teams to create, test, and deliver with agility. In my opinion, the tools and processes are a template which you have to tweak and implement considering factors like team cohesion and company culture, among other things.

Having worked with a large number of teams within organizations of different sizes, I have observed the teams have different levels of maturity. Similar to the Capability Maturity Model, here are the five levels of the Agile Maturity Model and their characteristics.

Agile Maturity model

Alt Text

Level 1 "Initial": The boss says, “Let's go Agile.”

Teams who are more focused on methodology instead of Agile. Tasks are broken down and assigned to sprints. Daily standups are simply "status reports" for managers. No retrospective meetings. No sprint planning/retrospective meetings. No sprint demos. Sprint plans decided by managers. Low team decision making. Typically this is a "lipstick on a pig" situation (where the the metaphorical pig is something akin to the waterfall model). No involvement from non-engineering stakeholders.

Level 2 "Forming": “Let's try to figure out Agile.”

Low team decision making, but there is some stakeholder involvement. Sprint demos are held, and managers change sprint plans based upon stakeholder feedback. Managers are still in control. No retrospective meetings (or these meetings are only held when the goals of the sprint are not achieved).

Level 3 "Performing": “We need to plan our next three sprints effectively.”

The team is getting into the rhythm of delivering sprints on a regular schedule. Standups and retrospective meetings are held regularly. Stakeholders are engaged and available to answer questions, and their feedback is incorporated during sprint planning.

Level 4 "Empowered": “We need to get this epic out by the next sprint.”

This is the level where the team is actively engaged in the planning, estimation, and execution of sprints and the project. Typically we see this in teams with high cohesion and trust. Also typically, this is a cross-functional team with all stakeholders actively involved. The team gets the big picture. Once your team members start planning in terms of, "We can complete story A, but this will mean story B must be dropped" or, "We can push to get story C, but it is going to impact quality of the product,” you know that you have an empowered team.

Level 5 "Optimizing": “Let's use Planning Poker to get better estimates.”

Empowered teams who continuously evaluate and adapt. This includes not only the sprint retrospective, but evaluating the Agile methodology as well as the processes used in the team. Has the team grown too big? Have we outgrown the tools that we are using? These teams are evaluating different estimation methods.

I have observed teams at different levels in companies of all sizes, from startups to corporates. Team trust and cohesion is a necessity, but not a sufficient condition to get a high performance, agile team. The culture within the team has a huge impact, as does the leadership team in place.

Category: Agile, Software Engineering