Planning for Unplanned Work in Linear(linear.app) |
Planning for Unplanned Work in Linear(linear.app) |
I am tempted, half tongue-in-cheek, to suggest simply scheduling it:
09:00-09:30 get coffee and morning standup
09:30-11:30 work on project A
11:30-12:30 lunch
12:30-14:00 deal with the emergency of the day
14:00-17:00 work on project B
I don’t think this is unplanned work so much as unrecognised work. Few Gantt charts etc. keep track of that overhead like the overhead from ‘surprise’ tasks.
As someone in Europe where lunch break doesn’t count as working time, this would amount to 7 work hours. Here the norm is 8 hours.
Does lunch break in the USA counts as working, or you typically work 7 hour days?
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.
Same experience where I work. Not perhaps "directly fed" to the accounting, but something similar. Basically: someone somewhere needs to know how many hours were CapEx and how many were OpEx. The division between planned work and unplanned work is a crude way of doing that. It's not perfect, but I do prefer that division over having to report hour by hour whether I did cap/op-ex work. The only problem I see with it is if this creates pressure on either a) creatively marking work as one type or the other or b) prioritizing incorrectly due to on this. Those are real problems (luckily I have not seen that where I work). But the division itself seems like as good a method as any.
This pressure is inexorable. With the wrong incentives, anything that falls under OpEx will be discouraged.
...which is literally the highest praise I have ever given and probably ever will to issue-management software. They correctly realize that we mainly want to not notice the software, which is something that every competitor gets wrong.
What I can't figure out is how they possibly got funding in the reddest of red oceans with a pitch that couldn't have been much more than "we'll make Jira but not suck" (that's essentially all it is), but I'm glad they did.
My biggest complaint is that they don't believe in email notifications. They have a very basic "catch up digest" but it comes in very slow and doesn't appear at all of you happen to look at Linear at the wrong time (because you are "active" and so clearly don't want a notification). So it is easy to miss stuff unless you are constantly checking their inbox.
It also has a bit too much structure with projects/tasks/subtasks which I find is less useful then just dependencies as you often want to break up a subtask but it doesn't really support that. But it does have raw dependencies so you can just use those even if they are quite basic.
But overall it is fine. Which is also the best thing I've ever said about an issue manager.
There are some drawbacks. Linear is highly opinionated about some stuff. I happen to think most of their opinions are sensible, so that doesn't bother me, but it's explicitly not a general purpose replacement for Jira.
I'm pretty impressed with their new developments. This article shows they are thinking about issue tracking from first principles, which is helpful. This triage thing is definitely something we've been struggling with, and something that most other issue trackers do not deal with well at all. We've been a customer for about a year now, and we're constantly seeing steady improvements. Recently upgraded to the top tier package, and I had a minor scare because I did not realize it was going to be billed annually (it mentioned a monthly price with 'billed annually' under it but my brain wasn't braining very well when I clicked upgrade), so I sent an e-mail asking about it, and they got back to me quickly, with a proper in-depth, human sounding response. I just love being in contact with an actual human, and not feeling like a number in an arbitrary system, even though given their scale I must be.
So two thumbs up from me.
They have been incredibly focused on improving the product in ways that are visible and get uptake from me immediately. Its one of the few pieces of software where I want to read the release notes everytime.
If I worked at a shop with less than 200 employees, its the no brainer choice.
That seems familiar enough I feel like it might also be a great analogy for something, but now I'm sore, disappointed, and behind schedule, so I'm just going to drop it and bunker down to finish this as quickly as possible.