Once in a while, a project ends up completely off-course. We end up having to fix something that was never part of the original plan, something that appears entirely unrelated to the actual problem we're attempting to solution: I often have in mind that one opening to some episode of Malcolm In the Middle where the dad meant to change the kitchen's light bulb before going to work and ends up spending the entire day unravelling the thread of intermediary tasks that sneak themselves in the way of his seemingly innocuous goal.
Somewhere along the line, we're 3 month in that 2-week project, everybody's getting fed up, and the deadline comes looming: we decide to implement only the half that's immediately doable, preserve the work-in-progress somewhere in our VCS of choice (Git, surely), close the remaining tasks as "won't fix" or discard (erm, "retroactively postpone", I mean) them to the infamous backlog, under the "technical debt" label.
We thought we'd be on top of things and could be surfing the wave of due features but ended up submerged under a rip tide of unknown unknowns violently revealing themselves; nobody's happy and we shipped a half-baked product that we now tell the stakeholders was a perpetual stew all along.
At that story's post-mortem retrospective (you do these, right?), we conclude that the failure to keep up with prerequisites discovered as we went lies mostly on:
- the staggering cost of unplanned cross-team collaboration, and
- the lack of a clear, shared vision of what "done" means, possibly aggravated by some well-intended scope creep.
In the alternate reality where we'd have aptly assumed the responsibility of laying out the foundations for successful project, we have spent some time upfront to ensure we'd build the right thing at the right time—when all the resources (human and other) would be suitably available and primed, then spent 2 more weeks actually taking on the 2-week job.
Of course, this only works if we indeed start ahead of time, otherwise this planning not only is directly delaying the project and eating into its allotted time and resources, but also is doomed to be biased towards expediency as we're basically discovering when would be the right time to begin the activity we're currently supposedly working on.
Considering the upstream preparations, it'll have taken somewhat more than the estimate, but still went smoothly. Without juxtaposing it to how poorly it could have gone, it's nothing to write home about... So I shall write about it here.
If you find yourself in an environment routinely bearing with projects being unceremoniously started and just as organically derailed, in-house products that have aged into a mere maintenance burden, or teams that are perpetually putting out fires, you may want to consider shifting your perspective:
One simple job scheduled, discussed, planned and delivered on time is a success story.
If a team consistently handles these straightforward tasks in that manner, don't make the mistake of assuming they look good because their tasks are easy: their tasks are easy because they are that good. They're giving you the value they sold you on; in many contexts in the software industry, that is quite a great value.
Celebrate, encourage, analyse and emulate these blueprints for success: this is where you can most reliably ensure your department will be more reminiscent of an icebreaker steadily and reliably ploughing its way through the Arctic, rather than a leaky oil tanker spilling its noxious entrails as it drifts helplessly in the open sea.