This is a rehash of a topic I posted about back in 2008 but it is just as relevant today.
When you work towards a release or some other looming milestone. There’s that urge to leave stuff behind, cut some corners – you know, just a wee bit, no harm done – so we can ship the damn thing already. Mostly you’d fight that urge. But sometimes you’d want to make a conscious choice to make a shortcut because, well, sometime delivery is more important
A little drop in quality in a single piece of code will not do much harm…for a while. There are, however, two problems with going this approach. One is that it is a slippery slope, i.e. it is probably not just one piece of code that gets this treatment in your code base. The second problem is that if low quality code is left alone to fester and then you add additional layers on top of it, it will be harder to change the original code later as more code need to be refactored. The term the industry came up for this low quality code you leave behind is “Technical Debt” . This is a good metaphor since as I mentioned before it gets worse with time and you need to pay it back.
Technical debt is going to be part of our code bases whether we like it or not – what we want to make sure is that we manage it. The best way to manage it is to make it explicit – make technical debt part of your product backlog – every time you get the urge to add a //TODO comment add that into the backlog.
Having the technical debt on the backlog has several benefits such as
- It will not be forgotten – it will be documented…
- It will not be hidden – The true state of the product will be in the open for management/product owner to see. As a manager I want to know the true state of the product. If I know what I can and can’t have I can get ready for that. If I think everything is rosy and then the system blows up in my face, that’s not so good..
- It will be managed – The importance/relevance of the “debt” will be reevaluated every time the product backlog get prioritized.
Technical debt will occur in your project, whether it is agile, “water-falled” , incremental or what not. Don’t ignore it
illustration by eric731
Hi, we created a plugin just for this…http://kenai.com/projects/csdutilities/downloads
Nice :)
You should have given the link to the wiki page that explains it: http://kenai.com/projects/csdutilities/pages/Debt
This is a really terrible advice. By putting TD on the backlog, you give Product Owner control over quality, which is responsibility of the development team. Most of the time, refactoring will be prioritised below new features and never get done.
It appears you have a dysfunctional team, which doesn’t take ownership of quality and you don’t trust them to maintain it at sustainable pace. This is exactly why teams decided what to commit to, they are in control of how much time they dedicate to new features and how much to refactoring.
Another issue with your approach is velocity. By adding debt to the backlog, it will count towards velocity, looking like actual progress on your product. You will lose crucial feedback loop that is fundamental to Agile. Instead of having visibility on the technical debt eating into productivity (visualised by decreasing velocity), everything will look fine (flat line, maintained velocity). No matter how bad the team does, and how much debt you accumulate, the velocity will look like the team is as productive as ever.
This can be avoided if you don’t assign it any effort, which you didn’t say you do or not. Unfortunately, I’ve seen many teams trying this approach, and they always chose to estimate it. Hence, anyone reading your advice, is likely to take this approach and seriously compromise their process.
First off, if your product owner is not concerned with the quality of the product then your team is in terrible state probably worse than “my dysfunctional team”
It is the team’s responsibility to allocate time to repay technical debt just as much as it’s the team’s responsibility to fix bugs entered into the system. I trust the team to do that. I want to know the quality, I want other stakeholders to know that as well
If you don’t document technical debt properly the chances it will be forgotten there is, in my opinion, worse than all the other problems you mention. if the effort is not known than the time allocated for this is “stolen” from the product owner without their knowledge – what type of transparency are you expecting to promote with that when you expect all this effort to go under the radar. if you want to count velocity for new features only then don’t count the effort there, but if you want to know how much “stuff” you’re going to have in the next iteration (assuming you use that over kanban-like flows) then you need to have the effort there (same for bugs by the way) – this is the capacity of the team…
If you can get your teams not to accumulate any technical debt – then yeah that’s better. Chances are your team is hiding it from you and it is there.Personally, I’d much rather have it out in the open
Arnon
Code quality, not product quality. PO may focus on feature quality, UX etc. Team has to maintain “sustainable pace” by constant refactoring and removal of technical debt – they are responsible for this, not you.
They can have it documented and have it visible too, it just doesn’t belong on the product backlog.
Time to maintain quality is “stolen” from PO? You really put this whole Agile thing upside down. It’s about trust, if you don’t trust the team to make engineering decisions and correct their mistakes, then you’re not being Agile. You’re essentially managing a group of developers and telling them what to do.
And this doesn’t imply lack of transparency. A team that tells you in a planing meeting that they can only commit to 50% of their average velocity, because they need to refactor existing code, gives you all the transparency you need.
They key here is that it’s not your call. You’re not their manager and if you’re doing Scrum and have a Scrum Master, he should stop you from denying the team a chance to do their job right.
And it’s not about measuring “stuff”. A team that spends entire sprint fixing bugs and refactoring, delivers nothing in real terms. Their velocity should be presented as zero, so everyone can see the effect of technical debt. If you worry about transparency, it doesn’t get any more transparent than this. Just don’t dress up clean up and bug fixing as real work.
Plotting bug fixing and refactoring effort on your burndown is essentially cheating and hiding the fact that the codebase is falling apart. For the outsiders it will look like your team is productive, but in reality they are delivering fraction of the features they used to.
I found that experienced development teams never hide debt on their own. It’s usually the business that puts pressure on POs and Devs to deliver as fast possible and denies them time required to improve existing code. Very few companies do that, because it requires Agile buy-in across senior management, and that’s hard.
If you think it’s about hiding technical debt, then you misunderstood my criticism.
I agree that the business and PO are the ones that put the pressure on the devs to deliver as fast as possible. But you also need to understand that it is a business decision to ship a product with a known lower quality to get to market faster and fix it up later. A minimum viable product is not just about features.
It is up to the devs to make sure that the business is aware of the quality of the product and that they had to cut corners to make a dead-line. Putting chores in the backlog makes that transparent to everyone. I think maintaing two lists is counter-productive.
Teams want to fix bugs as soon as possible, business can decide to give low priority to some bugs. It is the same for technical debt
Measuring progress of new features is important but measuring capacity is also important you want to understand where your teams are spending their time even if they decide how to allocate it. you can measure these separately but you probably want to understand both.
The PO is not the only one which has input on what to prioritise. e.g. you may need to do some work to support quality attributes which aren’t always easy to express as stories (I actually do try to express these as stories and I have a post or two about it in the blog). Motivation for prioritising technical debt is the team’s responsibility but again, once the consequences are explained it is the business people (PO) that should decide.
Lastly, regarding the tone of your comments – I am happy to have a healthy professional discussion. I respect other people’s experience and you can always learn something when people offer a different perspective on things. Let’s try to keep the discussion at this level and refrain from uninformed “personal” accusations e.g. our “dysfunctional teams” deliver software that is used by 20,000 customers world-wide and generate more than 900 millions in revenues