[HN Gopher] Planning for Unplanned Work in Linear
___________________________________________________________________
Planning for Unplanned Work in Linear
Author : cristinacordova
Score : 54 points
Date : 2023-11-16 19:58 UTC (1 days ago)
(HTM) web link (linear.app)
(TXT) w3m dump (linear.app)
| yjftsjthsd-h wrote:
| > Unplanned work happens unexpectedly, but it's not unexpected.
| You know that there will be bug reports, you just don't know
| when, where, and in what shape they will come up. The only thing
| that is certain is that they will appear.
|
| 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
|
| And for all that that's exaggerated for humorous effect, I
| actually _have_ played with scheduling blocks of time for
| catching up on Slack messages, which is pretty similar really.
| meheleventyone wrote:
| I work with a team from PT->CET and am in UTC-0 so no joke the
| first thirty minutes to an hour of my day is catching up with
| the rest of what happened the previous day and what's going on
| at the start of the next day. I don't need to schedule it
| because thankfully my morning is usually quiet but it's common
| enough I mention it in my work log.
|
| 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.
| candiddevmike wrote:
| I love multi timezone teams because it forces everyone to
| work asynchronous. I find those environments to be really
| relaxing and flexible.
| meheleventyone wrote:
| To an extent, for me at least I get a great block in the
| morning to early afternoon then a lot of meetings that are
| mostly 1:1s with direct reports and strategy/planning
| clustered around PT morning and my evening. I like that
| though but it's a struggle to not be brain dead especially
| with people freshly awake and full of coffee.
| esafak wrote:
| If your company is sensible. Some mandate "core working
| hours" based on the HQ, and meetings around the clock.
| adastra22 wrote:
| Why is this exaggerated or humorous? That's literally what I
| do. Works great.
| veidr wrote:
| Same here. And I put in my calendar to make it obvious to
| others that it's there. I used to put in in the issue-
| tracker, too, but lately our team manager started reducing
| the "normal" expected story points to a level that reflects
| the time left in the iteration after the average amount of
| "unplanned" work is considered, which also works.
| yjftsjthsd-h wrote:
| I guess the joke is that I would have liked to imagine that I
| didn't have an emergency a day like clockwork. Let me keep my
| fantasies;)
| cratermoon wrote:
| 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.
| lizard wrote:
| > 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.
|
| 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.
| dboreham wrote:
| Usually it's the largest ball of twine.
| lizard wrote:
| You can see the Largest Ball of Twine from the road, so you
| never get to actually stretch your legs, which was the
| whole point, and your detour ends up being a waste of time
| that contributes nothing to the endeavor.
|
| 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.
| alkonaut wrote:
| > 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.
|
| 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.
| cratermoon wrote:
| > 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.
|
| This pressure is inexorable. With the wrong incentives,
| anything that falls under OpEx will be discouraged.
| asicsarecool wrote:
| Has anyone here used Linear? Looks interesting
| lijok wrote:
| Been using it at work for a bit over a year now. It's great,
| very lean, snappy. They're deliverying features at crazy speed
| too. A breath of fresh air after having had to use Jira for way
| too long. Can highly recommend.
| Minor49er wrote:
| I've been using it at my job for about a year now. It's pretty
| decent. Their support team is also highly active on Slack, so
| if you run into any trouble, they will help you resolve it
| right away
| lmm wrote:
| I use it. It's ok. Slick, simple, gets the job done.
| aniforprez wrote:
| After wading through the molasses that is Jira, Linear is very
| good. Very fast and snappy though not as extensible and
| configurable as Jira of course
| aerhardt wrote:
| Started using it a few months ago. It's a normal issue tracker
| feature-wise. Doesn't seem to reinvent the wheel, functionally.
| Where it shines is in UX: crazy fast and snappy, great layouts,
| keyboard shortcuts, look and feel, etc. I'm at a point where I
| go "ugh" if I have to use anything else.
| cornel_io wrote:
| Yes - I don't hate it.
|
| ...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.
| superice wrote:
| Yep, using it for my small software company. We used Jira
| before, and while we had a halfway decent config so it didn't
| suck too badly, Linear is just light years ahead in terms of
| usability. I take a lot of inspiration from how they approach
| software.
|
| 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.
| bbatha wrote:
| Been a customer for 3 years. Easily the best ticketing software
| I've used, particularly day to day as an engineer. As a manager
| I found it lacking some higher level planning tools, but
| they've been putting a lot of effort in. As a sibling said
| usually the defaults are sensible. I could in theory do more
| things with JIRA, but that assumes my org configured my
| instance in a way I like, I can find the customization, or not
| get entirely turned off by waiting for page loads.
|
| 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.
| esafak wrote:
| How does it compare with Height or Shortcut?
| dmos62 wrote:
| Put whatever unexpected work comes up into a general inbox
| somewhere, without preprocessing it (i.e. without figuring the
| next steps). Then periodically process what's in the inbox
| (figuring out the next steps and scheduling them), once a day,
| once a week, whatever. Also, buffer for unexpected stuff in your
| deadlines, in my work it's generally 40%.
| adastra22 wrote:
| Sounds like the GTD approach. Works well for me too!
| jjk166 wrote:
| Absolutely nothing in this actually covered how to plan for
| unplanned work. While yes becoming aware of issues quicker and
| preventing things from falling through the cracks is great and
| all, it's still strictly post hoc. "Dealing with unplanned work"
| would be a better title.
| esafak wrote:
| They had to call it an "Ask" :(
___________________________________________________________________
(page generated 2023-11-17 23:02 UTC)