Get certified - Transform your world of work today

Close

Agile 3R Model of Maturity Assessment

16 March 2015

Phani Thimmapuram
Bank of America


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. [Editor's note: There are many such methods proposed. For example, see the recent article "3S Model for Agile Maturity."]

Readiness

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.

Rationalize

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.).

Relation

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.


Sl#

Standard

Detailed Description
Ratings by Stakeholders
PO SM TM1 TM2 TM3 TM4 TM5 TM6 TM7 TM8 Avg Rating
1 Timely delivery of valuable software Team is able to deliver the software on time 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 at 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 members trust each other and are motivated to deliver sprint deliverables 1 2 2 1 2 1 2 2 2 1 1.6
6 Communication Close 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, such as 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 on what has happened and take corrective action based on those 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 it simple Team keeps out  complications whenever and wherever possible 3 3 3 3 2 3 3 4 4 3 3.1
                  Overall average rating:           2.9
                  Maturity level Operating
Legend:
Greater than or equal to 3, less than 4 Adaptive
Greater than or equal to 2, less than 3 Operating
Greater than or equal to 1, less than 2 Promising
Less than 1 Budding



Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.8 (4 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.

 
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


 

Newsletter Sign-Up

Subscribe