By now, we have all learned how to reach agile maturity, but what do you do when it starts slipping away? After two decades of agile adoption, we still face the same struggles: code ownership disappears, tests become unreliable, technical debt piles up, and knowledge sharing fades away. We will explore three types of interventions (from subtle, prompt actions to crisis-mode reorganization actions), and how developers, architects, scrum masters, and managers can each contribute across five dimensions (leadership, domain, technology, staff, social).
We introduce a new model for mentoring agility, focusing on the later stages of agile maturity and how practical measures can be used to reverse the downward spiral. It is a practical framework for spotting decline early, real examples from a team that survived major challenges over six years. We want to jumpstart the motivation to act - because regardless of your role, doing nothing is rarely the right choice.
Publication
This concept is based on a case study that has been published:
Clark, K., Pufahl, M., Lederer, M. (2025): Staying Agile: A Process Lifecycle Model for Maintaining SCRUM Practices in Software Development. In Proceedings of the S-BPM ONE 2025. Cham: Springer.
The underlying question
Or, to translate it to research questions:
How can the lifecycle of an agile development process be systematically described over its entire course - from transition to stabilization of agile maturity? In particular: Which specific phases occur in the late process?
In the long-term, what actions have proven successful in averting negative tendencies towards non-agility?
The Lifecycle and Actions
Intuitively, most projects go through different phases. When a team and a project have just started working agile and are still figuring things out, they are still rising to their full agile maturity. In the long run, some projects continue to shine, while others gradually decline into chaos and crises.
Many agile lifecycle models have been proposed in academic research. We observed that there were more publications around the rise, fewer structured models about the shine (and even less about the decline).
We took all of these research models into account to create our own lifecycle model that describes agile maturity over time.
Awareness → Transformation → Breakthrough → Optimization
Our focus was on the Mentoring phase, where decline happens.
To be more specific, we focused on the three points in time to act, to get back on track, and to return to previous levels of agile maturity.
5 Action Areas
1. Leadership: Setting direction and empowerment
… coming soon.
2. Domain: Understanding the users and the business context
… coming soon.
3. Technology: Engineering practices, code, infra, architecture
… coming soon.
4. Staff: Roles and responsibilities, learning, mentoring
Let’s look into a scenario where a team is in the mentoring phase, more specifically in the Faulty Actions zone.
The team receives a new incident or alert and one of two things happen
Everyone panics and goes into headless chicken mode.
Probably no feature ever get completed in the planned sprint.Everyone ignores it (you can hear the crickets chirping) and simply assumes someone else will handle it (bystanders).
Whatever problem was reported probably wont get addressed until the next daily.
The action here is to make this work explicit! Rotate (unpleasant) tasks between team members in a fair and predictable way.
We introduced the role and called it “Firefighter”. This exists under many different names, I also really like concierge because it has a fancy, service-oriented connotation.
We switch firefighter tandems every week and ensure transparency by updating the Slack channel topic with the firefighters’ names, and keeping a designated ticket for firefighting duties in each sprint. If you pay a little attention to your firefighting roster you have a nice opportunity for mentoring.
Firefighter Responsibilities:
Weekly deployment
CVE checks
Screen alerts and respond to incidents
Support urgent PO requests
It’s simple, and it protects the rest of the team's focus and peace of mind.
But it’s not just firefighting, … Every team faces lots of little, almost invisible tasks such as cleaning up documentation, onboarding colleagues, talking to other teams about interfaces ...
There is a concept that I will not stop sharing called GLUE WORK by Tanya Reilly. It is typically expected from seniors or team leads, but anyone can handle it. She warns juniors and especially women/minorities about doing too much of this early in their careers.
Glue work makes the team faster, but the individual slower and can therefore be a promotion killer.
But I say celebrate anyone doing glue work and say thank you. Make everyone around you aware of how valuable glue work is for the team and inspire them to pitch in!
5. Social: Communication, collaboration, and culture
… coming soon.
Conclusion
Throughout this research, we found no shortcut, no silver bullet, no perfect recipe. Our case study showed that it is about doing the right actions at the right time.
