Last week I talked about refactoring and the need—throughout that process—to still be able to deploy frequently. What I did not explain was why it was important to still be able to deploy frequently, and that was a bit of an omission, because we shouldn’t take these kinds of mantras lightly.
The reason is to avoid what I call a hostage situation, which is what happens when you combine the lack of walkawayability with someone to blame. Just like any non-trivial piece of work, refactorings, and similar deeply technical reworkings, can take longer than expected. Additionally, the external context may change, meaning that (for example) we are suddenly presented with a much more urgent demand before the refactoring is complete.
Walkawayability is how ready we are to stop the current work prematurely without having wasted the effort so far. If we are prevented from walking away because we’re in the middle of a major piece of technical work which non-technical stakeholders barely understand then an unfortunate but easy conclusion is that the development team is to blame. It looks like the development team is holding the organisation hostage: “No we can’t stop now, we’ll have wasted all the time and money we’ve spent on it so far. We have to press on.”
I’ve been in situations where the original delivery date is reached but the work is still not finished. Feeling they don’t have much choice, the management team reluctantly agrees to continue the work to the next forecast delivery date. When it’s not done by that date, either, things get pretty unpleasant.
Frequent deployment is considered good practice these days. But we should never accept these things without reminding ourselves why they are important. In this case it’s about ensuring we can continue to respond to changing circumstances. With refactoring and similar it’s especially important for the development team not be seen as standing in the way of this, but rather enabling flexibility and responsiveness.
niksilver.com 