Just saying it like it is. My favourite Agile maturity measure is the one in the picture above! I like to invite a team starting out in Agile to create a histogram of how they as individuals feel about their comfort level with Agile. I know that Agile maturity checks are loved by management, but I think they’re less useful to teams.
At work I put some time and thought into developing a maturity model that spans Lean system thinking, Lean Startup, Agile and DevOps practices. I modelled it on Spotify’s team health check, which I do feel is really useful. This maturity check was only moderately useful. I suspect that if you do use it, you’ll make an early maturity team feel a bit depressed and inadequate.
My thinking behind this model was to set the bar of early maturity where a non-Agile team taking their first steps might find themselves. My scale ranges all the way up to mature, which is good practice and I hope, not too aspirational.
It might be most useful to use components of it, if a team discloses a particular area they want to address. The next step might be to use a retro to generate ideas about how they could get from “not yet” to “on the way”.
Take a look at it and use with caution!
| Not yet | On the way | Mature | |
| Standups | We don’t run standups. | We run standups sometimes. Standups tend to run over the 15 minute mark. We can’t always see the point of standups. | We run standups every day and stick to the questions: what we did yesterday, what we did today, and what obstacles we need to resolve. Standups never exceed 15 mins. |
| Team rhythm | As a team member I’m either too busy or not invited to attend all the Agile ceremonies – standup, estimation, sprint planning, showcase and retro. | I mostly attend those ceremonies that I’m invited to – standup, estimation, sprint planning, showcase and retro. | As a team member, I attend and contribute to all Agile ceremonies – standup, estimation, sprint planning, showcase and retro. |
| Process | Our way of working is painful. Process gets in the way of us getting stuff done. | We have a way of work that is sometimes easy and sometimes hard. It would be great if our process fit us better. | Our way of working fits us perfectly. We have just enough process to get stuff done easily. |
| Speed | We never seem to get done with anything. We keep getting stuck or interrupted. Stories keep getting stuck on dependencies. | We get through stories, but there are frequently blockers, or process glitches. | We get stuff done really quickly. No waiting, no delays. |
| Requirements | Our Agile stories are place-keepers for the work we do. We use BluePrint to articulate our requirements. | We are using Agile user stories, but our stories are sometime technical tasks derived from specifications. Our stories are not consistently small, estimable, and independent | Our user stories are not derived from a formal documentation process but are captured as business value. They are always small, estimable and independent. We always include acceptance and test criteria. |
| Analysis | Time pressure usually prevents us from having our stories articulated before bringing them into a sprint. We do this during the sprint. | Our aim is to get stories ready for a sprint, but accept that sometimes the work just needs to be done, so articulation of stories takes place during a sprint. | We have a clear “Definition of Ready”, so we never bring stories into a sprint unless they are fully articulated, including a story statement, acceptance criteria and test criteria |
| Sizing | We aren’t yet sizing our work before bringing it into a sprint. | Several team members get together for sizing. We mostly have stories estimated before we bring them into a sprint. | We have a regular rhythm of story sizing and involve the entire team in this process. |
| Velocity | We use the stories in a sprint as a guideline or focus for our work. We never complete the stories we plan to complete in the sprint. | We sometimes finish stories (including testing) in the sprint. | As a team we always finish all the stories (including testing) we commit to in a sprint. |
| Sprint planning | We aren’t yet conducting regular sprint planning. | Several team members get together for sprint planning. Sprint planning usually happens, but we usually carry over stories not completed from the previous sprint. | We have a regular rhythm of sprint planning that involves the entire team. We all commit to the work in the upcoming sprint and are confident we can complete it. |
| Agile wall | We don’t yet have an Agile story wall. | We have an Agile story wall, but it doesn’t necessarily reflect what we are working on, or what is in JIRA. Our Agile story wall is not hugely relevant for us in standups or our daily work. | Our Agile story wall is our key source of truth about the progress in a sprint. Anyone looking at it can see exactly what we are working on and where we are up to. It matches what is in JIRA. We use it both in standups and the daily work we do. |
| Showcasing | We aren’t yet showcasing. | We showcase when we have something tangible to show stakeholders. This can be between every second and fourth sprint. | We have working software to showcase after every sprint. We invite key stakeholders to this showcase and our developers run through what has been built. |
| Retrospectives & Learning | We aren’t yet running retrospectives. We never have time to learn anything. We are too busy for retros and cross team showcases. | Time permitting, we run retrospectives. This doesn’t necessarily happen after every sprint. | We’re learning lots of interesting stuff all the time. We run retros every sprint. We initiate and participate in cross team showcases. |
| User experience support |
We are struggling to understand what role User Experience designers play in defining our product and where they fit into the lifecycle. | We sometimes tap into the skills of User Experience Designers, but often time pressure prevents us from working closely with them. | We have complete clarity on the role of user experience designers in our product development. We integrate their work into stories across all product builds. |
| User experience integration |
We often find we don’t have time or resources to integrate qualitative (through UX testing) or quantitative (through integration of analytics) customer learnings. | We integrate some qualitative and quantitative customer learnings into what we build, but we rarely have an opportunity to run another iteration to further improve our product. | We integrate qualitative customer learnings (through UX testing) and quantitative (through integration of analytics) into every feature/initiative we build and deploy. |
| Testing | Testing is owned by the QA/Tester. Functional, non-functional and integration testing is performed at the end of the lifecycle, not necessarily within a sprint. | Testing is shared by the QA and Dev. Non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. | Testing is owned by the QA, Dev and BA. Non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. Developers practice Test Driven development (TDD). |
| Build | Build is manually performed custom or repeatable, but still manual. Build is performed infrequently. One member of the team owns build. | Build is repeatable and automated, but doesn’t happen with maximum frequency. Build is the responsibility of the team. | Functional Testing tools (Watir, Selenium, etc) are integrated as gatekeeper events to the build. Integration tests with external tools and products. |
| Releasing | Releases are extremely difficult. Our preference is to release at the end of the project. | Releasing is tricky, so we aggregate as much work as possible before releasing. | We have a regular rhythm for releasing. It is fast and painless |
| Collaboration & Communication | We consistently find it difficult to get answers to our questions, or resolve issues in a timely way. | It is sometimes difficult to get someone in our team to help us out, or resolve a problem when we need it. | If we need somebody in the team’s opinion or assistance, we can freely ask that person either at standup or throughout the day and expect a prompt response. |
| Empowerment – ways of working | It’s the job of leadership to suggest how we can work better. | It’s sometimes difficult to get traction on improved ways of working, but we give it a go. | We feel empowered to suggest how we can work better. Our suggestions translate to real improvements in the way we work. |
| Empowerment – product | We don’t have any understanding of how the customers are responding to the product so we can’t calibrate it. | We sometimes hear feedback about our customers’ responses to our product, but incrementing the product in response to this only sometimes happens. | Our regular cycle it to respond to learnings from customers. It shapes our backlog. |
| Contribution | We complete our work, but it’s not always clear how the tasks we are performing are critical to the success of the team. | We know that the tasks we are performing are critical to the success of the team, but sometimes it doesn’t feel so – . | Every day we are at work, we know how our work contributes to delivering a great product. We own creating a great product. |
| Fun & Celebrating Success |
Boooooooring. We do not celebrate successes. | There are some smiles about, but celebrating success isn’t something we really do as a team. | We have great fun working together. We find ways to celebrate our success. |
agilesista 
This is very good. I will use this as a benchmark for our team. Thanks for sharing Katrina.