Social Network

Twitter

Release debt: Agile development and Waterfall releases

Unless you have some really great connections, every type of debt I have ever had the displeasure of dealing with has come with some sort of interest payment. If your company has adopted Agile software development methodologies (Scrum, Kanban, XP, etc), but is only delivering software on a quarterly basis (or less often), chances are that you are paying a ‘release debt’ with interest.

If the concept of ‘technical debt’ could be overly simplified as ‘stuff that you’ve been meaning to fix‘, then you could easily view release debt as ‘stuff that you’ve been meaning to deploy‘.

Both types of debt are mostly caused by the same source: business pressure. The business says that they need to release a feature soon to compete with a competitor, or be the first to market with something. Which is ironic because they’ve chosen to pick an arbitrary date marked on the calender months from now instead of releasing it as soon as it’s ready.

Even if you are Apple, Google, Facebook, or some other type of large company with clout in a given industry that chooses to hold it’s own annual/bi-annual/quarterly conference/junkets, that arbitrary date marked on the calendar is a self imposed, artificial barrier that provides no value other than highlighting the fact your marketing and public relations team can handle a large amount of media inquiries at one time. Seriously.

Given the diversity and speed of start-up companies today, the last true competitive advantages anyone has now are:

Time to market

Quality

I shouldn’t have to argue that the large releases do nothing to achieve either of these competitive advantage, but the argument is somehow still required. You didn’t deliver to market the moment it was ready, and the fact that hell-or-high-water you were going to release a feature on X day means there is a path of dead bodies hidden somewhere.

Technical debt is accrued when the necessity to deliver something by a given date overpowered the need to fully understand implications, creation of supporting documentation, refactoring efforts to ensure loose coupling, multi-team collaboration, and many other factors that play into the development of a quality product.

Those dead bodies are technical debt written into stories that you weren’t able to do the first time around and hidden in the backlog behind the next set of features that are coming with the next release. Chances are, those stories are now going to haunt you on deployment day, future refactoring time estimations, and with each additional feature implementation. You’re now paying an interest payment on your technical debt.

Release debt is accrued when the necessity to deliver a large number of changes at once through one of these media extravaganzas has forced you to withhold every change the development team has provided between those arbitrary release dates. One of the things you’ve undoubtedly felt is reminiscent of Wizard of Oz when you go to perform the actual deployment – “there’s no place like production”. Something goes wrong and now you’re asking the development team to recollect how that feature from four months back actually works.

Given what’s happen over those last four months, your development team has succumbed to low to moderate memory loss either through losing it’s knowledge on the complex software components, forgotten the small details that had a huge impact on the behavior, or lost entire members of the team through turnover. You’re now paying an interest payment on your release.

This isn’t to mention that you’ve waged a shock-and-awe on your customer base, which in some instances translates to a tsunami of critical feedback for the multiple areas of your product that you’ve changed or added. Interestingly enough, I bet those hotfix/workpack/service pack releases where you address those most critical issues never have their fair share of deployment fallout when compared to the large deployments.

In any event, you are now paying two types of debt because you’ve chosen to disconnect your development and release cycles from one another.

Unfortunately, if you don’t break the vicious cycle by making larger, continuous payments to touch the principal of your debt, your payments are only going to be hitting the interest. Release debt is almost never paid down and whatever balance is left gets rolled over as technical debt.

Releasing features as they are immediately ready will provide for a much higher quality product, allow your marketing and public relations team (in addition to the engineering teams) to have a better work-life balance, and keep your company’s name continuously in the press spotlight. You would be much more flexible to emerging marketplace threats, responsive to your customer’s problems, and enable your development teams to change what is required to acquire simplistic and reliable designs.

Multiple companies have acknowledged their current method of Agile development with Waterfall release cycles are hurting them more than helping. They’ve realized that if they aren’t providing the changes and fixes to the customer base as they become ready, they are only truly delivering business value instead of any customer value. If all you’re doing is checking off everything on a team’s Definition of Done without actually putting anything into Production, your customer is only getting lip service for the money they’ve paid until you decide to actually release it.

The ability to perform Continuous Integration and Continuous Deployment is a great start, but means absolutely nothing if you have a segregated or buffered delivery pipeline. If you want to really help yourself and your customers, you need to have the shortest feedback loop cycle possible with a larger number of stakeholders involved. Getting those changes down the entire delivery pipeline into Production using a single workflow is paramount to providing that short cycle with both business and customer value, and reaping all of the benefits from Continuous Delivery.

As an added benefit, you will no longer be to accruing any interest, adding any debt principal, and should be making much more regular technical debt payments. So long as you stick with it, you should reach near-zero technical debt after a couple of years.