If you are an ITSM professional, fully conversant in the ITIL vocabulary, you will have no worries understanding the term Problem Management. The term ‘Technical Investment Vehicle’ however may leave you scratching your temple.
Coined by my esteemed Hivemind colleague Mark Dickinson, in his blog on the subject of how to deal with technical debt in our complex, demanding and quick to market organisations whose focus is naturally on the next thing when it may pay to focus on the present.
This is an issue that blights Agile and Waterfall deliveries alike and, regardless of which development technique you employ, invariably it will be your operations team that will be left having to finance the brunt of that debt like the 9999% apr payday loan it equates to.
In order to deal with the fall out of these, maybe at times, necessary short cuts Mark suggests looking at your ‘backlog’ and finding some commonality or pattern in what is proving sub-optimal, and from this building these frequent issues into stories that can be played through the board alongside new requirements. Surrounding these with good customer stories, he continues, can encourage your stakeholders to want to see this work completed and then your route to eradicating or a least keeping on top of technical debt is assured.
Of course, as a dyed in the wool Service Manager, the articulation of the desire to root out technical debt at source is music to my ears, but I know how difficult a sell it can be to turn customer’s heads to the idea of a Technical Investment Vehicle. If winning them over is a ‘closed door’, collaboration and DevOps is the key.
Dev need not invest time into finding out what the tech debt is, where it’s impacting us and who is affected, IT Service Operations is doing this everyday with Incident Management, often at considerable cost. The lynch pin for this situation is Problem Management. PM will seek to understand the impact, urgency and cost of all of these separate incidents then trend and aggregate them into a case for remediation and eradication. Its raison d’etre is to convince stakeholders which bits of technical debt are becoming too costly and which, in the grand scheme of things are ok to sit on for now.
With the rigour and authoritative, evidence based cases brought by Problem Management, Dev has compelling user stories all wrapped up and the sell should be much softer.
All well and good talking about it, and hopefully I have described it simply enough, but how does this work in practice in a DevOps environment. I would suggest 2 things which I have employed to great effect with several teams I’ve coached.
1. Agree a proportion of effort or class of service, between the Dev and Ops teams, for these Problem stories and make the cards conspicuous. In one organisation we agreed 1 in 5 cards played would be a Problem/Tech Debt. The Dev stories were on the usual white cards, somehow we found rainbow coloured cards for the Problem cards, boy, did they stand out.
2. If you have not already, implement the same visual way of working your Dev teams use for your Problem Management team. Get them a board. Tech Debt needs to be conspicuous, everywhere. It represents one of the biggest costs to your IT department and to your business, whatever that might be.
In the organisation where we employed point 1 most effectively a number of very positive things occurred; the Head of IT Ops began to attend all the Dev morning stand ups and Ops team members followed suit as they could see they had a vested interest, a reason and an “in” to those conversations. This germinated a step change in collaborative working; the tech debt reduced, the happiness went up.
In the organisation, a national infrastructure provider based over hundreds of sites throughout the UK, where we employed point 2 most effectively the ensuing transparency around Problem Management brought about a very noticeable cultural shift due to a fortunate set of events. The ITD instigated a series of tours of her estate and upon visiting the IT Operations Centre there were lots of discussions around repeated issues, infrastructure and service constraints and technical debt. Having adopted Kanban a few months earlier the Problem Manager could very quickly describe all the impediments to the work she was undertaking. Having seen the Problem board and attended stand ups every manager within IT Ops was appraised of these problems, how they could/couldn’t help, and how they were being impacted and so the story the group told was with a single voice. The voice was so compelling that the ITD and her assembled team were able to make decisions immediately and long felt issues were dealt with very quickly from that point on. A watershed moment for that organisation. A group ‘elevator pitch’ enabled because everyone concerned in the operation and delivery of IT Service knew what was going on.
With the right approach Problem Management can be a powerful and pivotal process in any DevOps setup.
