The Agile Architect
How Agile Are You? Let's Actually Measure It! (Part 0: Introduction)
How's your agile? Our Agile Architect shares with you his in-depth agile maturity assessment based on many years of helping teams and companies be agile.
For more articles in this series, please use the following links:
As I've worked with many companies and teams to get them started with agile or to become more agile, I've developed my own agile maturity assessment. By completing an initial assessment, the team has the ability to reflect on their processes, practices and team values in order to improve them. By continuing to assess agility at regular intervals, the team can track their progress. This series of articles will help you do the same.
What Is an Agile Maturity Assessment?
An agile maturity assessment is a way to evaluate how a team is improving their ability to be agile over time.
There are many ways to run the assessment. It can be performed by an objective third party, e.g., an agile coach, by the team themselves, or both. By comparing results between evaluators, the team can start to get a picture of their common understanding of their agile maturity.
What to do with the results is up to the team. Presumably, they would choose a single aspect of the assessment to improve upon, then continue to measure at regular intervals to see the results.
This assessment is focused on a software development team. While it has some aspects of organizational agile, it is there as a way for the team and their organization to understand how that organization can best support the team. A different agile maturity assessment is necessary to measure the agility of an organization around agile portfolio and agile organization principles.
This assessment can be prescriptive in some areas, meaning that it assumes that the presence of certain agile best practices (Kanban, XP technical practices) are the indicators of maturity in that area. However, that's very presumptive of me. In fact, you should adapt this assessment for your own needs. If you adjust or replace one of the prescriptive questions, be sure you do so with something that achieves the same goal. For this reason, I have mapped each question to one or more of the 12 agile principles, the shorthand for which is:
- Value Delivery: Our highest priority is to satisfy the customer through early and continuous deliveryof valuable software.
- Harnessing Change: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Frequent Delivery: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business and Development Collaboration: Business people and developers must work together daily throughout the project.
- Self-Organization: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- Communication: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Measuring Progress: Working software is the primary measure of progress.
- Sustainable Pace: Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
- Technical Excellence: Continuous attention to technical excellence and good design enhances agility.
- Simplicity: The art of maximizing the amount of work not done -- is essential.
- Self-Organization: The best architectures, requirements and designs emerge from self-organizing teams.
- Continuous Improvement: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Levels of Maturity
Each assessment question is evaluated to one of six different levels of maturity as described below.
Level 0 – No Capability
Level 1 – Beginning
The team has some passing knowledge from reading books & articles. They are not yet applying the knowledge or are applying it on an ad hoc basis.
Level 2: Learning
The team actively tries to apply knowledge from training, books, and coaching.
Level 3: Practicing
The team understands the practice and uses it regularly.
Level 4: Measuring
The team applies advanced concepts and/or is using metrics to measure their abilities and effectiveness.
Level 5: Innovating
The team actively experiments with new methodologies and practices and is using metrics to measure the effects.
The descriptions above are a general guideline. For each question, I have provided specific examples for each maturity level as it relates to that question..
While these levels of maturity may imply that higher is better, there is a cost to getting all the knobs to 5. The team should decide for each question in the assessment what their desired maturity level is.
Warning! The assessment gives the illusion of being very quantitative, as the maturity levels are defined numerically. However, in practice, the results are very subjective, based on the perception of the evaluators. As such, numeric maturity levels should only be used to help the team decide if they are improving (or backsliding) as they continue to mature their agility. The level of effort to get from one maturity level to the next is certainly not equal and the assessment is definitely not intended to allow comparison between teams.
Assessment Areas
Assessment questions are grouped into 9 different areas. Follow the links to these areas in the rest of the articles of this series to review the relevant assessment:
Once an assessment is complete and responses to each question are evaluated, results can be aggregated to show progress in each area. Figure 1 shows an example of agile assessments taken before and after an aggressive agile transformation initiative.
Figure 1: Example Agile Maturity Assessment Results
Final Thoughts for Part 1
Any metric, measurement or assessment can be used for good or evil. This assessment represents a point-in-time perspective of my personal opinions on how to measure agile maturity in a software development team. As I learn and evolve as an agile coach, I will continue to update and adapt the assessment. I hope you will, too.
Don't forget to hop over to Part 2 of this article to start your assessment with the technical craftmanship category.