The Agile Maturity Model

Note: This blog is a companion to the talk given by Ravi Gujral and Shaun Jayaraj at Agile Philly http://www.agilephilly.com/Agile%20Maturity%20Model.ashx


The best way to start describing the Agile Maturity Model (AMM) is by talking about what it is not.

The AMM is not

• A mechanism to measure the performance of a team
• A pre-defined set of practices, whose adoption guarantees successful delivery of projects in time and within a budget
  

The AMM, in contrast, tries to quantify degree of responsiveness of a team to an organization's business needs. The philosophy being that increasing the discipline and proficiency of executing some best practices will increase the degree of responsiveness. The AMM primarily focuses on application development activities; the dimensions of the AMM are

• Testing
• Source code management
• Collective code ownership
• Collaboration
• Responsiveness to business
• Assurance and governance
• Story formation
• Design simplicity
• Build process
  

For each of the above dimensions, the AMM lists behavioral patterns exhibited by teams. Teams can use the AMM as a reference to identify and compare the behavior that they currently exhibit and plan to alter and tailor them.

For example the behaviors identified in the testing dimension are

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

Consider a team that develops websites. Their testing strategy is to only have manual testers test the application just before deploying it to production. All the tests performed by the tester are acceptance tests. This would put this team on the level of "Acceptance testing in lieu of all other tests"

Using the AMM this team can then introspect and choose to introduce unit testing as a best practice.


The AMM Dimensions

Let us now look at the various dimensions of the AMM and the behavioral patterns that are identified within each dimension. The behavior listed at the start of each dimension is an undesirable behavior and teams should try and move away from them as soon as possible. However to what extent a team would like to mature in a given dimension is the team's choice.

The practices can be classified as

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

Testing

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

Source Code Management

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

Collective code ownership

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

Collaboration

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

Responsiveness to business

1. Frozen specification, unresponsive to business value
2. Team tries to accommodate new requirements by ad hoc change requests ("pile it on")
3. Iterative process with sprints of length short enough to respond to business change
4. Showcases per sprint; business prioritizes functionality per sprint
5. 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
6. Business writes high-level stories for all requests; organizational story queue exists; prioritization decisions made from full story backlog
7. 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

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

Story Formation (Requirements)

1. Development tasks extracted from voluminous, frozen requirements artifacts
2. Production of lightweight artifacts (e.g. panel flows) to drive high-level requirements development
3. Mapping granular requirements (e.g., use cases) in high level user requirements
4. Marshaling use cases into discreet statements of functionality that can be delivered in time boxed development sprints
5. Stories are an expression of end-to-end functionality to be developed, including testable acceptance criteria and a statements of value
6. Spontaneous story development provided by business for in-flight projects; stories not derived from extant sources but are immediate expressions of customer demand/need
7. Global repository of functional requirements for stories developed by business for any business requirements, including a formal measure of business value delivered

Simplicity

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

Build

1. Ad-hoc build requests; scripting and component marshalling performed manually
2. Consistent, repeatable build process with durable artifacts executed manually with each release
3. Build is automated, executed on a timed basis
4. Unit tests are integrated with the automated build; team is constantly notified of the status of the build; build triggered by SCM updates
5. 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
6. All product components advertise dependencies; master repository established
7. Product integration tests included; build process executes automatic deployment to QA testing environment

Conclusion
We will be talking about the above AMM model during the Agile Philly and discussing the interconnections between the various dimensions.

Ackowledgements
Ross Pettit , Gerg Reiser, ThoughtWorks Inc.

Related Blogs and Articles

1. An "Agile Maturity Model?" by Ross Pettit http://www.agilejournal.com/component/option,com_magazine/func,show_article/id,44/
2. Agile made us better but we signed up for great By Ross Pettit http://agilemanager.blogspot.com/2008/06/agile-made-us-better-but-we-signed-up.html