Staying Agile When It Gets Hard - Agile meets Architecture 2026

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).This scientifically based presentation shares 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. You'll leave with: A practical framework for spotting decline early, real examples from a team that survived major challenges over six years, and the motivation to act - because regardless of your role, doing nothing is rarely the right choice.

Transcript

1. Staying Agile When It Gets Hard Katie Clark Delivery Lead at Comsysto Reply Matthias Lederer Information Systems Professor at OTH Amberg-Weiden
2. … but actually, tests become flaky, technical debt piles up, and code ownership disappears. Agile Manifesto: Continuous attention to technical excellence and good design enhances agility. 2
3. ... but actually, there's always that one really urgent business story. And tech debt can be addressed "when things finally calm down". Clean Code: Eliminate all technical debt in every sprint. 4
4. … but actually, business experts are very busy and developers just implement what they’re told via an (in)complete story description. Agile Manifesto: Business people and developers must work together daily throughout the project. 5
5. We have so much agile and architecture advice, why does it rarely survive in the real-world? 6
6. 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? “ “ 8
7. “Project Internship” Published Paper 9 Katie Interested in legacy systems and insights on what makes teams successful in the long-run Matthias Interested in real-world IT processes in order to share up-to-date information with his students Lifecycle Actions
8. Agile maturity Time Time Agile Maturity WHAT ABOUT YOUR PROJECT? 🌟 10
9. LITERATURE ON RISE … A. Phase-oriented transformation models Agile Transformation Model [23], INSERT Model [26], ARTCO Model [27], Agile Lifecycle Phase Model [29], Agile Transformation Model [31] B. Maturity & measurement perspectives Agile Maturity Map [25], Agile Maturity Model [28], Scrum Maturity Model [34], Progressive Outcomes Framework [35], Perceptive Agile Measurement [30] C. Focused transformation lenses Agile Adoption Framework [22], Agile Transformation Journey [32], Agile Adoption and Improvement Model [24] D. Practice & implementation guidance Agile Management Implementation Practices [33] 11 All sources listed under extra ressources
10. … AND SHINE OF AGILE MATURITY A. Organizational decline & regression mechanisms 5-phase model of organizations [36], Five Stages of Decline [38], Larman’s Law [37] B. Post-adoption sustainability & institutionalization Post-adoptive Agility [11], Sustainable Agile [12], Normalization Process Theory [43] C. Agile anti-patterns & pseudo-agility ScrumBut phenomenon [39], Cargo Cult Agile [41] D. Regeneration & evolutionary development of agility ScrumAnd phenomenon [40], Long-term transformation & regression [42] 12 All sources listed under extra ressources
11. 👀 🤖 🚀 🌟 🙈 ⏳ 🛠 💥 💀 Awareness Transformation Breakthrough Optimization Mentoring Blinded Inaction Faulty Action Crises Dissolution Agile maturity Time Agile Maturity OUR LIFECYCLE MODEL 13
12. 🙈 ⏳ 🛠 💥 💀 Mentoring Blinded Inaction Faulty Action Crises Dissolution Prompt action Corrective action Reorganisation action Agile maturity Time Agile Maturity ACTIONS FOR WHEN IT GETS HARD 14
13. COLLECTING ACTIONS FROM THE REAL-WORLD 15
14. Action area \ intervention points Prompt action Corrective action Reorganization Leadership Establish transparency regarding goals and progress, for example through regular goal-oriented reviews (e.g., goal meetings with key stakeholders). Establish structured, bidirectional feedback and mirror leadership behavior, for example through systematic one-to-one mentoring. Reorganize decision-making and leadership structures, e.g., by redefining role-based areas of responsibility at a strategic off-site meeting. Domain Ensure immediate feedback from users and the market environment, e.g., through spontaneous product demos or end-user interviews. Adjust scope management, e.g., using feature flags, rapid prototyping, or event storming sessions. Strategically redraw product and system boundaries; in critical cases, cancel or recut epics and reduce dependency on third-party systems. Technology Encourage continuous knowledge and code sharing, e.g., through pair reviews, “Today I learned” channels, or technical decision records. Systematically reduce technical debt; this includes prioritized refactoring, architecture-related spikes, or the introduction of additional test layers. Restructure the architecture or deployment pipeline; consolidate redundant microservices or completely automate the release process. Staff Make competencies visible and distribute them more widely, e.g., via skill matrix self-assessments, task rotation, or micro proof of concepts. Establish targeted skill development; mentorship programs or thematically focused knowledge sharing sessions have proven effective here. Reconfigure team setup: Bring in coaches, set up a firefighter tandem or – in the event of persistent dysfunction – reorganize personnel. Social Maintain psychological safety: informal exchange formats, non-judgmental retrospectives or consciously framing incidents as learning opportunities. Institutionalize joint learning, for example through blameless post-mortems or feedback workshops to strengthen interaction and trust. Use professional conflict and culture management: external mediation formats, explicit empowerment mandates (“PO trust”) or culture coaching. “SCIENTIFIC SOLUTION” 16
15. Domain Technology Staff Social Understanding the users and the biz context (e.g. respect stakeholders, draw together) Engineering practices, code, infra, architecture (e.g. clean slate, complete refactoring) Roles and responsibilities, learning, mentoring (e.g firefighter role, glue work) Communication, collaboration, and culture (e.g. lived-in space, memes) 5 ACTION AREAS 17 Setting direction and empowerment (e.g replacing team members, feedback) Leadership Share your actions via menti.com 1796 6494
16. SYMPTOM • Open hostility • No trust Clearly communicate "this is not okay" Replace team members (fast) → reset the team dynamics LEADERSHIP ACTION ⏳ 🛠 💥 Prompt Corrective Reorganisation 18 Performance Potential
17. ⏳ 🛠 💥 Prompt Corrective Reorganisation SYMPTOM • Polite working mode • Everyone is doing their job Be the role-model for reflection and growth E.g. feedback circle Ask specific feedback questions Say thank you and be transparent LEADERSHIP ACTION 19
18. 20 Engineering practices, code, infra, architecture (e.g. clean slate, complete refactoring) Roles and responsibilities, learning, mentoring (e.g firefighter role, glue work) Communication, collaboration, and culture (e.g. lived-in space, memes) 5 ACTION AREAS Setting direction and empowerment (e.g replacing team members, feedback) Understanding the users and the biz context (e.g. respect stakeholders, draw together) Technology Staff Social Domain Leadership Share your actions via menti.com 1796 6494
19. SYMPTOM • Processes change • Scared of “the new way” • Power struggles Take your users and stakeholders serious Respect their concerns and fears • Introduce change slowly • Feature flags “for humans" DOMAIN ACTION ⏳ 🛠 💥 Prompt Corrective Reorganisation 21
20. SYMPTOM • Ongoing domain model transition • Insecure team Model your domain (together) with informal sketches Gallery Walk (Liberating Structures) Enforce architectural constraints automatically (ArchUnit) DOMAIN ACTION ⏳ 🛠 💥 Prompt Corrective Reorganisation 22
21. 23 Roles and responsibilities, learning, mentoring (e.g firefighter role, glue work) Communication, collaboration, and culture (e.g. lived-in space, memes) 5 ACTION AREAS Setting direction and empowerment (e.g replacing team members, feedback) Understanding the users and the biz context (e.g. respect stakeholders, draw together) Engineering practices, code, infra, architecture (e.g. clean slate, complete refactoring) Staff Social Domain Technology Leadership Share your actions via menti.com 1796 6494
22. SYMPTOM • Slow feature development • Many bugs • Low motivation Introduce a clean slate through language New quality standard is easy to recognize Create new learning opportunities TECH ACTION ⏳ 🛠 💥 Prompt Corrective Reorganisation 24
23. SYMPTOM • Incomplete refactoring • Mental overhead • Decision fatigue Make refactoring progress visible Make it fun: Refactoring Game • Java Optionals → Kotlin-native nullable objects • Side-quest puzzle • Fastest team wins a prize TECH ACTION ⏳ 🛠 💥 Prompt Corrective Reorganisation 25
24. 26 Communication, collaboration, and culture (e.g. lived-in space, memes) 5 ACTION AREAS Setting direction and empowerment (e.g replacing team members, feedback) Understanding the users and the biz context (e.g. respect stakeholders, draw together) Engineering practices, code, infra, architecture (e.g. clean slate, complete refactoring) Roles and responsibilities, learning, mentoring (e.g firefighter role, glue work) Social Domain Technology Staff Leadership Share your actions via menti.com 1796 6494
25. SYMPTOM Incoming incidents and alerts lead to A. instant panic B. no reaction Rotate (unpleasant) tasks explicitly Introduce a designated role: Firefighters • Handover every week • Tandem with experience mix • Transparency (Slack + Jira) STAFF ACTION ⏳ 🛠 💥 Prompt Corrective Reorganisation 27
26. Glue work needs to happen to make a team successful • Technical leadership (not tied to seniority) • Less glamorous - and often less-promotable BLOG/ TALK STAFF ACTION Appreciate Glue work! 28
27. 29 Communication, collaboration, and culture (e.g. lived-in space, memes) 5 ACTION AREAS Setting direction and empowerment (e.g replacing team members, feedback) Understanding the users and the biz context (e.g. respect stakeholders, draw together) Engineering practices, code, infra, architecture (e.g. clean slate, complete refactoring) Roles and responsibilities, learning, mentoring (e.g firefighter role, glue work) Domain Technology Staff Social Leadership Share your actions via menti.com 1796 6494
28. Jelled teams are so strongly knit that they have their own internal momentum. • Impossible to force • Easy to destroy (Teamicide) How to recognize a jelled team: • Not a clean, uniform office • Their space looks unique, often messy, and reflects the collective personality of the group. BOOK SOCIAL ACTION 30 Give your team the space to jell
29. The "Lived-in Office" reflecting the team’s personality A home base where the team can leave their "artifacts" 31
30. SYMPTOM • hygiene rot • small process violations • silent struggle Create a memes channel Humor can protect the team’s flow SOCIAL ACTION ⏳ 🛠 💥 Prompt Corrective Reorganisation 32
31. … handling stressful situations … holding each other accountable 33
32. … and appreciating each other. < Project Name > 34
33. MORE AGILE AND ARCHITECTURE ADVICE 35 Leadership Domain Technology Staff Social Make difficult (staffing) decisions fast Role-model the way to better (feedback) culture Take business fears serious (feature flags for humans) Model your domain (together) Introduce a clean slate through a change in language Make progress on cleanup visible and gamify it Rotate unpleasant tasks explicitly (firefighters) Appreciate glue work Give your team the space to jell Teams can use humor (memes) to protect their flow
34. STAYING AGILE ADVICE FROM TODAY 36 Make difficult (staffing) decisions fast. Role-model the way to better (feedback) culture. Respect your stakeholders’ fears (feature flags). Model your domain again (together). Introduce a clean slate through a change in language. Make refactoring progress visible and fun. Rotate unpleasant tasks explicitly (firefighters). Appreciate glue work. Give your team the space to jell. Teams can use humor (memes) to protect their flow. Domain Technology Staff Social Leadership
35. Staying agile is not (rocket) science, but it is hard work! 37
36. Katie Clark k.clark@reply.de Matthias Lederer ma.lederer@oth-aw.de Thank you! FEEDBACK SUPPORT QR Code at venue
37. Shadow AI: Developing a Diagnostic Tool for AI-Related Knowledge Hoarding in Software Development Teams 39 FUTURE RESEARCH
38. Extra Ressources Definitions, Sources, … 40
39. AGILE MATURITY (DEFINITION) Agile maturity describes the degree to which agile principles, practices, and values are consistently embedded in the everyday work of a development organization. Rather than representing a single measurable state, agile maturity reflects the extent to which teams are able to sustain adaptive, value-oriented, and collaborative ways of working across multiple organizational dimensions over time. In this sense, agile maturity is not limited to the adoption of specific methods such as SCRUM events or artifacts, but includes the long-term stabilization of agile thinking, decision-making routines, and technical practices within the development lifecycle. 41
42. 44 Sarah Wells - Technical Director for Operations and Reliability at The Financial Times “The Challenges of Migrating 150+ Microservices to Kubernetes” She mentions at [06:32] that a great metric for developer satisfaction is the number of sarcastic comments and memes being made in Slack. She noted that if the team is making fewer sarcastic remarks about the infrastructure, it’s a sign the migration had a positive effect on their daily work. MEMES AS METRICS
43. SOURCES 1-6 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. 1. Dybå, T., Dingsøyr, T.: Empirical studies of agile software development: A systematic review. Information and Software Technology, 50, pp. 9-10 (2008). 2. Dingsøyr, T., Dybå, T., Moe, N.B.: Agile Software Development - Current Research and Future Directions. Berlin: Springer (2010). 3. Aldahmash, A., Gravell, A.M., Howard, Y.: A Review on the Critical Success Factors of Agile Software Development. In Stolfa, J., Stolfa, S., O'Connor, R., Messnarz, R. (eds). Systems, Software and Services Process Improvement. Cham: Springer (2017). 4. Lacey, M. The Scrum Field Guide: Practical Advice for Your First Year. Addison-Wesley (2012). 5. Hajjdiab, H., Taleb, A.S.: Adopting Agile Software Development: Issues and Challenges International Journal of Managing Value and Supply Chains, 2(3), pp. 1-10 (2011). 45
44. SOURCES 7-12 6. Vallon, R., da Silva Estácio, B.J., Prikladnicki, R., Grechenig, T.: Systematic literature review on agile practices in global software development. Information and Software Technology, 96(April), pp. 161-180 (2018). 7. Hoda, R., Salleh, N., Grundy, J., Tee, H.M.: Systematic literature reviews in agile software development: A tertiary study. Information and Software Technology, 85, pp. 60-70 (2017). 8. Edison, H., Wang, X., Conboy, K.: Comparing Methods for Large-Scale Agile Software Development: A Systematic Literature Review. IEEE Transactions on Software Engineering, 48(8), pp. 2709-2731 (2022). 9. Henriques, V., Tanner, M.: A systematic literature review of agile and maturity model research. Interdisciplinary Journal of Information, Knowledge, and Management, 12, pp. 53-73 (2017). 10. Upender, B.: Staying agile in government software projects. Proceedings of the AGILE 2005. Los Alamitos: IEEE (2005). 11. Senapathi, M., Srinivasan, A.: Sustained agile usage: a systematic literature review. Proceedings of the 17th International Conference on Evaluation and Assessment in Software Engineering. New York: ACM (2013). 46
45. SOURCES 13-18 12. Barroca, L., Keynes, M., Gregory, P., Kuusinen, K., Sharp, H., Al Qaisi, R.: Sustaining Agile Beyond Adoption. Proceedings of the 44th Euromicro Conference on Software Engineering and Advanced Applications. Prague: IEEE (2018). 13. Maheshwari, S.K: Organizational Decline and Turnaround Management: A Contingency Framework. Vikalpa The Journal for Decision Makers, 25(4), pp. 39-50 (2000). 14. Brocke, J., Simons, A., Niehaves, B., Riemer, K., Plattfaut, R., & Cleven, A.: Reconstructing the Giant: On the Importance of Rigour in Documenting the Literature Search Process. Proceedings of the 17th European Conference on Information Systems. Verona: ECIS (2009). 15. Webster, J., Watson, R.T.: Analyzing the Past to Prepare for the Future: Writing a Literature Review. MIS Quarterly, 26(2), pp. xiii-xxiii (2002). 16. Mangold, W.: Gruppendiskussionen. In König, R. (ed), Handbuch der empirischen Sozialforschung. Stuttgart: Enke (1973). 47
46. SOURCES 19-23 17. Przyborski, A., Riegler, J.: Gruppendiskussion und Fokusgruppe. In Mey, G., Mruck, K. (eds), Handbuch Qualitative Forschung in der Psychologie. Berlin: Springer (2020). 18. Khandwalla, P.N. Innovative Corporate Turnaround. New Delhi: Sage (1992).19. Lederer, M., Thummerer, J.: Organizing a Self-Organized Team: Towards a Maturity Model for Agile Business Process Management. Proceedings of the S-BPM ONE 2022. Cham: Springer (2022). 20. Serrador, P., Pinto, J.K.: Does Agile work? — A quantitative analysis of agile project success. International Journal of Project Management, 33(5), pp. 1040-1051 (2015). 21. Looks, H., Fangmann, J., Thomaschewski, J., Schön, E.M.: Towards a Process Model for Agile Transformation in E-government Projects. Journal of Information Systems Engineering and Management, 6(1), pp. 1-7 (2021). 22. Sidky, A., Arthur, J., Bohner, S.: A disciplined approach to adopting agile practices: the agile adoption framework. Innovations in Systems and Software Engineering, 3, pp. 203–216 (2007). 48
47. SOURCES 24-29 23. Klünder, J., Hohl, P., Schneider, K.: Becoming Agile While Preserving Software Product Lines - An Agile Transformation Model For Large Companies. Proceedings of the International Conference on the Software and Systems Process. ACM (2018). 24. Qumer, A., Henderson-Sellers, B., Mcbride, T.: Agile adoption and improvement model. Proceedings of the European and Mediterranean Conference on Information Systems. EMCIS (2007). 25. Packlick, J.: The Agile Maturity Map A Goal Oriented Approach to Agile Improvement. Proceedings of the Agile. IEEE (2007). 26. Kahra, L.: Agile Transformation - How to Successfully Shape Your Transition to a More Agile Organization. Berlin: Springer. 27. Ndou, V., Ingrosso, A., Di Girolamo, A.: Framework for Agile Transformation: Guiding Organizations Through Cultural, Structural, and Competency Shifts in Project Management. Administrative Sciences 14(11), pp. 301-321 (2024). 49
48. SOURCES 30-35 28. Patel, C., Ramachandran, M.: Agile Maturity Model (AMM): A Software Process Improvement framework for Agile Software Development Practices. International Journal of Software Engineering, 2(1), pp. 3-28 (2009). 29. Diegmann, P., Dreesen, T., Rosenkranz, C.: In for a Penny, in for a Pound? A Lifecycle Model for Agile Teams. Proceedings of the 53rd Hawaii International Conference on System Sciences. HICSS (2020). 30. So, C., Scholl, W.: Perceptive Agile Measurement: New Instruments for Quantitative Studies in the Pursuit of the SocialPsychological Effect of Agile Practices. Berlin: Springer (2009). 31. Reginaldo, F., Santos, G.: Challenges in Agile Transformation Journey - A Qualitative Study. Proceedings of the XXXIV Brazilian Symposium on Software Engineering. ACM (2020). 32. Chukwunweike, J., Aro, O.E.: Implementing agile management practices in the era of digital transformation. World Journal of Advanced Research and Reviews, 24(01), pp. 2223–2242 (2024). 33. Yin, A., Figueiredo, S., Silva, M. Scrum Maturity Model - Validation for IT organizations‟ roadmap to develop software centered on the client role. Proceedings of the Sixth International Conference on Software Engineering Advances. ICSEA (2011). 50
49. SOURCES 36-41 34. Fontana, R.M., Meyer, V., Reinehr, S. and Malucelli, A.: Progressive Outcomes: A framework for maturing in agile Software development. Journal of Systems and Software, 102, pp. 88-108 (2015). 35. Weitzel, W., Jonsson, E. (1989): Decline in Organizations: A Literature Integration and Extension. Administrative Science Quarterly, Vol. 34(1), pp. 91-109. 36. Larman, C.: Larman's Laws of Organizational Behavior. https://effectiveagile.com/larmans-laws-of-organizational-behavior/ 37. Collins, J.: How The Mighty Fall: And Why Some Companies Never Give. JimCollins (2009). 38. Elorantaa, V.P., Koskimies, K., Mikkonenb, T.: Exploring ScrumBut – An empirical study of Scrum anti-Patterns. Information and Software Technology, 74(2016), pp. 194–203. 39. Krishna, V.A., Basu, A.B., Scrum: Is it ScrumBut or ScrumAnd. Proceedings of the Annual IEEE India Conference: Engineering Sustainable Solutions. INDICON (2011). 51
50. SOURCES 42-43 40. Havstorm, T.E., Karlsson, F., Hedström, K.: Uncovering Situations of Cargo Cult Behavior in Agile Software Development Method Use. Proceedings of the 56th Hawaii International Conference on System Sciences. 41. Berkania, A., Causseb, D., Thomas, L.: Triggers analysis of an agile transformation: the case of a central bank. Procedia Computer Science, 164(2019), pp. 449–456 (2019). 42. Carroll, N., Conboy, K.: Applying Normalization Process Theory to Explain Large-Scale Agile Transformations. In Proceedings of the 14th International Research Workshop on IT Project Management. Munich: IRWITPM (2019). 43. Tushman, M.L.: Special Boundary Roles in the Innovation Process. Administrative Science Quarterly, 22 (4), pp. 587–605 (1977). 52
52. 👀 🤖 🚀 🌟 🙈 ⏳ 🛠 💥 💀 Awareness Transformation Breakthrough Optimization Mentoring Blinded Inaction Faulty Action Crises Dissolution Prompt action Corrective action Reorganisation action Agile maturity Time Agile Maturity MODEL 54
53. ⏳ 🛠 💥 Inaction Faulty Action Crises Prompt action Corrective action Reorganisation action Agile maturity MENTORING FOCUS 55