0 comments
Various 
At QCon I learned that, surprise surprise, other projects team have to deal with technical debt as well.
Or maybe the team’s performance is down for some other reason, either technical or some obstacle in your process (I won’t go into explaining the monkeys or little ninja’s that get in your teams way, but, I you wanna learn more about them check out some of the video’s on the QCon or InfoQ website when they get online, there are some good stories there…).
When teams experience technical debt (or ninja’s…), it actually slows down their performance. Or in other terms, the team faces some form of ‘latency’. In this context latency is measured as days between a feature request and the actual delivery of this feature into production.
And latency, as we all know, is annoying for our experience, and has to be eliminated.
So far, nothing new for most developers I guess, right?
But, when we look at latency in this context, merely saying it’s annoying is actually a huge mistake! Because when it’s annoying, most people will just ignore it, and decision makers will definitely not invest in fixing it, they have features to get done!
One important thing to realise is, if you can reduce your team’s latency, it’s kind of like compound interest; every fix on your teams performance will come on top of the previous one, and after some time of making improvements the total sum will be way more then just adding up the individual fixes.
Interesting mathematics for sure, but the hard part of reducing your team’s latency for many teams is to get approval for your team to do so…
And asking your manager for some valuable sprint-time to work on technical debt, yeah well, good luck with that!
So, don’t talk about it!
And of course, their most probable solution for you to ‘just working harder’ might be fine for a day or two, but since most latencies tend to be structural issues that’s not really a solution in the long run.
So, turn this thing around, and envision the goal you want to achieve; releasing features more quickly.Now that’s something you, your team and your manager can relate too.
When your manager is not on board (yet), somehow find just a little time to make some small improvements ‘for free’, and show what a little effort can give in return.
When your managers gets to see your performance is actually improving by these efforts, try to get some percentage of your teams time, for each sprint, to allocate on reducing latency.
And with the previously mentioned compound interest, you should see a serious reduction in latency. This will make you and your team feel empowered to improve your own process, and make your manager (and theirs) happy for getting features out quicker.
More on QCon in the next blog!