Pay it down or you may go belly up!
6 June 2016
Achieving high quality
Have you ever heard an Agile team referred to as "high performing"? If someone asked you to define a high-performing team, would you be able to do so? The truth is, everybody's definition of high-performing teams is probably different. What immediately comes to my mind is that that they're predictable, trusted, and value driven. No team is going to get to that level without a relentless pursuit of a high-quality product. However, I'm not here to define high performance but rather what leads to it. We know that we're only as good as our people, so for the sake of this argument, let's assume all high-performance teams have great team members. Throughout the years, I have been fortunate enough to encounter a fair share of high-performing teams. If there was one commonality among them, it was quality.
The word quality can have many different meanings, so let me clarify. Many will refer to quality as the degree to which a product is fit for its purpose and satisfies the client's requirements. In an Agile environment, we mitigate the risk of subpar quality by delivering working software early and often to get feedback, and we pivot if we are not heading in the right direction. The other flavor of quality is associated more with the reliability of the product and the prevention of application outages, hard errors, and regression issues in which deployment of a new feature has negatively impacted existing functionality. This is the type of quality that high-performing teams are always considering, and they bake preventative measures into their daily development processes.
What leads to technical debt
From my experience, outages, errors, and regression issues can typically be attributed to one of two things: technical debt and lack of testing. We all know that if development and testing are not seen as one activity, then the team is probably not high performing. However, I would also argue that if technical debt isn't managed on the backlog with everything else, and is not periodically paid down, then it also could prevent a team from getting to the next level.
Technical debt was a term coined by Ward Cunningham, one of the authors of the Agile Manifesto. He used it to refer to the idea that, structurally, the code was not up to par and carried more potential to negatively impact productivity. Therefore, it is something that should be periodically "paid back," much like financial debt, as a preventive measure to guard against instability.
Technical debt is a natural product of traditional and Waterfall behaviors in which the development and QA teams are held to the fire to meet a project delivery date. In response, development and QA teams deliver a subpar product to the client. Shortcuts are taken and code is hacked together, all for the sake of meeting a date. Most organizations will categorize these types of substandard solutions as "interim," yet they almost never revisit and refactor them. These interim solutions are considered technical debt.
Effects of technical debt
Make no mistake: Technical debt puts the business at risk. It typically does not have the design resiliency and scalability to survive the test of time. Chances are that many of the firefights that your company so frequently experiences are due to some type of technical debt. If not consistently paid down, or in technical terms refactored, technical debt can destroy an organization.
I once worked at a software vendor that had no core product. To clarify, there was no main code line that could be branched or released when the company sold to a new client. Instead, a copy of an existing client's code was made, and new development was done on top of it to satisfy the new clients' requirements. Existing client features were often duplicated because of a lack of communication among the project teams. This pattern occurred repeatedly. The excuse of not having a core product in which all new features were added and tested was of course due to lack of time and the need to meet a delivery date.
When we implemented Scrum, sprints were constantly derailed and new features could not be delivered due to daily client production firefights. The amount of technical debt had spiraled out of control. Sad to say, the company was literally drowning in technical debt and unable to continuously deliver value to the customer. The amount of time and money spent duplicating features and supporting production incidents was unfathomable. It could all have been avoided up front with an investment into a core product that was relentlessly developed, refactored, and tested. A small price to pay compared to the costs they have accrued in production support.
Paying it down
The moral of this Agile story is that quality is the catalyst for agility. Therefore, companies that want to "be" Agile should be willing to invest in quality up front. Paying down technical debt is part of the investment. Sure, no product owner is going to want to tell the business that they are fixing technical problems instead of delivering new features. However, we need to educate the business sponsors about the risk of keeping this debt and its potential cost. We should also take this a step further and educate the business about the risk that we accrue when we rush to meet an arbitrary project delivery date. In both cases, I am willing to bet that the investment in paying down the debt or not taking it on will far outweigh the potential cost.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.8 (4 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.