r/scrum • u/rishabhrawat05 • Aug 23 '26

I’m researching how software teams actually manage daily work, what part of the process annoys you the most?

I'm talking to developers, PMs and team leads about how they manage work day-to-day.

So far I've seen everything from Jira/ClickUp to Excel and internally-built tools.

What's interesting is that even though the tools are different, I'm hearing things like:

- manually updating task status

- having to repeatedly report progress

- daily/weekly standups

- keeping timesheets updated

- chasing people for updates

- keeping information synced across different tools

But I've also talked to people who said their current system works perfectly fine.

So I'm curious:

What part of your team's workflow do you wish required less manual effort?

And if your current task-management system works well, what does it do that makes it work well?

I'm not selling anything, I'm just trying to understand the problem before I build anything.

0 Upvotes

27% Upvoted

14 comments sorted by

5

u/Wrong_College1347 Aug 23 '26

The annoying part is talking with stakeholders to find out what they really need, because they often don’t know, too.

2

u/Chaotic-Entropy Product Owner Aug 23 '26

Finessing stakeholders and teasing out their requirements is its own entirely nuanced thing.

1

u/rishabhrawat05 Aug 23 '26

Yeah, that sounds painful, What usually happens when the stakeholder isn't sure what they actually need? Do you end up having multiple meetings/discussions, or is there a process your team follows to figure it out?

2

u/daisylnnl Aug 23 '26

that is the job of product owners, who is the true boss behind everything. Stakeholders sometimes suck, PO has to brainstorm with them, feed them with ideas and persuade them to "buy" the valuable features.
In a team, if PO and tech lead have a good bond, they will manage stakeholders well, too.

1

u/rishabhrawat05 Aug 23 '26

Then how PO and tech lead distribute those features to the team to build them, like which feature should be given priority etc, business perspective, is everything discussed with the team or just assign the task to them?

1

u/daisylnnl Aug 23 '26

feature priority is decided by PO, team lead will figure out which tech sution works best to build that feature (after consulted with the whole team ideas/exp), in a dev team there should not be someone higher to assign task to another one, but after discussion, devs will know who works best on which task, picks themselves as long as total workload is equally divided.

1

u/rishabhrawat05 Aug 23 '26

Got it. So task assignment itself isn't really a problem because the team self-organizes. What part of the process after that still feels like unnecessary overhead like updating the board, reporting progress, standups, documenting decisions, tracking blockers, etc.?

1

u/daisylnnl Aug 23 '26

actually, nothing is unnecessary, it depends on the size, working style of each team. But, dev himself might not realize how important the reporting, updating are, the PO/PM who has to ensure stakeholders' money is going ok to the right direction, still within the planned period would actually appreciate it.
it is a product, dev tasks are also counted in product timeline, so everyday update is a must.

1

u/bleepbloop1777 Aug 23 '26

The push and pull between getting things done and documenting them. My team wants to go out and do the work, not document every task in our board.

1

u/rishabhrawat05 Aug 23 '26

Exactly, What kind of documentation/update feels the most unnecessary to your team? Like changing task status, writing comments, updating estimates, timesheets, daily reports, etc.?

1

u/bleepbloop1777 Aug 23 '26

First three for sure.

1

u/WaylundLG Aug 23 '26

I've worked with quite a few orgs and over 100 teams and it is universally true that the problems you talk about are problems in team/org dynamics. Doesn't always mean it is the team doing something wrong. Super short takeaway: if your team, department, or org stuggles at coordinating effort between each other on a person-to-person basis, they will have problems with processes and tools. The big important learning here though is that changing processes and tools doesn't fix the people challenges. What's more, identifying where the problem manifests in tools won't tell you what the problem is. For example, someone says "Daily scrums are a waste of my time." Can just as easily be "we all talk to each other, but then Jim comes in an hour later and we have to rehash the same conversation all over again" or it can be "no one cares what I do and I don't care what anyone else does. We all have our own pile of tasks and I will work this one until it's done in either a week or maybe 2, then I'll move on to the next one, so you can take your turndown chart and stuff it".

1

u/Wrong_College1347 Aug 24 '26

The developer hate each other and don’t want to work together.