Agile Maturity Assesment

admin   April 27, 2016   Comments Off on Agile Maturity Assesment

Assessing the maturity of Agile teams is a big challenge for most organizations, yet any organization should check frequently on the maturity of its Agile process. When I started the Agile transformation, there was definitely a misconception within the team that “Agile is fragile.”

I think in terms of the following basic 3R model of assessing the maturity of the Agile process.

This is the key for success of the Agile transformation. Since we have diversity among the various mind-sets, cultures, and work environments, we need to get buy-in or readiness from all stakeholders to make the process successful.

This is the very important phase, as it covers the basic guidelines of Agile. Strengthen the process and ensure waste reduction and use of best practices to fix the bottlenecks during the development process (dependencies, lead/lag times between the applications and systems, etc.).

Emphasize the relationships among individuals to achieve the best results through closer team communication and trusting each other and being motivated to deliver sprint deliverables. This is vital in terms of successful delivery of the work. When team members are more connected with each other, they will produce more value/output.

Following are two basic questions we should ask ourselves before judging the maturity of the process.

1. What are the basic factors we should look for in a maturity assessment?
2. Is our model really simple to administer?
As a software developer, I have been in the industry for more than 16 years; I’ve seen a lot of processes. When my team decided to embrace Agile for our software development a few years ago, I remember feeling a lot of uncertainty about it. When the Agile process was first described to my team, one of the more enticing aspects was that it appeared we no longer had to deal with huge requirements and design documents. In a way, that part turned out to be true. We definitely don’t create the same documentation that we did when we were following a Waterfall model. However, many of the folks who doubted the wisdom of the Agile process often commented that in Agile you don’t have to write documentation and that it would just invite development chaos.

The reality for our Agile teams seems to be that we are writing more documentation. The documentation we write is much less formal but much more functional. We usually don’t write a document unless it’s absolutely necessary, and the story document is our core document. These story documents are often less than a page long, but they encompass a concise description of the business problem that needs to be solved with a synopsis of what design, architecture, or function can be introduced in our product to solve the problem. So we aren’t writing less documentation, but the documentation we do write has a lot more utility.

Here is a simple method of assessing teams based on the Agile principles. Anyone can customize this per their requirements.






Detailed Description

Ratings by Stakeholders
PO SM TM1 TM2 TM3 TM4 TM5 TM6 TM7 TM8 Avg Rating
1 Timely Delivery of the valuable software Team is able to deliver the software timely and with the expected quality 3 3 4 3 3 3 4 3 3 3 3.2
2 Change requests inclusion Team is accommodating the changes as suggested by the PO 3 4 4 3 3 2 2 3 4 3 3.1
3 Iterative/Frequent delivery of software Team is able to deliver quality software with in frequent intervals 3 4 3 4 3 3 2 3 3 4 3.2
4 Collaboration Team is following daily rituals and collaborating 4 4 3 3 2 2 4 3 3 3 3.1
5 Motivate and Trust Team trusts each other and motivated to deliver sprint deliverables 1 2 2 1 2 1 2 2 2 1 1.6
6 Communication Closer team communication wherever possible 3 3 3 3 2 4 4 4 4 3 3.3
7 Engineering Practices Team is following/ striving for best engineering frameworks like Test Automation , TDD, continuous integration 2 2 1 1 1 2 3 2 2 2 1.8
8 Reflect and correct Team is able to reflect what has happened and taking corrective action based on the reflections 3 3 3 3 3 4 4 2 4 4 3.3
9 Working Software Team is delivering working software at the end of the each sprint 2 2 3 2 2 3 3 4 4 4 2.9
10 Sustainable Estimations/Velocity Team is working for planned hours and with the sustainable velocity 4 4 4 4 3 3 3 3 3 3 3.4
11 Keeping Simple Team keeping everything simple not complicating too much 3 3 3 3 2 3 3 4 4 3 3.1
                  Overall Average Rating:           2.9
Maturity Level  Operating


Greater than or equal to 3, less than 4 Adaptive – Green
Greater than or equal to 2, less than 3 Operating – Amber
Greater than or equal to 1, less than 2 Promising – Red
Less than 1 Budding – Red