I abandoned proper issue management

Posted by CooperNettees@reddit | ExperiencedDevs | View on Reddit | 31 comments

the shop i work at is small. only 30 devs or so. i joined when they were just getting started; only two other devs. for a long time, i did all the backlog grooming, issue management and estimation, and planning. i was up front when I joined I would do this for a while but it wasnt something i was interested in doing forever.

once we hit around ~15 people I was spending about half my time wrangling issues. I felt like I had done enough of that and simply said everyone would be responsible for tracking their own work from now on, pending another system.

if they want to make issues and roadmaps, go for it. if they want to do it all in notion, fine; slack dms? cool, loose scrap paper? sure why not. nothing? fine by me.

in part i made this decision because i felt like I had covered doing this long enough, and if my boss didnt like it he could do it himself, hire someone to do it, or come up with some other process. But I was done with it as I had always said this was me doing them a favor.

surprisingly, it wasnt really that bad. customer reps started tracking just the work they cared about as lightweight as possible and began prioritizing against client asks directly. priorities change frequently enough that it didnt cause problems. big chunks of work specifically are still translated into issues and broken down. people just track what theyre working on themselves and things change frequently enough that any plans made would need to be revised anyways.

we lost visibility into a lot of the quarterly issue reporting, but no one was ever able to make much sense of that data anyways, and what changes are being made release to release are recorded in the changelog and merge commits anyways.

overall i actually don't really miss the rituals around issue creation, tracking estimation, prioritization, etc; I wouldnt mind doing it again but I would rather the company pay for it, or demand it be done, accepting the overhead as part of the work, than me take it all on myself again.

[-]

No-Economics-8239@reddit

Kanban is a perfectly valid way to do work tracking. There are some trade offs, but overall on certain teams it can be a great fit. If your work schedule is inherently chaotic and deadlines aren't as pressing as leadership would have us believe, than you don't need to try and add extra overhead. As you point out, the extra work of trying to make things less chaotic aren't always as valuable as the time it takes to prepare, groom, and estimate things. On the other hand, some teams and industries do benefit from the extra overhead and discipline. While some might enjoy the challenge of a constantly changing work board, others prefer a more sedate and regulated pace where things are more thoughtful and difficult to change.

[-]

CooperNettees@reddit (OP)

i have done waterfall, agile, kanban and now nothing at all. what i will say is the systems companies invested the most into making work well for them are the ones I've found have worked the best.

[-]

ings0c@reddit

My experience is quite the opposite - in the teams where the devs owned the board, with very little process, and minimal interference from management, things have worked great. The focus was the work, and the process just helped us do it.

In the orgs that have invested heavily in process, it’s been hell. The process became a job unto itself. SAFe is the epitome of this kind of process-gone-wrong.

[-]

Tee_zee@reddit

I’m an engineering manager ; going to give a different perspective.

In the teams I’ve worked with where the devs are allowed to manage their own backlog, they’re all extremely happy, because they get paid to do a hobby instead of delivering what the business needs and wants.

[-]

Adept_Carpet@reddit

If the devs don't understand what the business needs and wants and aren't motivated to deliver, there is no system that will deliver goods results.

If they do understand and want to deliver, then basically any system will work.

[-]

Tee_zee@reddit

I agree, but I see the system as an easy, non-personal way to enforce accountability and create the minimum floor of the culture. You'll soon find people who don't conform to it and make it easier for both of you to either resolve the differences or part ways. I think lots of people unfortunately are traumatised by previous micromanagement, i find there's a lot of pushback on systems for tracking work that are rooted in fear from previous projects or jobs, rather than specific criticisms.

[-]

CooperNettees@reddit (OP)

in my experience when the process is really heavy its typically for a reason. for example, I worked in a space with high compliance requirements. the company used waterfall and did all the design up front because our clients needed a software bill of goods to get approvals ahead of time. then would hand us back a massive 900 page document with the acceptance criteria. then we would break that up based on the delivery milestones we needed to hit by certain dates.

on the ground the process felt onerous. but I can understand why they went with that approach. it made sense given what our clients needed from us to accept the finished product.

ill admit ive seen terrible SAFe disasters as well, but I guess it never felt like there was any real reason for it in those circumstances.

[-]

Potato-Engineer@reddit

I like Kanban, so I present this anecdote for amusement, not criticism:

I've heard of ways to add extra process to Kanban. You get your usual group of PMs and managers competing for dev time and trying to escalate their favorite work items, and eventually, you add a New Dictate: work cannot be escalated, but items can be de-prioritized. So getting any rush work done means you need a sign-off from everyone who has tasks above you.

[-]

0Iceman228@reddit

30 devs is large, not small. I think it's important to point out that this size is already not common at all. This is more devs than the 4 companies I worked at combined, including externals. Also so many developers have never worked in different environments and think none of those things you can disregard matter, yourself included it seems. I'm not a fan of these posts because they try to paint this universally true picture which is just wrong and gets people getting into the industry the wrong idea. The framing should be different, with more nuance.

[-]

CooperNettees@reddit (OP)

30 devs is small. ive overseen 150 devs.

you should read some of my comments. i make it extremely clear i have worked in many different environments and seen processes work.

what doesnt work is putting everything on one person. if the company doesnt want to invest in process thats their decision.

[-]

gomihako_@reddit

We like to shit on AI here but setup MCP rules with Claude and connect it your Jira.

[-]

light-triad@reddit

This has been my experience as well. Every time I get enough power in an org to do so, I kill Scrum, most of the official Jira processes, and nothing bad happens. We usually become more productive. The case I always try to make to people about why this happens is that Scrum actually has the very obvious tax of the Scrum ceremonies. If you're getting the whole team together a few hours each week to maintain the Jira board, then there's less time to get them together for more useful things like talking about the projects they're working on and having actual discussion on what to work on next.

If I could make one change to the software industry, it would be convincing people of this. Scrum only makes sense when you have a product owner that is qualified to do the job, actually takes it seriously, and the engineering team is not. It's a very specific circumstance, which I've never actually encountered in real life. Scrum is a process designed so that you can take the ideas of one person with all of the business and product context (product owner) and translate them into actionable work items by the engineering team in two week increments.

If this doesn't apply to your team Scrum is not right for you. And it's probably not. Any halfway decent software team will have business and product context spread across people inside and outside of the engineering team. If this applies to you then you're better off doing Kanban and replacing all of the Scrum ceremonies with meetings where people talk to each other about important things instead of story points.

[-]

EquationTAKEN@reddit

Scrum only makes sense when you have a product owner that is qualified to do the job

This resonated with me. I've been a fan of scrum for a long time, but I'm realizing now that this is only because my old job has a PO that was excellent at owning the backlog, knowing that prioritizing one thing means putting something else on hold, understands the value of a WIP limit, writing perfect tasks with acceptance criteria, and in general respected developers' time.

At my new job, we have the Scrum ceremonies, but the PO prioritizes everything. The fact that she's not allowed to sort the list by "everything at #1" is an annoyance, and she expects us to understand why the backlog isn't sorted. The issues have no description because it was created verbally and "understood at the time", which means it can only be picked up by someone who was discussing it at the time. If they remember it. Which they don't. So it has to be re-discussed later.

And on that note, back to polishing my CV.

[-]

Tundur@reddit

I'd also add that, if you are on a team of engineers with no product knowledge being micromanaged by a product manager, your absolute first priority should be gaining that product knowledge and putting the PM out of a job.

Devs should be directly plugged into the business, not treated like contractors at the far end of a bureaucratic logistical tail.

[-]

EquationTAKEN@reddit

That, I'm not entirely sure of.

For context on the good PO I was talking about: I worked on an enterprise in-house tool with an in-house userbase of about 200. The PO was initially a user, who had supreme knowledge of what the tools did, what they were for in the grand scheme, and sat closely with the users.

The users came to the PO with bug reports, feature requests etc. And then the PO would handle the prioritization, writing out workable tickets, and grooming the backlog.

I guess that's something of a unique scenario. But I would not want to put a developer on that.

[-]

compubomb@reddit

The main issue this brings up is lack of accountability, and people can invent shit they worked on but didn't? Also are you working on shit the organization wants you to. It's about resources allocation. I guess they just don't give a F.

[-]

CooperNettees@reddit (OP)

if they're worried about it they can figure it out on their own

[-]

arihoenig@reddit

I have seen issue management become an empire of its own. I try to focus on making sure we don't have issues to manage (at the very least that the issues we have to manage weren't caused by me).

It is tricky because people are rewarded for managing issues, so creating issues and then managing them puts one in better stead than not creating issues in the first place.

Better to not have issues management at all, rather than have issue management become an entire self sustaining make work project.

[-]

bokchoi@reddit

I'm am in a small dev shop and while we have an issue tracker, we don't use it any longer. It is the graveyard where we can dump issues or long term projects that we don't want to completely forget about but don't want to look at daily. Instead each dev and pm track the prioritized issues for their clients in lightweight manner (eg, in a todo list and emails). Surprisingly, issues are not dropped or lost and clients are happy. We do provide summaries for individual clients on delivery but, as you say, we lose insight to query across the whole org. Is say on whole everyone is much happier.

[-]

hyrumwhite@reddit

Do you ever find issues get lost?

[-]

CooperNettees@reddit (OP)

I cant think of a case where thats happened and it actually mattered. many issues get forgotten about and never really end up being resolved directly; instead they may get erased during the depreciation of old code or systems.

now, we do lean on our customer support team to keep track of work thats important for clients from their perspective. so that doesnt get lost, as they're tracking it. and internal technical issues of importance I track myself to make sure they are eventually addressed.

so its probably happened but its never been of any real consequence.

[-]

Attacus@reddit

I solved this when I released hold on things with overly complex jira workflows too. Linear was a godsend. Organized enough to keep track of things, keep people in the loop and give people autonomy. But not so organized it feels like too much red tape to get anything done.

[-]

theuniquestname@reddit

I've never understood why some teams that I interact with want me to enter their work tracking tickets for them.

Just copy my email or instant message into whatever you need.

[-]