Setting Up Global Agile Teams- Sustainable Bug-Free Code

It is clear that in this rapid conversion this team learned how to operate using agile practices – to an extent – but managers did not learn how to monitor this new Agile system and use the leverage points that could have kept the situation from spiralling downward. Pleased by the quick turnaround, they expected it to just remain on a course of its own accord.

Agile systems don’t automatically stay on track. No system does; they all need some degree of monitoring and adjustment to counter entropy. In an organization, the “Agile system” consists of the core team, plus the stakeholders [2] who’ve chartered that team, and others who manage or interact with the core team. As part of an agile adoption programme, managers need to learn the critical role they must play in fighting entropy by exercising control in a new way.

Let’s look at a simple analogy. If enforcement of traffic laws were suspended, it wouldn’t be long before there would be chaos on the roads. People who want to follow the rules would have to respond to those who don’t, and the whole thing would spiral downward. Likewise, in an organization, it is for managers to understand the laws – the critical leverage points – and use them correctly to keep the flexible system running with minimal ad hoc intervention.

Let’s take it one step further. Suppose there has been a breakdown–as we’ve seen with the Comet team—what are managers to do? An accident, flooding, or downed trees can create a big traffic jam on the road. Regardless of the cause, the individual motorists are powerless to move their vehicles once they are caught in the gridlock. No amount of pressuring or punishing them makes any sense. The first thing the police do is not to pull cars out of the jam, but to halt the inflow of more cars. They block off the routes into the gridlock, thus preventing it from growing. Next, they free cars out the other side by clearing the blockage.

The jam is a system problem, not a question of the individual motorists. Although each driver has responsibility for controlling their vehicle correctly, that won’t prevent or solve traffic jams. Likewise, many of the problems that software teams experience are system problems of their company. Executives and managers govern that system and have a unique role to play during and after a change to agile.

Technical Debt and Latent Bugs

Let’s look at Comet’s big issue. Activation of bugs in the legacy code via new features added to the code base was the initiation point for the unravelling. “Technical Debt” is a term covering hidden problems in the system: unnecessary complexity, unclear naming, excessive coupling, inflexible architecture, and latent bugs. Correctly running software can have these breeding grounds for germs. Technical Debt shows up when you try to make changes to the software. It makes bugs far easier to create, even for careful developers.

All software has technical Debt. But code written the agile way with robust unit tests has much less Debt and therefore far fewer bugs–typically one or two orders of magnitude fewer. In Comet’s case, technical Debt was getting removed incrementally. This is normal. Removing it all in one go would mean having to focus on that alone for quite some time without building new features. That would be unacceptable to the project sponsors.