Agile Maturity Model – 3 Different Approaches

Posted by Udayan Banerjee on November 30, 2011 · 10 Comments 

Though we do not have an accepted model for accessing the level of maturity of adoption of agile methodology, there three distinct schools of thought on what an “Agile Maturity Model” could be. The first school of thought maintains that agile methodologies are only a means to an end and what is right for an organization can only be derived from business goal – there can be no generic model.

The second school of thought looks at agile maturity mainly as a scaling problem starting from an adoption at a single team level and spreading out to span the entire organization and extending its scope to area other than pure software development.

The third school of thought is emphasizes that agile maturity cannot be assessed as a whole but it is important to look at the sub processes and their maturity. The emphasis need to be on level of maturity required in each of the sub process, monitor where the organization currently stands and make plans to reach the desired level.

Off course there skeptics who think agile maturity model is meaningless. For example, Charlie Rudd says that we are yet to establish correlation between the progressive stages of maturity of agile adoption and progressive improvement in business objective performance where the business objectives may vary but the agile stages must the same – What is the Purpose of an Agile Maturity Model?

Why Agile – start from the business goal?

Esther Derby maintains that how agile you are doesn’t matter. What does matter is that your company is satisfying its customers, stakeholders, and employees. Therefore, an agile maturity model cannot be an end in itself; it has to be means for achieving an end – Achieving Agility: Means to an End, Or End in Itself

She claims that adoption of agile can serve the interest of all the three groups like customers, stakeholders, and employees.

• Agile encourages close collaboration with a product owner or customer
• Iteration planning and tracking story-points helps teams and management understand capacity
• Agile methods encourage planning based on demonstrated capacity
• Working in short iterations to produce completed slices of feature can allow the company to realize revenue early
• Agile engineering practices such as automated unit and customer tests, pair programming, and frequent integration find errors early
• Many teams who use agile methods are building strong cross-functional teams and report that their satisfaction with work-life and work/life balance is higher

However, it is important to assess your “agility,” assess how well you are satisfying your customers, stakeholders and employees. Charting a course based on a clear understanding your current situation is most likely to succeed.

So, she does not recommend a prescriptive model but says that it has to be tailored for each organization.

How to scale Agile – from one small team to whole enterprise?

Scott Ambler identifies 5 levels of maturity which he describes as a five-stage model that provides guidance for improving your effectiveness at agile software development – The Agile Maturity Model (AMM)

• Level 1 = Rhetorical: Agile strategies were applied on hand-picked pilot projects, by a small team of flexible and often highly-skilled people, and were given sufficient management support.
• Level 2 = Certified: Many of team members have obtained some form of agile certification.
• Level 3 = Plausible: The organization begin to focus on agile strategies which may in fact be actually viable within the organizational context. There is a struggle with scaling issues, such as strategies for large or distributed teams.
• Level 4 = Respectable: Agile teams adopt a full delivery lifecycle, not just a development lifecycle, and tailor their approach to meet the unique needs of the situation in which they find themselves. The teams are self-organizing within an appropriate governance framework, recognizing that they work within the constraints of a larger organizational ecosystem.
• Level 5 = Measured: In this stage techniques are adopted not only from the agile but also from traditional, lean, and other paradigms in order to be as effective as possible. The emphasis is on steering projects based on real empirical information and not just observational guesswork.

In a nutshell you move from a stage of adopting agile by the book and shunning every other practice to a stage where you look at the organizational context and mix agile practices with other techniques as relevant and appropriate.

Martin Proulx has also proposed a 5 level maturity model where the focus is on moving for single team to the whole organization –  Yet another Agile Maturity Model (AMM) – The 5 Levels of Maturity

• Level 1 = Team Level: In the level team members have decided to adopt Scrum and/or software engineering practices without asking for approval from their manager. Outside the team, almost nobody has heard or understands what Agile means.
• Level 2 = Department Level: At this level, the practices adopted by the team members have started to be imitated by other teams within the software development department and some managers have become aware of agile approach.
• Level 3 = Business Level: At this level, the solution teams have integrated the business people in the model with more collaboration among them. A Product Owner is clearly identified and may be dedicated to their project.
• Level 4 = Project Management Level: At this level, the project management approach is modified to include some of the Scrum practices. Projects managers are fully aware of the new practices used by the teams. A strong evangelist is in place at the management / executive level to promote the new approach.
• Level 5 = Management Level: At this level, managers have adapted their management style to support an agile organization. Organizational structures and reporting mechanisms are better adapted for collaboration and improved for increased performance. Management is considering implementing Agile to projects that do not require software development.

The clear assumption is that the agile adoption happen bottom up. He also mentions a 6^th level which is corporate level but says that it is utopia.

Scott Ambler, in another post, goes on to identify 8 different dimensions of the scaling up challenge – Agile Scaling Factors

1. Geographical distribution: Effective collaboration becomes more challenging.
2. Team size: Paper-based, face-to-face strategies start to fall apart.
3. Compliance requirement: regulatory issues – such as Sarbanes Oxley, ISO 9000, or FDA CFR 21 bring requirements of their own that may be imposed from outside your organization.
4. Domain complexity: More complex domains will require greater emphasis on exploration and experimentation, including but not limited to prototyping, modeling, and simulation and working software may come much later in the cycle.
5. Organization distribution: Project team includes members from different divisions, different partner companies, or from external services firms.
6. Technical complexity: The nature of the problem itself may be very complex in its own right where technical solution may have to be found before delivering working code.
7. Organizational complexity: Existing organization structure and culture may reflect traditional values, increasing the complexity of adopting and scaling agile strategies.
8. Enterprise discipline: Enterprise architecture, enterprise business modeling, strategic reuse, and portfolio management disciplines may need to work in concert with the disciplined agile delivery processes.

How to be Agile – what processes to focus on?

Ross Pettit claims that the aim of any Agile Maturity Model should be to create a simple, flexible, fact-based assessment of the degree of agility in fundamental IT practices and, subsequently, in the organization. The framework should help an organization can quickly assess how its current processes enable and inhibit responsiveness and can determine what it should be doing – The Agile Manager and An “Agile Maturity Model?”

He talks about different dimensions like:

• Shared Responsibility
• Build
• Requirements
• Testing
• Responsiveness
• Assurance
• Simplicity
• Configuration Management
• Communication
• Governance

He suggests that, for each of these dimensions, you look at your initial stage, where you are currently and where you would like to reach. He also mentions that your roadmap should be driven by business needs. Shaun Jayaraj, in another post, elaborated on each of these dimensions – The Agile Maturity Model

Scott Sehlhorst suggests a similar approach but identifies different dimensions for agile maturity – Agile Maturity Model – What’s Next?

• Staffing the engineering team correctly
• Assuring Quality is in your team’s DNA
• Reducing overhead in the release process
• Feeding the beast
• Managing stakeholder expectations
• Continuously learning from your market

So, is it necessary to have a model to measure agility? Which of the three approaches is the best approach? Is it possible to have a hybrid approach – combining 2 or all 3 approaches?

Here is an interesting paper “A Disciplined Approach to Adopting Agile Practices: The Agile Adoption Framework” which combines 2 of the three approaches. On one dimension it looks at levels of adoption and on another dimension it looks at adoption of principles.

Udayan Banerjee on Google+

Filed under Agile · Tagged with agile development, Agile maturity Model, Business agility, Iteration, Maturity Model, Methodologies, Programming, Project management, Scott Ambler, scrum