… something on Tech Day
As alluded to in my blog on Sprint Calendars, you will have seen the Monday at the start of a Sprint was labled as ‘Tech Day’.
I introduced Tech Day to give explicit permission to the team to tackle tasks that might feel hard to justify to take on in the course of a sprint, but are likely to prove beneficial to that work — Sharpening the Saw as Stephen Covey puts it in the 7 Habits of Highly Effective People.
This of course includes paying down what Allan Kelly describes as ‘Technical Liability’, as this conveys the concept of it being a bad thing, whereas with it’s normal name of Technical Debt can sound like too much of a good thing to a business or finance person, where debt is seen as an essential tool to be leveraged to the max.
Tasks that might be identified for Tech Day might be working on some testing infrastructure, or a required change in architecture, setting up a multi-threading framework, etc.
So it could be that a task started on Tech Day wouldn’t fit into that day; and this has certainly happened but I have been pretty relaxed that it is better to see (important) tasks through straight away rather than parking it to the next Tech Day — always consider your Work In Progress.
Of course, if some work has been identified for Tech Day but then becomes necessary for Sprint Work, it should be taken on as part of the Sprint, not held back for a Tech Day as this would hold up work identified to be on the Critical Path.
Making Work Visible
Dominica Degrandis (@dominicad on twitter) identifies four types of work in Making Work Visible. Neglecting any of the four types brings problems eventually. Work to address Features and Bugs are easy to be accepted in to a Sprint, but it’s ensuring that time is spent addressing the other two where the challenge comes. Having a regular Tech Day is one way to ensure time is spent on these tasks as well.
The Flip Side
There are a couple of ways in which the are dangers to having an explicit Tech Day.
If there is some Tech Day like work that is on the critical path of the sprint then it should be taken on as part of the main sprint work, not artificially held back to the next Tech Day.
One thing that I have been concerned about is that work that should really be done as part of the main sprint work is deferred to a Tech Day.
Secondly, there is a danger that the Tech Day becomes the ceiling to the amount of this sort of work, holding it back.
Conclusions
I have found a Tech Day to be a useful statement of intent to teams that we (need to) care about the health of the codebase.
It’s not the answer to all ills, if the Technical Liabilities are overwhelming, a day every two weeks won’t solve the problems. But it’s a starting point, and more time can be devoted on an ad-hoc basis.
What it does do is make sure regular time to ensuring issues in the codebase are addressed — and all four types of work.
