Once a month I feel like a rich man. On the day I get paid,
my bank balance shows the fruits of my efforts in all their glory. This lasts a
day or 2 until some bugger comes and swipes the lot!
In reality, I am actually poor. Like most people I have a
huge debt in the mortgage on the house that keeps me warm and dry. This is a
well-managed debt, lasting years that I nibble away at each month.
If I were to treat my finances like a
business on an extensive balance sheet then I would make my true financial
situation visible. It would make me sad obviously, but if I want to know my
true position then this is what I should do.
A POs responsibility does not lie solely in serving the
customer. They must also align the customer’s requirements with their company’s
vision. These are 2 perspectives but the developers give you a 3rd
which is equally important – they can tell you about all the things you CANNOT
see and yet still affect your product.
Many POs I have worked with insist that the backlog should
not have any stories that describe technical debt since they have no value. I
would ask you to consider that the backlog is better seen as a balance sheet –
it forecasts the future worth of your product.
So if we treat the backlog as a balance sheet, we can start
to attribute the losses of not addressing technical debt against the gains of
new features. It is actually the combination of these that describe the true
position of your product and its ability to continue making you money.
Our technical debts are ever increasing – this is either an
active process which we decide on or a passive process through neglect. Just like a mortgage, there is maximum we can
afford based on our resources – we cannot keep increasing our mortgage forever.
If we don’t carefully managing our debt we might have to
take out a more expensive loan to cover the costs over a shorter term. At
worst, this could be one of those payday loans because we exhausted our credit
with all other lenders who rely on us being sensible in order to do business
with us.
Technical debt provides balance to your backlog. Viewing
your debt alongside your credit allows you to make more informed decisions
about what to invest in and when.
3 comments:
It's always frustrated me when addressing technical debt is not seen as delivering any value. It may not be delivering new features, but if it might take 4 sprints to deliver something new whilst hacking around the debt, or 2 sprints if the first sprint addresses the debt, the choice is obvious!
I think if developers want technical debt tasks on the backlog, they need to convey the value to the PO in terms they understand. Don't intimidate them with technical goobledygook, find the genuine value. If there isn't any value, then you shouldn't be doing it...
I would like to find a way to be able to show the real value and credit of resolving any technical dept to the customers.
If resolving a technical dept will not add value to the business, what is the point of resolving it.
If we could achieve presenting the value of resolving an issue, gaining a credit is already guaranteed and it is no longer a problem adding them to the backlog!
Indeed this is the challenge. From a developers stand point the benefits of resolving technical debt can be more intangible. It is the long term accumulation that is more damaging - as per the analogy, we want to deal with debt as we go by acknowledging it. The longevity of the product is a concern for the company who owns it, this might not align directly with the short term needs of the customer. It is the blend of perspectives that allows us to make the best decisions. One source of information that is often neglected is the source control system history - areas of our products that change frequently might be treated differently than those which rarely change.
Post a Comment