I mean, first we really need to align on which Jira components to add to that ticket of yours, because we use them to reflect the products that benefit from the change and you should get in touch with the Automated Horse Warehousing PO whether changing the hue on the "Apply Now" button on the About Us page impacts their Siemens automation codebase. Also, you didn't fill out the seven big free text fields with the proper info in the proper format, and while I understand you physically can't know half of this before making the change, you must or the ticket can't advance from "Backlog" to "Under Consideration for To-Do" in our pre-grooming meeting on Thursday. Oh and I think the update comment you wrote under BLLSHT-173 got auto-deleted because you didn't follow our Task Update Formatting Guidelines, could you reformat and post again?

I see you worked for both of the past two companies I worked for as well.

Emphatically yes, there's some really broken process out there.

I sat on a team with 6+ hours per week of full-team, in a room, jira ticket creation/reviewing/sizing/prioritizing. So thats 15% overhead right off the top.

This of course was not the only time we spent interacting with tickets, as we then had daily standup, random "check-ins" from product/management on ticket status, and of course actually picking, updating, and closing our own tickets throughout the sprint.

Easily spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it.

I understand developers’ complaints about this sort of thing and I am as much of a Jira-burnout victim as the next coder.

But.

How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one?

15% honestly doesn’t sound like a number I would automatically assume is ‘too much’ for such activity. I’m not sure even 30% sounds like a crazy high number. Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity.

It doesn’t have to be Jira backlog grooming, sure. But it has to happen.

If the developers aren’t spending their time doing this, who is?

> Figuring out if the plan is still the right one?

15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway

> Putting the whole team in a room every week is just going to churn the plan constantly

Yes, that's the point, that after each week (or two) of work, we've learned more and the plan already is outdated and needs to change.

> inputs likely aren't changing with that frequency

In my experience, they absolutely are unless you're building the simplest CRUD app that's identical to one you've built before. The inputs are less often changes from external stakeholders, and more often tasks that are turning out to be more difficult than hoped.

> and you aren't going to be able to pull in all the other stakeholders that often anyway

Of course you are. It's the PM's job to gather the new inputs, go check in with relevant stakeholders (takes a day or two at most), update or re-confirm their priorities, and then make the updated decisions for the next sprint.

In my experience, 15% of time spent each week on planning is about right. It doesn't maximize the productivity of each person coding, but it hugely maximizes the productivity of the whole team in delivering a valuable end result.

My experience with weekly ticket grooming is that most of the time we spent 1-2 hours talking about the exact same tickets we talked about last week and left everything in the exact same order as it was when we started. When working on quarter+ long projects there just wasn't anything that changed week-to-week, and when things did change the actual planning to adapt to that was done immediately, not in the weekly meetings.

What was great with my ticket grooming bi-weeklies was that despite having 20 engineers in a room, we were strongly admonished from going into technical details of implementation in the room. "Take those offline. But please put a size on the ticket, thank you."

What else do you want us to do for 4-6 hours/week? Write poetry?

Eventually every ticket just gets sized "medium-big", and people keep their heads down with mouths closed.

So, in my example, we were having 2-3x/week 2-hour, full dev staff meetings.. without product in the room. He was a very busy man and could only grace us with his presence for 30 min every 2 weeks to basically sort the tickets we had spent 12 hours putting together and decide which he actually cared about.

Much could be accomplished more efficiently by getting product, management, and 1-2 seniors in a room for 30min to actually decide what/if plans have changed & cascade the changes accordingly.

99 times out of 100, the plan didn't change because something raised from the bottom, but because management has changed direction or users have asked for something new. Why subject 95% of the team to hour long monologues?

I don't think that's the case for most of the substantial software projects. The plan for the Linux kernel doesn't change each week (do they have "PMs"?).

15% seems very excessive. Almost a whole day a week and two days lost of deep work. Try to aim for 1.5%. Do as much of the planning as possible without a meeting.

1.5% of a workweek is 36 minutes.

I don’t know how you can get a team of developers to productively spend 39 hours and 24 minutes of keyboard time productively coding in the same direction with only 36 minutes of discussion.

That works great in FAANG companies, you might have 1-3 hours of meetings in total a week. That is how your typical PhD program works too, meet with your supervisor once a week. And low meeting culture seems to work just fine for the Linux kernel developers too. You're always free to engage in extracurricular activities, but it's not mandatory.

It's the lesser tier, often non-tech companies doing this kind of micromanagement.

Exactly. A real product driven company with a mature product isn't interacting with customers frequently enough to upend their plans every 1-2 weeks.

How do people think Apple develops completely new product lines like the iPhone, iPad, watch, etc.

There's a lot more up front planning (and yes .. of course, course corrections) than a lot of agile advocates want to admit.

Most agile hyped up senior management I've met just use it as an excuse to be derelict in their ability to plan anything.

> isn't interacting with customers frequently enough to upend their plans every 1-2 weeks.

As I said, re-planning is more often than not needed because of technical challenges developers are running into. If one person is going to take 4 weeks to deliver something instead of the expected 2 days, lots of things may have to be rejiggered.

But also, yes even "real product driven company with a mature products" are changing plans every 1-2 weeks. Because each new incremental feature is a little project of its own. I never said plans get "upended" but they absolutely need to get re-adjusted ever 1-2 weeks based on both dev input and product/user reaction.

If you want to talk about the iPhone, just look up the history of how the software keyboard was developed. Talk about rapid prototyping and upending plans!

The good software companies do these projects in the 3-6 month length instead of 1-2 weeks.

No they don't.

They absolutely plan where they want to be in 3-6 months -- they're generally quarterly OKR's -- but the only way they consistently achieve their targets is with weekly or biweekly readjustments.

They do, and if you need to adjust a project you don't need 10 hours of weekly planning meetings (the Linux kernel developers don't need it, so your CRUD app developers don't either).

The higher you go, the less agile it gets, because that's a horrible way to develop software, or any high-skill professional service or product.

Sorry, are you suggesting a better way to operate is to have the team go off for like a five week offsite to come up with a plan for the rest of the year? Then once a month, they get a day to figure out if the plan’s still working?

It’s an option, I guess… let us know how it works out for you.

That's a horrible idea for sure, but I'm not sure the current model being derided works for all team compositions either.

In a 20+ person dev team with a lot of juniors, the team is not "coming up with a plan" or "deciding if its still working" so much as product/tech lead/a couple seniors who have zones of responsibility are handing one down. The two hours spent in the room is agile kayfabe.

"Get everyone in a room and hash it out for 2 hours" is maybe a model that works at team size of 5, senior, empowered engineers, but it is not something that works at large scales.

I mean... yeah. That's kind of how a lot of big enterprise projects with VP-level visibility get managed (I participated in versions of this at both Amazon and Facebook)

Obviously you don't need to pull all the junior eng offsite for a whole month, but the engineering leads + PMs + engineering management end up there. And obviously there's also ongoing prioritisation happening between leads/PM/management throughout the year - but that doesn't require pulling the whole team every week.

Yeah, I think this level of planning has gotten lost in our recent fad of agileness.

Senior management thinks they know where they want to be in 3 years, but there is no cascading multi-quarter, let alone multi-year planning of the projects & steps to get there.

I've even been in orgs where someone senior is trying to make very very large org & tech changes, and really can't be bothered to put the big building block steps to get from here to there. As it turns out, they never get "there".

Somehow they know enough to bring in project managers for big concrete things like "retire a datacenter" and go all out with MS Project, GANTT, etc.

However when it comes to software changes like "split an on-prem Java monolith into a fleet of python micro services in the cloud" ... it's all iterative vibes the whole way.

Agileness is many things but I really think we can stop thinking of it as a ‘recent fad’ by now. The manifesto was written 22 years ago. It’s been the dominant mode of engineering organization for over a decade.

> Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity.

The promise of "agile" is, IIRC, faster turnaround and iterative development. Yes, the 'wrong' thing is expensive. Getting something basic in someone's hands in 2-3 days to get some feedback is usually more productive than days of figma then 'sign off' then work work work then putting it in hands and getting back "this is wrong" (missing data, etc). Sometimes those things can be found in 'design-only' sessions, but I've rarely seen it happen where lots is found there, then things are implemented perfectly afterwards not requiring any further changes.

Much depends on the size/scope of the work, and I don't think there's one-size that fits all, but the ticketization of work process as teams grow pushes towards "one true way", which then seems to paper over a lot of cracks that don't easily show up in burndown charts.

That 15 or 30% might be the time ultimately taken on thinking/planning/etc of a specific issue, but too often it seems there's an idea of doing more up front "gets it done" and the notion of fast feedback/iteration cycles is glossed over, and you're expected to "get it done" - "all the planning was already done".

When doing dev-type work, I always end up needing to iterate with endusers/stakeholders, and there's little 'up front' that could have been planned to avoid some of that. It may be the nature of the people/teams I've worked with, though.

Yeah and the larger issue - putting 20 people in a room for 2 hours violates like every single management / efficiency / socio-political recommendation in the book.

The more people in the room, the fewer participate, the fewer decisions get made, the more gets punted to the next time 20 people are in the room again in 3 days.

> The promise of "agile" is, IIRC, faster turnaround and iterative development.

The promise of agile is working software.

Iterative development is a how, not a what.

arguably the goal of any software project is... working software, no?

i understand your point, but also think 'agile' is at least as much of a 'how' as much as a 'what', especially over the last 5 years or so.

"agile" itself would seem to be a 'how'. "agile software development" as a phrase is describing - at least too many folks - 'how' the software development will be carried out.

but... it's also a massive amount of hair splitting it seems.

People should absolutely be planning their work. Measure twice, cut once. But then again, isn't agile supposed to be iterative? Measure, cut, measure, cut, measure, cut.. repeat?

How much value do you get from putting 20 engineers in a conference room for 2 hours, 2-3 times per week? What if this is mostly just a head strong manager who enjoy monologuing his captive audience team?

Note I said "spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it" This doesn't really help prevent building things that don't fit together at all. It barely allows you to surface technical dependencies and order of operations.

> How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one?

Keep in mind that in most "jira-oriented" places (or probably all of them), that task isn't attributed to developers at all.

If you are doing this and development, like a healthy place, yes, 30% of the time evaluating your work sounds sane. But that evaluation time must not be interleaved with development time at all. Any interleaving will destroy the value of both tasks.

Stipulated: many companies suck at engineering management.

But in companies that are good at engineering management, you will often find:

- weekly planning sessions

- daily standups

- work ticketing and backlog systems (sometimes Atlassian ones!)

- prioritization discussions

So I would suggest that anyone who assumes that those activities correlate with bad engineering management, is falling into a base rate fallacy.

P(is badly managed | Jira) is high, but that’s because P(is badly managed | tech company) is high.

> Oh, I see... I just assumed people read tickets and did the work and updated the ticket?

There are a LOT of Professional Scrum Masters and Product Managers who want to constantly review the state of tickets, make update/status comments and communicate simple questions and answers via the ticket system.

Did you mean 'x'? Yes, I meant 'x'.

Our slack bot channel exploded when we hired a new Product Manager who communicated strictly via ticket updates, literally dozens of alerts per day. They got upset when they found out every single developer had unsubscribed from all the ticket channels because of the noise.

Make everything, even a 1 min fix a ticket and insist it's under right category and right project, the time is accounted for, and each developer have to report 8h time worked a day and you can have plenty of time wasted on ticketing

If you're making a change without saying what it is or how to test it, and not writing an automated test to cover it then that would be a problem. It might be 1 minute in code, but that doesn't mean it's a 1 minute fix.

It depends. Maybe the 1 min fix is to add a missing test case for something that already works. Spending 20 mins creating a templated Jira for that is a waste of time imho, but it depends on what you do. In some places that have externally audited traceability requirements that would be necessary.

Yes, I agree with that. I'd say that changes to the running codebase would need (slightly) more formality than changes to the test codebase, but yes, if tests are a feature e.g. because they feed into regulatory output, then they should also be ticketed.

I don't find that a Jira ticket takes more than 2 minutes to write though, so maybe there's a difference in terms of number of mandatory fields.

2 minutes? That's barely enough time to load the Jira ticket creation page...

Hah! Hit create and the popup opens. Unless you have a load of plugins installed, in which case tell your IT department off.

The commit or comment is enough for that.

There are definitely corporate cultures where updating ticket status at regular intervals is higher priority than actually working the problem in the ticket.

Of course it is. That means that you work on the problem, but when a regular interval arrives, you stop working on the problem to update the ticket instead. Once updated, you go back to working on the problem. That's how status updates are supposed to work.

Inverting the priority would mean that you never update tickets until you're done fixing the problem. That might be possible in small organisations or for small problems. Everywhere else, it's necessary to provide updates from time to time before the problem is solved.

If you want daily updates on normal tasks, you're just wasting a bunch of people's time. Under ordinary circumstances, that stuff cannot possibly be actionable, and tracking data that's not actionable is just wankery. I don't mean keeping people directly working on the tasks in-the-loop with one another and surfacing blockers, which shouldn't need formal process beyond at most a five-minute daily standup, I mean up-the-chain status updates. Wanting to watch the little Jiras move through the flow chart on a daily basis is just PMs and managers wishing they were playing Starcraft or something instead of doing work.

Given that, if your tasks are taking long enough that any but very-rare outliers span more than a couple status updates (which shouldn't be needed more than about weekly, under normal circumstances) then your tasks are too big or you've got some serious process issues making everything take far longer than it should.

From the project manager's point of view: I think it depends on the urgency/priority of the bug. If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily. If it's a nice-to-have bugfix, update it whenever you can, I don't care. If it's somewhere in between, I'd expect an update frequency proportional to the seriousness of the problem.

Bottom line is that in any remotely serious business, status has to be written and communicated to the executives. It's not optional. There's the easy way: use the ticketing system, leave comments, mark things as resolved, so the managers can just read the ticketing system's reports and leave you alone. And there's the hard way: don't use the ticketing system, and have an annoying guy like me "pinging" you for updates and what's the progress on this and what's the status on that. We both like the easy way so let's settle on doing that!

> If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily.

That's what one has sev/incident response procedures for. Put everyone in the entire management chain on a conference call with execs/comms/legal for as long as it takes - and make damn sure the line manager is shielding the actual engineers from this process so they have time to fix the bug.

> From the project manager's point of view: I think it depends on the urgency/priority of the bug. If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily.

Right, that's why I specified "normal" and "ordinary" tasks. Outages are another matter.

> Bottom line is that in any remotely serious business, status has to be written and communicated to the executives. It's not optional. There's the easy way: use the ticketing system, leave comments, mark things as resolved, so the managers can just read the ticketing system's reports and leave you alone. And there's the hard way: don't use the ticketing system, and have an annoying guy like me "pinging" you for updates and what's the progress on this and what's the status on that. We both like the easy way so let's settle on doing that!

Devs aren't in the ticketing system all day. They close it because they're all bloated as hell and eat system resources like mad, only opening it when strictly necessary, which then takes forever. They take longer to navigate it than you do, because they're not in it all day. They dread it because ticket workflows are often convoluted and hard to understand for anyone who's not in the ticketing system all day, and because they're all designed in such a way that it's weirdly-easy to accidentally press a button or drag something and mess things up in ways that can be tricky to fix or even to understand what's happened, sometimes without even noticing one has done that—it usually feels like trying to collaborate by using the PM's RDP-shared Windows desktop, covered with directories and text files arranged just so.

It is not the "easy way" to them, it's easy for you, and only you—otherwise, they'd use it! If your devs are any good, I guarantee they're communicating a lot, just not where you want them to, because it is not easy for them. Slack, email, git logs, PRs, quite possibly a shadow-ticketing system that's not a resource-hogging, confusing pile of crap in really pathological cases (probably the one attached to any Web-attached source management system you're using)

I agree that status needs to be communicated, but if that's more than about weekly under normal circumstances then it's because someone's screwing up, and it's worth remembering that your "easy" as someone who's in Jira (or whatever) all day isn't someone else's "easy".

Their "easy" would be you letting them use a ticket system they find actually-usable, and then reading that and translating anything that's happened there, into the one that you like but that doesn't work well for them. Or just figure out a way to use the one they like—you're one person, they're several.

[EDIT] It's also worth considering that those kinds of high-visibility-to-managers systems are always going to be a bit bullshitty. People will omit things or even lie on them at higher rates than they will on purely-internal communication tools, which is part of why people don't like to use them for their actually important communication within a team. Letting the team communicate where they like and then translating that into Manager in the high-visibility system will get you more-accurate information, and you can decide what to do with it.

That really depends how short your management chain thinks the intervals are

I found the scrum master

Ha. No.

Do Linux kernel developers do that?

I recently pushed back on discussing if an already-completed ticket was really a bug, or a feature to work around a limitation in the browser.

I mean, that ticket was messing so hard the tech debt statistics! Or so that claimed the PM.

You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?

> whether a ticket was “critical” or merely “high?” or truly a blocker

Wait until they start adding additional categories like critical blocker, high blocker, severe blocker, exceptionally severe blocker, etc. etc.

Now apply that category soup to tracking both priority and severity.

Infinity blocker, infinity + 1 blocker

I certainly have, but I have rarely regretted spending the time to prioritize my work before starting my work and/or discussing the same with my team. Like pretty much all work of all kinds, there is variance in how long it takes and how effective the outcome is per person-minute.

These categories on ticket have little to do with me prioritizing my work. There are thousands tickets in each of those categories.

>spending the time to prioritize my work before starting my work and/or discussing the same with my team

And in the past, I did regretted opening unnecessary discussions quite a few times. I learned not to do it, because it ended in endless bike shedding or conflicts and there were no special gained insights. Turns out, I can do trivial decisions by myself.

This seems like a highly dysfunctional state of affairs. Maybe I've never worked at an organization big enough to suffer from this kind of thing.

Exactly, there’s a fine line between prioritization and bikeshedding.

If ticket priority does not matter, then why do you care? Set them all to single priority and don't think about it.

If priority does matter, then why "waste"? Lets say you get rid of tickets.. then your statement becomes:

"You've ever wasted a few minutes on whether a bug you found is worth mentioning in release notes? Or if it truly should cause revert of deployment?"

When said this way, doesn't seem like "waste" to me, rather a regular part of the job. If the person working the bug doesn't know how bad it is, then who does?

> If ticket priority does not matter, then why do you care?

Because when you have a ticket priority system, there is often someone external who cares deeply about ticket priority. And reporting requirements around ticket priority. And metrics about ticket priority over time.

If you've never been pulled into a meeting with Comms and Legal to discuss retoractively whether a (completed) ticket should have been labelled High or Severe... count yourself lucky

> You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?

Calling "deciding on how to spend your time" a waste of time seems a misnomer.

But ... that person is not deciding how he will spend time. He is deciding which labels to put on ticket. What he will do is not directly related to that.

What's a priority but a way to decide what to do next? The fact it's stored as a label on a ticket doesn't seem particularly relevant.

The discussion over what priority label to put on a ticket has very rarely changed my opinion on what the actual importance of the ticket is, and I'm generally going to pick what to work on based on that, not based on the label.

It is a way to categorize tickets. It somehow influences what is going to be done next, but it is only one of many factors.

One project manager in our company started to actually use it for prioritization, the higher the priority the sooner it was done. Soon after, literally everything ended to labeled critical.

People shouldn't be able to label their own bugs/features' severity or importance. They should be able to label it with severity or importance to them, and the team responsible should be allowed to triage accordingly.

Absolute priority quickly becomes washed out - everything gets shoved to one end of the range.

A useful priority scheme might be, insert the ticket in the list of open tickets by urgency and importance. Something like that, that you can actually make arguments about and compare.

Almost every software company I've ever worked with had this insidious "priority inflation" that couldn't be stopped. It works like this:

We start out with some sensible definition of priority for bugs: P3 = nice-to-have, P2 = low-priority-but-ship-blocking, P1 = emergency-fix-this-now. Bug intake goes on for a while under this system. Some bug filers don't feel their P3 or P2 bugs are getting worked on, so they "promote" those bugs to P2 and P1. That'll show those engineers my bug is important! Now we seem to have more and more P1 emergencies going on, and the team is struggling to just get through those. Nobody knows which ones are actual emergencies, and which ones are just "somebody being passionate about a bug".

Soon, we get an actual pants-on-fire production emergency. This emergency is more urgent than any P1, so we call it P0! Now we finally have a way to mark real emergencies, because the bug database is now overflowing with P1s. Soon people realize they can deem their favorite bugs as really-really-important, so they promote them to P0. Eventually, the database is now overflowing with P0s, and nobody knows what's really urgent. Then another real pants-on-fire production emergency happens...

I worked at a shop with P0, and then there were too many P0 tickets, and then you just worked on whatever the CTO told you was the _actual_ highest priority ticket when he stopped by your cubicle for a chat.

No one got fired for making something a P0. That's the problem.

Seems like an easy fix.

1) Allow developers to change the priority, i.e. downgrade P0 to P1 or P2, with all subscribers notified. Optionally, always downgrade to the lowest possible priority.

2) Shame people for inappropriately using P0. After a few strikes, remove their ability to do so.