Technical Debt! Managing it on an Agile Project
"Story work takes precedence over all other work.", "We'll do what technical debt we can if we have time.", "You can't boil the ocean."
I suspect most, if not all software practitioners have heard or said sayings like those above, or something along these lines, yet most projects aren't aware of what they are giving up by not properly prioritizing technical debt. I was on one project many years ago, back in the pre-DevOps days when almost 0 attention was given to such work, velocity suffered, the team grew to over 50 and they slowly became less and less effective at their job. There's no doubt that if management knew that this was caused by their inattention to technical debt, they would have paid more attention to it, but it seems they didn't know to ask. With the introduction of DevOps years ago, the problem has been helped to a large extent, but there is still a lot of room for improvement. If there were no DevOps today, would your agile team naturally devise such a role to keep your team effective? I suspect not, and this suggests a gap in how we manage projects today.
Outline/structure of the Session
- Interact with attendees to discover their definition of technical debt (give examples and ask if they would classify as tech debt, ask if they feel it's avoidable, ask for work items that are not story work/bugs/improvements of direct, visible value to the business that they would not classify as technical debt)
- Review original and subsequent definitions of Technical Debt and make a clear case for a broadening of the term.
- Outline different approaches to identifying technical debt, and encouraging it to be procured from developers, and how it should be procured. Highlight importance of a good 'Definition of Done' in this process.
- Outline different approaches to managing technical debt (ie. in-context for work < 2 hours, as work items for those >= 2 hours)
- Show what a dashboard could look like to help managers better understand the impact of not choosing to do particular technical debt so they can be fully informed when they consciously choose not to do it.
My goal is to attain the following:
- Attendees come out convinced that a broadening of the term 'Technical Debt' to include all debt of a technical nature is appropriate.
- Attendees that believe Technical Debt is avoidable, will be convinced that it is not.
- Managers will hopefully feel more empowered to deal with it and Developers will feel more empowered to surface such things. I hope for this to bring both roles closer together on their perspective of the matter and a better, mutual understanding if/when choosing not to address technical debt.
Developers, Managers, Other Software Practitioners