.NET Rocks episode 460 had Scott Ambler talking about his APMM.  Here's the link to his blog entry on APMM, and I also repost some of that content here.

The Agile Process Maturity Model (APMM)

The goal of the Agile Process Maturity Model (APMM) is to provide a framework which provides context for the plethora of agile methodologies and practices out there today. The APMM defines three levels, each of which build upon each other, for agile processes and practices. At IBM we’ve found that many customers find the agile message confusing, in part because of the multitude of voices within the agile community but moreso because the agile rhetoric often seems to ignore or gloss over many important issues which our customers face on a daily basis. Hence the need for something like APMM to provide badly needed context for agile methods and practices


APMM Level 1: Core Agile Development
Level 1 agile processes address a portion of the system life cycle (SDLC). Examples of Level 1 agile processes include:

• Scrum. The focus of Scrum is project leadership and requirements management. Scrum proponents claim that it is a process framework, but if so then it is a sparse and incomplete one at best and very clearly every other process in existence could also make this marketing claim. A more accurate description is that it is a high-level lifecycle for construction iterations (what Scrum calls “sprints”) and several practices such as daily stand-up “Scrum” meeting, product owner, product backlog, iteration/sprint planning, and potentially shippable software.
  
• Extreme Programming (XP). XP is a collection of practices for software construction, include refactoring, test-first design, pair programming, on-site-customer, continuous integration, whole team, and collective ownership. XP is very close to being a APMM Level 2 process but it is unfortunately missing (currently at least) explicit practices for project initiation and release the system into production.
  
• Agile Modeling (AM). AM is a collection of practices for light-weight modeling and documentation, including requirements envisioning, executable specifications, active stakeholder participation, prioritized requirements, and prove it with code.
  
• Agile Data (AD). AD is a collection of practices for database development, including agile data modeling, database testing, database refactoring, and continuous database integration.
  

APMM Level 2: Disciplined Agile Delivery
Level 2 agile processes extend Level 1 to address the full system delivery life cycle (SDLC). As the
criteria for disciplined agile development suggests they also tend to “dial up” certain aspects of agile development, such as testing, measurement, and process improvement. Furthermore, they include explicit mechanisms to support effective (ideally lean) governance. Examples of Level 2 agile processes include:

• Hybrid Processes. A common strategy is for organizations to cobble together a Level 2 process on their own, often around the Scrum "process framework" and XP with ideas either brought in or reinvented from AM and sometimes AD. This strategy is perfectly fine in theory, although in practice a lot of project teams seem to spend a lot of time in trial-and-error experimentation to figure it out for themselves. They invariably have some "learning experiences" which could have been avoided if they'd only started with a Level 2 process to begin with.
  
• Rational Unified Process (RUP). RUP is a comprehensive process framework for iterative software delivery which can be instantiated anywhere from a very agile form to a very traditional form as your situation warrants. RUP practices include risk-value lifecycle, whole team, test-driven development (TDD), business process sketching, and continuous integration.
  
• Open Unified Process (OpenUP).
  OpenUP, the definition of which is available via open source, which combines and extends practices from Scrum, XP, AM and RUP for co-located agile teams which are building business applications. OpenUP practices include whole team, daily standup meeting, prioritized work items, risk-driven lifecycle, TDD, active stakeholder participation, and continuous integration.
  
• Harmony ESW. Harmony ESW is an agile software process for embedded software (ESW) systems.
  
• Dynamic System Development Method (DSDM). DSDM is an agile delivery process originally based on Rapid Application Development (RAD) which is often used to developer user interface intensive application. DSDM practices include prototyping, test throughout the lifecycle, reversible changes, and feasibility study.
  

APMM Level 3: Agility at Scale
In the early days of agile, the applications where agile development was applied were smaller in scope and relatively straightforward. Today, the picture has changed significantly and organizations want to apply agile development to a broader set of projects. Agile hence needs to adapt to deal with the many business, organization, and technical complexities today’s software development organizations are facing. This is what Level 3 of the APMM is all about – explicitly addressing the complexities which disciplined agile delivery teams face in the real world.

The scaling factors which an agile team may face to a lesser or greater extent includes team size, physical distribution, organizational distribution, regulatory compliance, cultural or organizational entrenchment, system complexity, and enterprise disciplines (such as enterprise architecture, strategic reuse, and portfolio management). Each factor has a range of complexities, and each team will have a different combination and therefore will need a process, team structure, and tooling environment tailored to meet their unique situation.

Unfortunately, the term “maturity” is a loaded one within the software process realm, not the least because of the Software Engineering Institute (SEI)’s Capability Maturity Model Integrated (CMMI). A lot of good work has been done to show that agile and CMMI can be applied together, and I look forward to seeing that strategy come to fruition. However, where the goal of the CMMI is to provide a framework for software process improvement the goal of the APMM is much more modest – it merely strives to define a framework which can be used to put the myriad agile processes into context. In short, the APMM and CMMI are orthogonal to one another, and in future blog postings I’ll discuss how CMMI and APMM fit together.