Recently, a team at a client that had been having success with the managerial practices of Agile was beginning to feel the dull pain of gradually mounting technical debt. The lack of automated tests and a slew of code smells were pointed out, and the developers were quite keen on learning how to apply their new skills for identifying and eliminating debt taught to them by technical coach Mark Levison.
It was pointed out to the team's management and the Customer that there would be some cost to paying down the debt, not unlike the Principal and Interest ratio in a loan payment. While the payment is the same (the length of the iteration), the amount paid as interest (technical debt) gradually becomes less and more is paid towards the principal (stories). This was accepted, although the Customer correctly wanted to be able to at least see what work was being performed to pay down the technical debt.
After this meeting, the development team's manager talked to me. He was concerned that the developers would be spending time trying to make the system "perfect". While I agreed that "good enough" would suffice, I didn't agree with this manager's next assertion: "The system isn't going to be changed after this next bit of work is completed." I pointed out to him that the vast majority of work on a system is performed after it has been released into production, but he still had a lingering concern.
Fast-forward a few days, and I'm notified by this manager that the team is losing one of its developers and half of the time of one of its business analysts. I was not happy, to say the least, and asked why this was happening. The manager said that their last project needed them back to do some new work. I asked, "What new work?". The manager replied, "Some new requirements came up after the users got the system in production."
He didn't seem to understand the irony of the situation.