|
|
|
|
|
|
by cratermoon
953 days ago
|
|
|
I kind of like the article take on how to handle emergent issues, but I don't like that it still sort of silos software development into two parts -- planned and unplanned. I hate the term "unplanned" to describe this kind of work. By using a very narrow definition of "plan", for work "organized and scheduled in advance" but only within projects and roadmaps, it sort of works. A more informal usage of unplanned, though, suggests a kind of blindness to the reality of software development and maintenance. The reality is that the effort in software development isn't easily divided into these streams. The article fails to address an important consequence of putting effort into fighting fires: the project plans and roadmaps of the affected teams will be disrupted. This is where the term "unplanned" really fails, because if the organization never takes into account the effort taken to address issues and emergencies, the plans are worse than having no plan at all. On a different note, one place I consulted with had its planning and tracking tool (Jira-like Azure DevOps) directly feed into its accounting system, such that different types of work were bucketed into different amortization flows. Planned work was a capital expenditure (CapEx), while anything funneled into Unplanned became an operating expenditure (OpEx). Any accountant that knows the implications of CapEx vs. OpEx can see where this is going. This company had a lot of bugs and issues that were left unaddressed. |
|
|
The article likely glosses over these particular details because it's a sales pitch for an app that offers a, seemingly, smooth flow to get "unplanned" work into the "plan." The "plan" just being the ticketing system where work-to-be-performed is assigned, not the roadmap.
You're not wrong that "unplanned work", of any form, can disrupt your timelines. And that why the features they are describing, that are separate from the assigned work, are important. They require someone to explicitly acknowledge and accept the costs of that work before adding it to the "plan."
That said, your roadmap, like it's analogous counterpart, generally won't be that specific. It's just there to layout the direction and highlight important landmarks. You don't use the roadmap to draw every gas stop or who is driving each stretch of road on the road map because it's hard to anticipate those details and expensive to update when things go awry. And even if you try, sometimes you just want to take a detour and see the Largest Ball of Yarn because you need to stretch your legs and it's only a few miles out of the way. Your roadmap shouldn't care about any of that, it's just there to help you get back on track when you're done.
But once you get to the car, you make a plan. You decide who is going to drive first and how far you expect to go. And you can change that plan when the fuel tank doesn't get you as far as you thought, or a poor night's sleep catches up with you sooner than expected, or there's a rock shop on the side of the road, because you can ask the other people in the car whether its worth arriving a little later to look at some cool rocks.