Opening Remarks: This article is the synthesis of our experience as Agile coaches and data gathered from Agile practitioners in our network. We do not have the presumption to cover every aspect of Agile complexity. We are gladfully welcoming feedback to start a conversation on any aspects that might spark your interest. 

Introduction on hands-on guide to avoid pitfalls in executing an Agile project
Pitfall #1: Losing faith in the team
Pitfall #2: Confusing agile and disorganization
Pitfall #3: Hiding yourself in the basement
Pitfall #4: Underestimating planning value
Pitfall #5: Not getting out of your Agile bubble

Pitfall#6: Being overwhelmed by technical debt


You have been practicing Agile for a while now. You have improved how your team work together by setting the right management artifacts. But somehow, it seems that something is still wrong: 

  • The effort to develop new features grows continuously 

  • Releases cause regression in existing features 

  • Application’s availability drops due to unexpected bugs 

These are common symptoms of Technical Debt

What we define as “Technical debt” (1) is extra effort and re-work incurred in any software project which will eventually have to be repaid. It can come both from poor initial design choices that would make certain portions of the code being written obsolete or from deficiencies in software design and / or code quality due to compromise accepted to meet deadlines and deliverables in fixed scope and time projects. 

In traditional projects, a lot of effort is invested upfront to avoid such rework and compromises, thus allowing to maintain a low level of technical debt throughout the entire development lifecycle. This approach is suitable for fixed scope projects where all the requirements and expectations are known and not expected to evolve during the life of the project. It was mostly the case in the early years of software development, but in Agile projects however, the focus is more on “testing and learning”. Fast adoption of new market requirements is enabled by allowing software architecture to evolve during project lifecycle instead of being locked in the beginning. It is thus perfectly acceptable - and sometimes even desirable - to have “imperfect” code (2) to be able to demonstrate quickly, to gather feedback and refine project priorities. 

Exhibit 1: Illustration of the evolution of technical debt on two projects 

We believe that there are 2 pillars to keep in mind when handling technical debt in an Agile context: building team capabilities about tech debt management, measure and manage technical debt in existing Agile artefacts (3) 

Team capability building 

On the one hand, focus on business stakeholders’ education, as it is critical that they have a minimal understanding of what technical debt is. If they are new to Agile and/or IT development, you should consider having a dedicated session to present them with the metaphor early in the project. This introduction should not get into the technical details, but rather focus on the compromises that a conscious handling of technical debt means for business (i.e. frequent releases now vs. frequent releases in the future, frequent release now vs. stability of the system, frequent release vs. fine-tuned user journey). This will help protect the technical team from impatient product owners and help business stakeholders make enlightened time-allocation decisions between developing new features vs. cleaning and improving the existing ones. 

On the other hand, focus on building a healthy culture of transparency in the dev team. Raising technical issues should be promoted through positive feedback to encourage teams in sharing their technical problems and not hiding them. So-called “problems” should be seen as opportunities to strengthen the test base and improve the team’s capabilities. All team members should master notions such as pull requests, code smells, or clean code concepts (4)

Measuring and managing Technical Debt 

The image of debt was chosen purposefully: not repaying it means that you will have to face capital and compound interest reimbursement in a not so distant future. That is why it should be dealt with continuously and embedded into traditional Agile management artifacts. This means that it should be embedded and shared in ceremonies through the creation of transparent artifacts. We recommend you consider the following when it comes to managing technical debt: 

  • Ensure Team Leads have final authority on when and how refactoring should occur 

  • Create technical user stories, and prioritize them in sprint planning just like normal feature work 

  • Allocate a regular effort in every sprint (e.g. ~20% of capacity / points) to tackle tech debt 

  • Dedicate time to do post-mortems and codify learnings when high technical debt was generated 

  • Use code analysis tools and code smells to support prioritization of tech debt to work on 

Having such an incremental approach will help the team build the habit of estimating the complexity and time needed to deal with technical issues and provide transparency to business stakeholders. Without doing so, the team will reach a point where technical debt becomes overwhelming, significantly slowing down releases. This will call for a specific “Debt removal project”, meaning that the development team will only work on technical issues for a long-lasting period (up to several months) in order to be able to deliver at its previous pace. 

  (1)This concept was first introduced by Ward Cunningham in 1992, see here for a quick video introduction
  (2)This example from Dave Nicolette in the banking industry shows how a “quick-and-dirty” solution helped a banking client win 2 million $ yearly with conscious decisions on Technical Debt, with little added support costs
  (3)Some might argue that a proper tooling is as important as all the above to tackle technical debt (e.g. proper test environments, static code analysis and monitoring tools, etc.) but it is not specific to Agile, we decided to exclude it from the current analysis
(4) Clean Code, a Handbook of Agile software craftsmanship, Robert C. Martin

This article is part of a series of articles on Agile pitfalls and tips to avoid them. You will find the complete series here addressing People, Processes and Technology. You are interested to know more on the technology dimension, check how you could adopt new ways to test.

Are you interested to work on Agile projects and support our clients in their digital transformation? We are hiring: check our job offer!


Parutions récentes

  • Image de l'article
    Abécédaire d'Orphoz
    Oct. 26, 2021

    F comme Flexibilité


    Lire la suite
  • Image de l'article
    Who we are
    Sept. 21, 2021

    Que sont-ils devenus?

    En déjà dix ans d'existence, Orphoz a vu grandir bon nombre de talents. Nous avons décidé d'aller à leur rencontre et de les interroger sur leur nouveau métier.
    Merci à Claire, ancienne consultante chez Orphoz, qui dévoile les coulisses de son rôle de PMO et consultante interne en industrie.

    Lire la suite