What is the standard terminology for the scenario of the agile iterative cliff?

Question

Sometimes you get into a scenario where a software team is iterating quickly and delivering lots of software. Over time, failure to do housework and paying off technical debt leads to productivity going down.

They eventually approach a point where all the resources of team are used up in overcoming the accumulated cruft just to deliver simple changes.

This appears to be a tipping point in technical debt. An associate referred to it as the agile iterative cliff - but that doesn't register on Google.

My question is: What is the standard terminology for the scenario of the agile iterative cliff?

Answer 1

The term gridlock seems appropriate. Mind that I just made this up, it is not a broadly accepted term for the situation you describe.

You keep adding scenario bound quick and dirty fixes until you reach a state that does not allow another quick fix without breaking something else. So there is no longer a possibility to make a move by just tweaking something, you have to take the whole thing apart and start over.

I call the methodology that leads to this situation "rushing to the exit". No analysis is performed, nothing is modelled, issues are addressed ad hoc, one at the time, until they stop coming in. If they do not stop coming in before gridlock, you have an expensive problem.

As Frank pointed out, this is not equivalent to agile. Agile does not mean stupid, lazy or reckless. Agile is just a formalized way to not let formalities/overhead gridlock your project. If done properly it even reduces the risk of technical gridlock.

Answer 2

I've never heard of that term, which is probably because it doesn't make too much sense - in my experience there is no tipping point. It's a gradual thing.

The only real tipping point happens once you realize that technical debt exists and you need to get rid of it. At that point your productivity will fall massively, because at the same time you need to refactor the software, retrain your software engineers, and take a more measured approach when working on new projects.

If that realization doesn't happen, the entire thing is usually called a death march, but that is a rather generic term which encompasses various kinds of failures, not just technical debt. It describes a failed company/project/software where the people in charge have yet to realize it failed, and generally try use the same methods to save it which they used to run it into the ground.

Answer 3

It sounds like a death march with infinite defects methodology.

Joel explains it here like this

The very first version of Microsoft Word for Windows was considered a "death march" project. It took forever. It kept slipping. The whole team was working ridiculous hours, the project was delayed again, and again, and again, and the stress was incredible. When the dang thing finally shipped, years late, Microsoft sent the whole team off to Cancun for a vacation, then sat down for some serious soul-searching.

What they realized was that the project managers had been so insistent on keeping to the "schedule" that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote "return 12;" and waited for the bug report to come in about how his function is not always correct. The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as "infinite defects methodology".

It's not a new concept. This was long before the "agile manifesto" or any other newfangled jargon from the 2000s. (You Dang Kids Get Off My Lawn.)

Answer 4

The generic term is bad software engineering. It really has nothing to do with agile or any other methodology. You can create this problem with any methodology.

I put this answer here as a counter to the term "technical debt." I don't like that term as it implies that the "debt" (i.e. poor design) is inevitable.