> Ticket management is not busy work, it's a necessity for everyone to keep updated.
I would say that rather depends on how much of it you do.
I would say that rather depends on how much of it you do.
For example, I went through a dozen tickets this morning and 96% of my time was spent either writing updates or doing the work the tickets were talking about. 4% probably went to reading the ticket itself and placing it in the correct place after updates/work. That 4% means meetings later will flow faster, and I don't have to remember or write down details and statuses of things somewhere else.
Are people really wasting time on 'ticket management' that isn't as I've described?
Edit:
I've spent some time thinking about this, and despite being the org owner for our companies Azure DevOps instance I'm actually firmly in the 'Ops' camp of Ops<->DevOps<->Dev. My job is mainly Ops and I do some DevOps/SRE work on the side as the pragmatic-infrastructure-guy. I often see lots of nonsense done in the Developer camp. I think why I don't see the downsides of tickets is because I come from the background where tickets are more Help Centre-like. It's just pieces of work that needs doing or people need help with. If the help centre started arguing about if something is 'high' or 'critical' or spent 50% of their time just 'managing tickets' then they would flat-out just get fired. I guess that's the cultural difference between HC/Ops and 'Dev' that I wasn't really seeing before.
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.
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.
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!
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'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.
>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.
Calling "deciding on how to spend your time" a waste of time seems a misnomer.
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.
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.
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...
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.
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?
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
Wait until they start adding additional categories like critical blocker, high blocker, severe blocker, exceptionally severe blocker, etc. etc.
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.
I mean, that ticket was messing so hard the tech debt statistics! Or so that claimed the PM.
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.
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?
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.
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
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.
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.
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?
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.
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.
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!
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.
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.
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.
It's the lesser tier, often non-tech companies doing this kind of micromanagement.
It’s an option, I guess… let us know how it works out for you.
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.
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.
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.
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.
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 working software.
Iterative development is a how, not a what.
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.
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.
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.
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.
How long do your legs need to be? Long enough to reach the floor.
Does any of your manager, Product Manager, Project Manager, skip level, or teammates create unneeded communication overhead asking what the status of something is and when it will be done? A planning tool should communicate that.
Are deadlines being missed or visibility into what is actually being done missing? Planning tools should help with estimation and revealing how much complex work is being done.
In a lot of ways these tools are not going to make the work faster, but instead make it so that the human side is appeased. It reduces anxiety of managers, it creates an understandable evidence of work (most non-technical folks cannot tell the difference between a good and great implementation just by observing the app, but they can understand a ticket that explains a refactor). It drives alignment, communication, and buy in.
The fastest a developer can go is alone in a dark room with no interruptions. But that doesn't scale. Even if that engineer is a 10x engineer, you still need a different system when you want 11x development. That's when planning, communication, coordination, allocation etc. all come into play.