Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
A number of stakeholders do not quite understand the necessity of dealing with technical debt preferring new features on top of not very maintainable code. Development is sometimes seen as kids who just want to play the coolest toys.
Can anyone suggest anything which will make the job of 'selling' the necessity of dealing with technical debt as a main priority?
Any youtube videos, articles, books recommendations and links on success stories would be very appreciated.
You might tackle it by highlighting increases in development costs caused by technical debt. That is a problem we are facing right now, too. Business is requesting more and more features they need when my team really wants to remove technical debt.
We underlined that with less technical debt new features can be shipped way faster- and faster means cheaper. And cheaper, with possibly increased quality, always goes a long way with non-technical folks :)
It is a bit like pausing chopping wood in order to sharpen your axe.
In one of my previous projects, we had a major part of a site run on annual data put together by the business. Unfortunatley, the database had been architected in such a way that each year's data will go into a separate database. When it came time to launch the current year's data, it needed a lot of grunt work by the dev team as well as extensive testing.
Our dev team did an estimate of how much effort it will take to make changes to the architecture and the code base. Then, we also estimated the saving in time each year as a result of the change. We then sat with the business team and got approval for the one-time effort to pay down this technical debt.
I like this more proactive approach advocated by Steve McConnell: How to Categorize & Communicate Technical Debt
You can also try his other suggestion - when the velocity starts to drop, see if it is because of too much debt. Then devote an iteration to reduce technical debt with the expectation of the velocity to increase.
By analogy, you are asking people to replace a car that works perfectly well because you know that at some point in time the cost to maintain the existing car won't be worth the effort. You need to provide them with thoughtful estimates of when that point in time will be. In other words, the only way to convince them is to come up with a clear, justifiable business case. If you can't document what the benefits are in dollar terms you are just swimming against the current.
To be honest I haven't seen many people in IT shops willing to commit to cutting their systems maintenance budget by $X per year if given $Y to upgrade their systems. Most either position it as a cost of doing business or make the argument that risk of catastrophe is being reduced. This may all be true, but isn't a convincing argument because it smells (like you say) of boys wanting toys. From a PM's perspective it also seems to me like a good way of getting away with not thinking through the benefits side of the equation, which I find annoying.
The non-technical stakeholders only need to know how much work is needed to add the new feature. Like unit tests, refactoring should be included in the estimate for adding the new feature. It's part of the development process.
If you can group features together that all benefit from the refactoring then the extra work can be spread over the group and isn't allocated to any single item. This is usually more palatable.
Here's the rub: Many a time the stakeholders have asked me why a change will take longer than the last time we made a similar change. Good - the stakeholders aren't stupid and they are paying attention! My answer is, "We've outgrown the original design. Based on the number of past changes related to this new feature we need to implement a new design. This will allow us to add this new feature and support it in production."
What you're looking for is an analogy that will help them understand the problem in simple everyday terms.
I highly recommend the video I link to below, which shows a mechanic, adding features to a car in a completely unorganized way to such an extent that for example, adding a GPS will cause the car not to be able to make right turns.
Ward Cunningham originally came up with the metaphor of technical debt to “sell” the notion that the costs of refactoring code “up front” significantly outweigh the costs of having to spend time “down the line” building additional features on a code base with restricted extensibility. He used the metaphor of “debt” at the time because the people he was trying to convince were finance guys and he wanted to connect with them in a language they could understand.
If you need to “sell” the same fundamental idea but the metaphor of technical debt is not doing the job, presumably it is because the people you’re trying to convince are not finance guys. In this case it’s worth searching for a new metaphor which your target group can easily relate to.
Here’s an a simple idea of how to create a different metaphor:
A young guy, let’s call him Mike, gets his first paid job and decides it’s time to move out of his parents house and into his first flat. To start with Mike takes a spacious but simple room where he can sleep and keep his stuff but where he needs to use a shared bathroom with other tenants in the block.
After his first pay raise, Mike decides it would be nice to have a bit more convenience by having his own washbasin instead of using the one down the corridor. He calls up somebody to help him implement this and although they advise him that it’s best practice to build an enclosed bathroom where the washbasin can be installed, he decides for the less expensive option of installing it next to his bed.
Time moves on and Mike gets a promotion at work at which point he starts to think “This convenience and privacy thing is great! I think I’ll get a shower in here as well!” So he calls up the washbasin guy and starts to discuss options. Now the washbasin guy again provides some lower cost and higher cost alternatives but this time is quite insistent that the higher cost option of building a standalone bathroom is the right thing to do because it will give Mike the option of installing a WC and bathtub in the future. Mike thinks long and hard about this - as well as the cost of building the bathroom, there’s also the cost of moving his washbasin in there as well. And he’s not even sure if he’s actually going to want a WC or bathtub anyway. After thinking it over for a couple of days Mike decides to take the washbasin guy’s advice and get a standalone bathroom built in. “There’s some extra cost in doing it now” he reasons “but it will be worth it in the future as I’m pretty sure now I’m going to need a WC or bathtub and I want to avoid the cost of having to relocate both my washbasin and shower from the living room.”
This story has a happy ending. The alternative (less happy ending) sees Mike opt to install his new shower next to his TV and later he’s forced to shift both washbasin and shower to his bathroom anyway.
In this metaphor the washbasin guy (i.e. the development team) is recommending the creation of a standalone bathroom as well as the relocation of existing amenities (i.e. a refactoring of the existing set up) to prepare for the installation of a WC or bathtub (i.e. development of future features).
It’s quite a domestic example, but hopefully it helps you think of others more applicable to your domain.
