Assessing agile maturity
I’ve been working with agile frameworks for nearly 20 years. I’ve even collected behavioural data on what makes a team truly agile. What the data highlights is that teams that start with the basics get agile outcomes faster than teams that create their own flavour of agile. We’ve even written a Whitepaper with Scrum.org on this area.
What do I mean by agile outcomes? A large program ZXM has been coaching for a few years just had an external audit of its delivery done. The organisation has improved from 200+ days lead time to deliver value in 2018 to only 4 weeks in 2020. This organisation’s teams have demonstrable outcomes that are due to its change in work practices from traditional to contemporary agile practices.
- Faster time to value: They rapidly reduce the lead time to deliver value from idea to the hands of the customer or stakeholder.
- Higher quality: Rework (including software defects) reduce to almost zero within a year.
- Lower costs: Overtime shrinks, sustainable pace increases, and the reduced rework means the same outcomes can be delivered with less cost.
- Higher throughput: We’ve found it fairly easy for teams ZXM has coached to double their output while still having a sustainable pace when all the above behaviours are put into place.
Specific behaviours predict these outcomes
This data from expert review of hundreds of teams over a 10 year period highlights that as four key behaviours get stronger these agile outcomes grow:
- Self-organisation: Managers create the guardrails for long-lived teams to make decisions.
- Agile values: Their behaviours and actions directly reflect the principles of the agile manifesto.
- Sprinting: The whole system of work operates in short work cycles and embeds processes of inspection and adaptation.
- Continuous improvement culture: using empiricism and data to reflect and then taking time out to continuously improve.
When these behaviours are not very strong the outcomes from agile are significantly lower.
Why are DIY agile framework teams slower to be agile?
“We’re doing our own flavor of Agile and Scrum.”
“We just pick the parts that work for us.”
“We’re just being pragmatic.”
Scrum founder, Jeff Sutherland, has often said that Scrum is less effective when only parts of it are implemented. When the Daily Scrum is only held every other day, the team loses an opportunity to assess its progress toward its Sprint Goal. Transparency suffers as a result. When Sprint Reviews aren’t done because the team has already shown its work to the Product Owner, an opportunity to engage stakeholders about the Sprint and its results in order to elicit feedback about what to do next has been missed. Transparency about the state of work, the Product Backlog, and the Product Goal, also decreases. An opportunity to build, strengthen and maintain trust has also been lost.
“Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.” – Jeff Sutherland and Ken Schwaber (2020)
When some teams start out, they don’t actually pick the parts that will make them more effective. “We just pick the parts that work for us” means for the most part:
- We pick the parts we “like”.
- There are practices we don’t like, so we don’t do them.
- We like how we work now, so we pick parts that serve those needs.
- Agile is the thing that we compromise on when delivery urgency increases – all those meetings just get in the way of doing the work anyway.
What I’ve seen result from this behaviour is a way of working that is neither repeatable nor scalable. And it rarely has a benefit beyond that individual team.
Slower to be agile? But we deliver! We’re agile!
I’ve heard many of these teams say their customers are happy, yet when I’ve gone and asked their customers I get a very different picture. I often ask them by what measure are they agile? I get a lot of “you’re just purist” and “what you don’t understand is … ” or “we’re just being pragmatic!”.
This often starts to smell of confirmation bias, selection bias, and groupthink in the team.
Overall, I think these types of behaviours and actions suggest a very different mindset than an agile mindset.
Shu Ha Ri
When I first started with agile, Martin Fowler and Alastair Cockburn (signatories to the 2001 Agile Manifesto) were promoting a specific approach to learning agile ways of working: Shu Ha Ri.
Fowler and Cockburn’s premise is that when introducing agile to a team, you have to tailor the style of teaching not customise the elements that you’re teaching a team. This is because every team is different, their work is different, their skills are different, and their overall context is different. Introduction of an agile framework might begin with only some elements, but it’s done in a way so as to help teams build capability at the rate they can absorb learning. Some teams learn better when change is introduced iteratively. For those teams, picking specific parts for them to learn, e.g. introducing agile planning and a retrospective, might be the most effective ways to learn Scrum. Other team’s learnings are more effective when done holistically – with all the essential elements at once.
Whatever the team’s journey, creating a coaching plan that highlights the learning pathway sets expectations that learning agile isn’t like going to a course to learn how to use Microsoft Word. This is a continuous learning journey with the coach continuously assessing where a team is at so they can help them learn and improve.
Create a team's learning journey with Agile IQ®
Agile IQ®'s assesses a team's agile behaviours and provides learning recommendations to take them to the next level of agility.
Get the basics right first before you start customising things
Shu Ha Ri reminds us that teams need to get the basics right first. Early stages of learning and agile coaching should focus on concrete steps to imitate, before the focus then shifts to understanding principles, and finally into self-directed innovation where teams have enough knowledge to understand how to self-reflect, learn, and adapt their way of working so that it benefits the organisation over producing suboptimal team-level-only outcomes and inconsistent practices between teams.
Conclusions: Assessing the team’s stage of learning tells you a lot about their agile maturity
A team’s state of learning tells you a lot about their agile mindset. Teams that are jumping to customise elements they have no experience with aren’t seeking to be agile, they’re seeking to look like they’re being agile. Some people would call this cargo cult agile. Teams who can demonstrate the outcomes of their agile practice – behaviours that create faster time to deliver value, have lower rework and higher quality – are at a stage where they should be learning new practices, or even better still, helping other teams benefit from their knowledge and experience by becoming mentors and teachers. This to me is a high performing, high capability maturity, agile team.
M
