Working on an ongoing development project, one becomes familiar with the idea of technical debt very quickly. While many definitions abound, the best analogy I have heard is to compare technical debt to a financial debt. It may get you something faster in the short term, but eventually it will need to be repaid and with interest! Indeed, the current turmoil in the market shows just how devastating mismanaged debt can truly be. Fighting cultural dysfunction that allows technical debt to accumulate is a major challenge a scrum master faces.

This got me wondering, is there an interpersonal equivalent to technical debt that would operate in a similar manner? Much like neglecting technical quality, could people suffer from accumulating “organizational debt”? From my own experience, the answer would be yes. Who among us has not seen the hard nosed, “get it done at all costs” individual who has success on a few projects but burns innumerable bridges along the way? Such a professional may succeed if they can keep on moving from area to area, but this does not seem to be a formula for lasting professional success.

Looked at another way, we can see that trust is the foundation of so many concepts of Agile Software Development. It is the critical enabler that evolves the relationship between a project team and it’s sponsor from one of contract based negotiations to productive collaboration. Some of the riskiest ventures are those when such an interaction is forced by the necessity of a situation rather than a natural outgrowth of human interaction and team building. People will begin to follow the motions, but without trust it is not clear that an earnest interaction can take place.

What does such a situation look like? It’s the product owner leaning on the team to make additional commitments above and beyond what they can commit to. It is the team members padding sizing estimates as they assume they will be forced to do more anyway. It is the frantic effort to hide the warts of a product prior to a show and tell due to a fear of revealing problems. I would posit that all of these are symptoms of the larger issue of a lack of trust.

Going back to the analogy of technical debt, there are various techniques that teams can use to limit and manage the accumulation of such a debt, and I have seen many teams explicitly add stories to their backlog accounting for the debt that must eventually be paid. However, what similar practices or tools do we have for the health of relationships between our team members? An organization must not only have engineering best practices but also have complimentary organizational practices to help foster a team spirit and build trust.

There are a number of tools available to support building trust such as regular retrospectives, respect for team based commitments and concensus based decision making. It is not the particular technique that is so important, but rather the prioritization and commitment to building a cohesive team and healthy relationships with our coworkers. It’s always easier to focus on “hard” skills and capabilities, but they are not sufficient on their own for effective, agile software development. While I don’t expect to see teams start adding stories to improve team morale or patch up a tenuous relationship between two team members, we should acknowledge the cost of these situations. Whether it be technical or organizational in nature, one should be be aware when accumulating such debt and be sure to manage it properly.