As a result of a retrospective we were uncovering worse ways of developingsoftware. We had a idea we though was great and tried it. We stayed with it during the development of a major update which took 3 months. After a retrospective with the maintenance engineers it turn out our idea does not work for them (we had discussions with them before we tried the idea and the also thought it was a great idea). We came to the agreement we better get back to the old situation. The team for the update is dismantled and the maintenance engineers don't have time to do so (although their project manager has agreed to invest the time).We're now in the situation the maintenance engineers pay the interest each time a minor release has to be made. This is very much like technical debt but has nothing to do with the product itself. Is this called process debt or is this put under the term technical debt? And what would be a good way of dealing with it? (Any other or concrete ideas to make it visible to product managers?)PS The idea was migrating a 4 product VSS database to SVN. The database heavily leans on shared files and is a mess to untangle and pour in a usable SVN structure. It's very counter intuitive but is seems some things are better kept in VSS.
Is 'process debt' a term people work with
agile;version control;terminology;retrospective
I hope I have interpreted thing correctly, I would call this technical debt. Software consists of more than just source code. Source is probably less than 10% and no more than 20% of the SDLC effort (At a commercial level at least).  If you cannot reliably and easily build and deploy your source code, causing problems and costing money down the track, it's no different to source code that is hard to maintain, buggy and slow. The fact you tried something different and it was not as good as what you left behind does not change things either. The software is now in a less maintainable state than it was previously, because of chosen technologies (VSS vs SVN) - technical debt. The Process Debt you refer to undoubtedly exists, but that's due to the process making you do things that are no longer required. For instance if you had a process that required manual running and markup of a printed test book on each release, but you had implemented automated testing, that would be process debt, as it's something that is no longer relevant due to changes in the way things are done. 