Good Agile teams manage their TechDebt, great Agile teams never let it pile up.
I was recently conducting a team Agile assessment using my good old questionnaire, asking questions and touching upon practices, grouped in three buckets for People, Process and Technology. Toward the middle of the Technology section, there was the "Technical Refactoring" question, with a grading scale from "It is frowned upon" to "It is integral to continuous improvement." The team had a lively conversation about where they are with managing TechDebt and how they can improve. (They didn't score themselves too high, but agreed on a plan to get better about it.)
It struck me a few hours later when I was doing my own scoring and analyzing the data, that if teams don't watch out they begin to accumulate not only "Tech" debt but other "debt" as well.
When technical teams stop refactoring their code (and there are always good reasons for putting it off - fast-tracking features, meeting release deadlines, keeping happy the stakeholders who pay for the product), TechDebt starts to pile up. Initially, one can't really notice it. It is like buying a large-screen TV on a credit card. The amount is not too big and you know you can pay it off anytime with some modest sacrifices. But "anytime" never comes because of the PO keeps insisting on applying the limited cash income (velocity) toward building new features. Over time, the compound interest starts piling up and gets more noticeable - releases take longer and longer because the regression suite had bloated over time and the team never found the time to create an automation test framework; bugs take longer and longer to fix because the team never took the time to refactor and untangle the spaghetti code put long ago in a rush and without any documentation.
If the team doesn't pause to take systemic and significant steps toward burning down their TechDebt, they soon find themselves at a grinding halt. (Check out the Unicorn Project by Gene Kim for a great and rather realistic dramatization of a fictional organization in this situation.)
Unfortunately, the same pattern can repeat in the other two non-technical pillars of People and Processes. It is more subtle and difficult to pinpoint, but at the same time - with very noticeable manifestations.
Teams accumulate People (or, Social) and Process debt when they go through a major reorganization or significant personnel turnover without taking the time to properly heal - i.e. go through the natural forming-storming-norming progression before they can become high-performing. Similarly to the TechDebt, if teams are put under the pressure to deliver results immediately, without taking the time to build their written and non-written agreements, teams start accumulating SocialDebt and ProcessDebt.
It is not a big deal initially, somebody makes an impatient remark or the team cuts short the Retro ceremony because it is Fri afternoon, they all had a long week fighting fires and the Product Demo went overtime. Over time, the impatient remarks snowball into snarky comments, verbal sparrings, passive-aggressive behavior, lack of trust and all-over toxic atmosphere where people can no longer come together to joint decisions and they start working in competing enclaves. Conversely, the occasional missed Retro blows up to systemic issues with how the team breaks down, plans and executes work together. They are all aware of the right way to do things, but they can't seem to find the time or energy, or consensus to do it.
Even more unfortunately - trouble usually comes in threes, as they say. One kind of "debt" usually brings along or is a strong indicator that the other two are present as well. TechDebt accumulates because the team doesn't have solid processes for code quality review and/or because there is lacking a strong social contract between the PO and the team to communicate and understand the importance of technical refactoring.
What can teams do about it?!
An old mentor of mine used to say:
Sometimes we need to slow down in order to go faster!
Analogously to the consumer debt example above - when the situation gets intolerable, it is the best to:
- pause,
- ask for help,
- forego what's non-essential,
- come up with a realistic plan to pay off the debt,
- stick to the plan.
In the fictitious example from the Unicorn Project, the leadership of the company institutes a 1-month feature freeze to allow the teams to fix their bugs and build their CI/CD infrastructure.
In real-world scenarios and working with actual teams, we've created TechDebt and Chores user stories or tasks in the backlog and co-mingled them with the Feature stories. Each iteration, we'd pick a certain percentage of Feature and TechDebt/Chore user stories. In the first couple of iterations, the ratio was close to 40% - 60%, until we rebuilt the team Working Agreement and recreated some of the foundational practices. Gradually, over the next several iterations (a couple of months), we gradually tilted this ratio to 60%-40%, 80%-20%, and 90%-10%.
TechDebt and ProcessDebt may be painful and hard to burn down. However, SocialDebt if not addressed early, may become irreversible and irreparable. Bad code can't go anywhere, but people with hurt feelings have options - they'd rather move on than put up with a toxic team environment. Bugs and spaghetti code can be fixed, retested and forgotten about it, but humans tend to retain the bad memories from the past. Human minds are wired to remember the negative experiences a lot longer than the positive experiences. There is an old adage in couples therapy that for each bad word, a partner must say 5 good things about their partner. The same applies to teams and team dynamics - it takes sustained, focussed, and usually externally-facilitated effort to rebuild a dysfunctional team. Unless the team leadership invests in effective coaching, the only practical resolution often is organic attrition.
To rephrase my opening statement:
Good Agile teams manage their TechDebt, great Agile teams watch out for Social, Process, and TechDebt and never let it pile up.