I had a great time at the Mile High Agile 2012 conference. I thoroughly enjoyed and learned from every talk and heard almost 100% positive reviews of all the talks I missed out on in the other tracks. Many thanks to all who were involved in making it happen. I’ll definitely be back next year.
I want to write about one experience that really fired me up and kept me thinking for several hours afterwards. During one of the talks, the speaker gave us 3 minutes to talk amongst ourselves about how we might try to get rid of technical debt within the confines of an organization that doesn’t think it has time for any development work that doesn’t either add a visible feature or eliminate a visible defect.
At our table of about 8 people, 2 people seemed to think they each had a new way to magically sell management* on the importance and urgency of removing technical debt. They spent most of the 3 minutes talking about these magical methods.
I couldn’t help noticing several implications:
- Management doesn’t understand technical debt (but we can explain it to them if we talk very slowly and explain it just right).
- Developers aren’t allowed to remove technical debt (read: do their job) without permission from management (the people who still don’t understand technical debt).
- Any blame for the technical debt lies with management, not the developers who created it and are too scared to fix it.
- This situation will somehow improve someday if developers just keep what they’re doing.
- Nobody is sticking up for development in these organizations in the way I would expect a Scrummaster or a lead developer to.
With about 20 seconds left I finally vented through my mouth just enough to keep my head from exploding. The words that came out expressed that I wouldn’t waste my time asking for permission and would instead just do it, and maybe tout it after the fact as a good thing for the company, or not. I was swiftly shot down with “that’s really dangerous” from multiple people at the table and then time was up. Each table got one spokesperson to express the gist of their discussion and it wasn’t me. What a letdown!
This interaction stuck with me the rest of the day. I know my projects would have a ton of technical debt if I had to beg for permission to fix it or, worse, waste mental energy trying to think of clever new ways to beg for that permission because all previous attempts had failed.
I couldn’t help wondering what life would be like if I had to ask for permission to do other essential parts of my job. What if I had to ask management if I could use source control? Install a new editor? Test first? And should I expect management to pat me on the back if I do?
To be fair, getting rid of technical debt is always a judgment call. There are plenty of situations where it makes sense to leave it in. Many developers are overzealous in this department, just as non-technical management is traditionally underzealous.
In my opinion the decision of when to tackle technical debt should always be made on the development side. The extra upfront cost of doing so should already be reflected in the team’s velocity. This helps the team’s velocity stay fairly constant instead of dropping off exponentially due to excessive technical debt.
*In the context of our discussion, “management” seemed to refer to one or more non-technical persons “above” the developers in their organization who determine what visible features developers work on and when. I’ll use the term in the same way here.