How to Analyze the maturity level of teams in Agile

Tell us more... What has changed since becoming Agile? What are some things the teams are doing now that they weren't doing before? How are the teams functioning? More details may help answer your question.

What qualities and behaviors does the team feel makes up a highly mature agile team? How might they set their own standards and goals and grade themselves against it? 

Knowing what you want to measure against may help determine the types of tools or evidence required. 

I would like to know in what ways or by using any charts or tools can we find
the maturity level of team or organization on Agile

Let's start with the organizational vision for agile change. What benefits arising from agile practice have been anticipated? 

And now time has come to showcase their maturity level for management.

What do management intend to do with this information?

Is there a reason why the team are not consistently radiating information that demonstrates their maturity, or that management cannot see it?

What transparency is desired, and what are the potential reasons (good or bad) that it doesn't currently exist?

tnx a lot for the info, that's what I was looking for

Organization that want to begin an Agile transformation normally want a way to mesure if some teams are behind (and need coaching) or in front of everyone (success story)

Since the beginning of 2020, some coaches went in every teams in IT to ask several questions to each teams

They were all kind of question :

-To you practice vertical slicing

-Does your stories are INVEST

-...

They were basically some "best practices" and team had to say, Yes or No to each questions

Thanks

Dear All,

I am focusing on the below parameters to measure team maturity .,



How frequent they are achieving Sprint Goals

What's the delivering Value providing to sprint

What's the Pace of Work team is doing

How they are developing the T-shapped Skill

How fast they are learning based on Retro

Team taking decisions on avoiding the work in order to focus on high-priority items

But I would like to know how can represent the above factos to the management visually

How do the Scrum Team feel about sharing this information?

Do they agree that these are all things they should be aiming for?

If there is sufficient trust and (perceived) safety in doing this, then the most effective way could be for the Scrum Team to take shared responsibility for radiating this information. i.e. they can choose to make it visible (and how), and your role in presenting it would be little more than helping management find that information.

If there is not sufficient trust or safety, then having you or anyone else assessing and sharing this information on behalf of the Scrum Team is likely to do more harm than good. It can erode trust even further, and it is a missed opportunity for a team to self-organize and take responsibility for its own maturity.

What's the delivering Value providing to sprint

What's the Pace of Work team is doing

On a very specific note, I would argue there is very little need to report on the work being done, unless it is unsustainably high and causing problems for the team. An emphasis on value is going to be much more useful in taking important decisions, and empowering the team to self-organize.

If by "Pace of Work", you mean something like the time it takes to get something "Done" or to release, I'd encourage you to reference it in terms of value or feedback opportunities, rather than units of work.

I've been talking about this topic a lot recently with people around. Measuring agile maturity is good, but it is secondary to the ability to deliver a product that is fit for it's need and is satisfactory to the customer and user. So I'd like to challenge this a bit to move from an "agile maturity assessment" to "product development/delivery maturity assessment".

Another thought, why not use the Agile Manifesto's 12 principles to take a baseline and assess maturity?

This is such a good discussion. On one hand, i do understand management wants to have a visueel representation of how teams are doing so they have a sense of control. On the other hand, having agile teams has as a consequence one doesn't need to micromanage teams and have to trust them. I know of situations, teams have to score themeselves on a maturity matrix. As a tool for themselves to help understand their strenghts and weaknesses but also to give management insight on how far teams are in the agile transition. But if teams score themselves, level 2 might mean for team A something different than for team B and the management insights are meaningless and they don't even know it. 

I am struggling with this. What is a good way to inform management/organisation on how good a team is performing? Can it be a objective measurements, like number of deployments, code quality scoring, stabilty of velocity (range), better performance figures (ie: a business process is taking less time because of better software). And can it be without manually scoring?

What is a good way to inform management/organisation on how good a team is performing?

Why not assess value delivered and quality achieved, and the constraints the team faces when trying to optimize such things?

Perhaps management can then be of service to the team, by ensuring that organizational impediments to agile practice are removed.

Can it be a objective measurements, like number of deployments, code quality scoring, stabilty of velocity (range), better performance figures (ie: a business process is taking less time because of better software).

All of those measurements can be extremely high but the product being delivered is not something that anyone wants to use.  This is what everyone is referring to when they say to measure value and quality.  Value is perceived by the consumers.  Their willingness to spend money on, to use, to recommend to others all talk to the value that the organization is getting from the work that is being done.  Customer satisfaction scores are a better measurement of the work that a team does than number of deployments.  In a Continuous Deployment set up I could deploy 20 times a day by just adding comments or reformatting a line of code.  But does that really make a team successful?

Quality is represented by the ease of use, the absence of code defects, the availability of the product when people need it.  It isn't just about how many tests you have or the number of defects discovered in production.   A product that generates a large volume of support calls because it is not intuitive to use is an indicator of poor quality work. 

Good metrics are not the easiest to acquire. 

What would you say is the best way to do this?

Why not assess value delivered and quality achieved, and the constraints the team faces when trying to optimize such things? 

Maturity is measured from the ability to deliver high valuable software increment and receive fast feed from end users . In this way the risk and the complexity of the domain is mitigated . This is the urgency for adopting scrum ..