Agile Maturity Model

One day in a management meeting, my boss ask all the team leaders “what is the current agile maturity level of your teams” ?

This is a hard question. We said that we still are not perfect, but we think we are in the good way, of course.

Agile maturity level ?

With that question in mind, I searched a little bit over the internet. I’ve not found so many literature.

The first article i found is The Agile Maturity Level (AMM). Scott W. Ambler proposes 5 stages of maturity, defined as:

Level 1 of the AMM is the Rhetorical stage

Level 2 of the AMM is the Certified stage

Level 3 of the AMM is the Plausible stage

Level 4 of the AMM is the Respectable stage

Level 5 of the AMM is the Measured stage

This article is quoted in some blog posts, and is kind of interesting, but with the definition I cannot assess the level of maturity of my teams.

Then I found another blog post citing an entry in the “agile journal” that is sadly a dead link. The idea is to define 10 dimensions including project management, requirements, development and configuration management, and identified consistent patterns of progression – or maturity – in the way people and teams move toward more agile practices.  I like the radar chart using these dimensions.

Finally I’ve found this definition of 9 dimensions with rules for assessment of maturity level.

Agile Maturity Model : an assessment definition

With little modifications, I defined my dimensions and levels, using this scale:

0 Regressive
1 Neutral or Chaotic
2 Collaborative
3 Operating (Consistent exhibition of competance)
4 Adaptive (Expertise to adapt to change)
5 Innovating (Creative evolution of practice, and spread these practices throughout the organization)

Here are my levels (largely inspired by the cited website):

0 No unit testing framework, ad hoc testing (Manual testing of individual components/ controls)
1 Unit testing, manual functional testing; application has a testable architecture
2 Unit testing integrated into build process, testing automated as much as reasonable given application
3 Developers write unit tests before writing functional code
4 Test are identified and produced as part of a story creation
5 Automated functional testing (e.g.. GUI testing); stories remain in development until all bugs are fixed or deferred

Source code management
0 Traditional schemes based on fire-locking and time-sharing
1 SCM supports version of code
2 IDE(s) integrate with SCM; developers include meaningful comments in commits
3 SCM support merging; optimistic check-ins
4 SCM support atomic commits
5 SCM is transparent to delivery team, behind build process

Collective code ownership
0 Knowledge held by specific team members; people work in isolation
1 No pairing, people work alone, some informal process for keeping people informed
2 Pairing scheme ensures rotation
3 Team signs up for functionality rather than assignment to individuals
4 Within an iteration, functionality delivery is signed up for just in time
5 Old (bugs) and new functionality is queued, development team pops the stack in real time

0 Regular progress updates from management to the delivery team (as opposed to the other way around); irregular team meetings
1 Project collaboration tools (wiki, mailing list, IM) in place and used throughout project team; project status published and visible to all
2 Daily stand-ups and sprint meetings; problem solving is bottom-up as opposed to top-down; team sets sprint objectives and agrees on estimates.
3 Integrated, continuous build process, with build status notification to the team and collective responsibility for state of the build
4 Business is part of the team, stakeholders accept working software at reviews in lieu of other tracking or progress metrics
5 Build automatically deploys to QA environment available to any interested party

Responsiveness to business
0 Frozen specification, unresponsive to business value
1 Iterative process with sprints of length short enough to respond to business change
2 Showcases per sprint; business prioritizes functionality per sprint
3 Continuous involvement of the business on the team: business certifies story complete out of dev; involved in (rather than approval of) story definition and acceptance tests
4 Business writes high-level stories for all requests; organizational story queue exists; prioritization decisions made from full story backlog
5 Development process is integral to business initiatives; development teams work as a part of the business unit rather than as a service to the business unit

Assurance and governance
0 Status reports document progress; schedule acts as plan
1 Sprint planning is introduced
2 Plan becomes communication and tracking tool rather than an exception report
3 Every sprint review examines value delivered and assesses next sprint by need, priorities (and delivery)
4 Organizational adoption: Introduction of Portfolio Planning and global optimization of resources (use of metric and standard measures)
5 Business review of value and return helps teams on regular basis based upon status

0 Development tasks extracted from voluminous, frozen requirements artifacts
1 Production of lightweight artifacts (e.g. panel flows) to drive high-level requirements development
2 Mapping granular requirements (e.g., use cases) in high level user requirements
3 Marshaling use cases into discreet statements of functionality that can be delivered in time boxed development sprints
4 Stories are an expression of end-to-end functionality to be developed, including testable acceptance criteria and a statements of value
5 Global repository of functional requirements for stories developed by business for any business requirements, including a formal measure of business value delivered

0 Big up-front design that attempts to accommodate all potential future needs
1 Application of fundamental design patterns
2 Structural refactoring to decouple application architecture
3 Aggressive and constant refactoring to improve code quality/simplicity extant code
4 Spiking solution with each release to introduce new ideas and challenge architectural decision
5 Technical design decisions taken with each story

0 Ad-hoc build requests; scripting and component marshalling performed manually
1 Consistent, repeatable build process with durable artifacts executed manually with each release
2 Build is automated, executed on a timed basis
3 Unit tests are integrated with the automated build; team is constantly notified of the status of the build; build triggered by SCM updates
4 Test and metrics (e.g., code quality, complexity, check style, etc.) are integrated as gatekeeper events; build data archived and reported in build portal/dashboard
5 Product integration tests included; build process executes automatic deployment to QA testing environment

Agile maturity model in action

I’m not yet fully happy with that, but that’s a start. With that tool, I’ve assessed the agile maturity level of one of my teams in this format:

agile maturity model in action


For the record, I did not get any follow up by my boss. But nonetheless I have now paths for improvement in my teams


, Agile, Management

Leave a Comment

Your email address will not be published.

+ seven = 11