▲ 8 r/agile

Do PM tools quietly kill agile or are we just using them wrong?

Noticing a pattern across teams I've worked on. The more structured the tooling (Jira, story points, burndown charts), the more the team seems to optimize for the board looking right instead of the work actually being right. Story points become something to argue about instead of a rough sizing conversation. Burndown becomes something to defend in a meeting instead of a signal to act on. Feels like the tool quietly reshapes behavior toward satisfying the tracking system over the actual agile values underneath.

At the same time, informal whiteboard Kanban doesn't scale once you've got multiple teams and real dependencies, leadership needs something to actually look at.

So, is heavier tooling just an inevitable tradeoff at scale or has anyone found a way to use structured tools without the tool becoming the process itself?

reddit.com
u/Agile_Syrup_4422 — 8 days ago

i spend more time feeding the tool than doing the work the tool was supposed to help with

ok i need to rant because i had a realization this week that annoyed me more than it should have. i sat down monday to actually do some work and instead spent the first two hours getting the board ready. updating statuses people forgot to move, fixing an automation that silently broke and had been misfiring for a week, renaming a bunch of tasks so the reporting wouldn't look insane, archiving old stuff, chasing down three custom fields that were empty. two hours. and none of that was work. that was maintenance on the thing that's supposed to help me do the work.

and then it hit me that this happens constantly. i've slowly become the unpaid full-time admin for a tool that was sold to me as a time saver. every new feature is another thing to configure. every automation is another thing that'll break in a way nobody notices until the numbers are wrong. every view somebody requests is another thing i have to build and then maintain forever. the tool doesn't reduce my workload, it just added a whole second category of work: keeping the tool itself functional and honest.

and if i stop maintaining it for even a week? it rots. statuses drift, automations pile up errors, the board turns into a junk drawer, and suddenly nobody trusts it, which means everyone goes back to asking me directly and the tool was pointless anyway. so i can't stop. i'm locked into feeding it forever just to keep it from becoming worthless.

i genuinely can't tell anymore if these tools save more time than they cost. some weeks i'm convinced a shared doc and a decent memory would be faster than the elaborate machine i now spend my life oiling.

so tell me i'm not alone. how much of your week actually goes to maintaining the tool versus using it? and has anyone deliberately gone simpler and felt better for it or does the maintenance tax just come with any system once your team is big enough?

reddit.com
u/Agile_Syrup_4422 — 23 days ago

Do truly customer centric companies exist? After 15 years in product, I've started to doubt it

I've been in product roles since around 2009, currently leading a few teams. Worked at startups, a scale-up and two big corporates, and every single one of them had customer obsession or user first written on a wall somewhere. In practice? It almost always turned out to be customer-centric theater.

User research? Sure, we did some. Personas? Framed and forgotten. Actual decisions driven by user needs? Not really.

The core issue, in my experience, isn't the PMs or the researchers. It's what actually drives the roadmap once you're behind closed doors. The roadmap gets set by whichever enterprise customer is threatening to churn, whatever the biggest deal in the pipeline needs to close and whatever the CEO saw a competitor do last week. The user gets invoked constantly but almost always as justification for a decision that was already made for other reasons. Nobody wants to say we're building this because sales promised it, so it gets dressed up as customers are asking for it.

And no matter how much effort I put into building a real discovery culture: talking to users, testing before committing, being willing to kill an idea that doesn't land, it keeps crashing into the same wall. Quarterly revenue pressure, the loudest customer winning and leadership that says listen to users right up until the moment the data disagrees with what they already wanted to do.

So I'm genuinely asking: have you ever worked somewhere that was actually customer-centric? If yes, I'd love to hear what actually made it different. Was it the leadership, the size, the business model, luck?

reddit.com
u/Agile_Syrup_4422 — 29 days ago

what surprised me about project management after leaving corporate for a startup

spent over a decade doing PM in big corporate setups: formal PMO, stage gates, the whole thing. jumped to a startup about six months ago. now that the shock's worn off, here's what's actually different, in case anyone's weighing the same move.

first: nobody here knows what a project manager is supposed to do. in corporate my role was defined down to the artifact. here i got a polite nod and basically ok so what will you actually do? stung at first, then felt freeing. no template to fill but also no template to hide behind.

the documentation habit was the hardest to break. i came in ready to build risk registers and change control, started doing it and realized nobody was reading any of it. in a 30-person company half the process i was trained to run is solved by two people turning around and talking. i had to unlearn the instinct that a document equals value. a lot of it was just me recreating the comfort of my old job.

speed over polish, for real. corporate decisions took three meetings and a sign-off. here someone decides in slack over lunch and it ships friday. sometimes that's the wrong call made fast. but i didn't realize how much of my old job was managing the process of deciding instead of actually deciding.

authority basically doesn't exist and that's clarifying. no positional power to lean on, so it forced me to get good at the thing that was always the real job – influence, trust, being genuinely useful. the process was propping me up more than i wanted to admit.

honest downside: it's lonely. no PM peers, no manager who's done my job, no playbook. i took all that support for granted in corporate and some weeks i really miss the guardrails.

where i've landed: the value isn't process for its own sake, it's judgment about when a little structure helps versus when it just slows a fast team down. a startup doesn't need someone to run ceremonies, it needs someone who brings just enough order without smothering what makes it fast.

anyway, no big conclusion. if you made the corporate to startup jump, did yours go the same or totally differently?

reddit.com
u/Agile_Syrup_4422 — 1 month ago
▲ 830 r/corporate

i quietly stopped overdelivering for a year and got the exact same review. nobody noticed.

so this has been rattling around my head and i feel like some of you will get it.

for about six years i was The Reliable One. you know the type. the person who answers slack at 9pm, who picks up the project nobody wants, who stays late to fix the thing that isnt even theirs because someone has to. i genuinely believed that if i was just visibly the hardest working person in the room it would obviously pay off. that was the whole plan. work harder than everyone, get recognized, move up.

what actually happened is i became load bearing. like the building would not stand without me, which sounds great until you realize that means they can never let you leave the spot youre propping up.

the thing that broke it for me was small. we got a new hire on my team, nice guy, did the bare minimum, left at 5 on the dot every day, never volunteered for anything extra. and at review time he got the same rating i did. same. and i had spent that year basically holding the team together with my hands. i wasnt even mad at him honestly, dude had it figured out. i was mad at myself for believing the story.

so i ran an experiment. i just... stopped. not in a quitting way, i still did my actual job well. but i stopped picking up the orphan tasks. stopped answering after hours. let things that werent mine sit until the actual owner dealt with them. said "i dont have capacity for that this week" out loud, which felt illegal the first few times.

a full year of that. you know what happened? nothing. same review. one "we'd love to see more leadership" comment, which, ok. the work i dropped either got absorbed by someone else or turned out to not matter in the first place. the org did not even flinch.

and the part that actually stings. i had more energy, i was less resentful, i was honestly probably better at my real job because i wasnt spread across nine things. and it cost me literally nothing on paper.

im not saying coast. im saying the thing they never tell you is that above and beyond is mostly priced in the second you do it twice. it stops being a bonus and becomes the baseline they expect for free.

anyway... did you keep grinding, did you dial it back, did dialing it back actually cost you anything or was that fear made up too? feel like half this sub is secretly the reliable one

reddit.com
u/Agile_Syrup_4422 — 2 months ago

I thought we had a communication problem. We didn't

One thing I got completely wrong early in my PM career was assuming that if people had enough information, they would automatically stay aligned. So whenever something felt off, my solution was usually more communication. More updates. More explanations. More meetings. More status reports. It seemed logical at the time.

But looking back, I don't think lack of information was the problem most of the time. The PM knew what was happening. Team leads knew what was happening. Leadership had reports. Stakeholders had timelines. Everybody had pieces of the puzzle, yet somehow people still ended up pulling in slightly different directions.

I remember one project in particular where everyone was working hard, nobody was hiding anything, communication was frequent and still there was constant confusion around priorities and dependencies. We weren't missing information. We were missing a shared picture. That's something I didn't appreciate enough when I was younger.

The projects that felt easiest to manage weren't necessarily the projects with the best people or the best processes. They were usually the projects where work was visible enough that people could understand what was happening around them without asking someone else to explain it.

You could see what was blocked. You could see what depended on what. You could see why a delay in one place mattered somewhere else. A surprising amount of coordination happened naturally because people weren't operating inside their own little corner of the project anymore.

These days I spend less time trying to create perfect updates and more time trying to make the work itself easier to understand. Maybe that's why some projects feel heavy even when communication is technically good. Everyone is informed but nobody can actually see the whole thing. And when that happens, the PM quietly becomes the human API between teams, translating the same context over and over again.

reddit.com
u/Agile_Syrup_4422 — 3 months ago

At some point the tooling around software development became heavier than the development itself

At first the board exists to support the work. Few tickets, clear flow, simple process. Then as the team grows, more structure gets added because honestly some of it IS needed. More visibility, more tracking, more coordination between teams. But after a while I started noticing something weird.

Engineers were spending increasing amounts of time maintaining the picture of the work instead of the work itself. Updating statuses, splitting tickets correctly, linking dependencies, fixing sprint boards, making sure reports look right, writing updates for systems that already contained the information somewhere else. And the strange part is nobody explicitly asks for this. It slowly emerges because once enough managers, stakeholders and teams depend on the tooling, keeping the system clean becomes its own responsibility.

At some point I realized we had engineers doing administrative work to maintain the project management layer around engineering work. What made it more confusing is that from leadership perspective things looked healthier than ever. Beautiful dashboards, organized boards, detailed metrics, lots of visibility. But inside the teams people felt slower, heavier and more fragmented.

I’m not anti-process at all. Without structure large software projects become chaos very quickly. But I do think there’s a point where the coordination layer starts consuming too much of the energy it was supposed to optimize.

And honestly I still don’t know where that line is. Every team says we only added what was necessary and somehow six months later everybody is drowning in workflow maintenance again.

reddit.com
u/Agile_Syrup_4422 — 3 months ago
▲ 76 r/agile

Retrospectives slowly became one of the weirdest parts of agile for me

When I first started doing them years ago they actually felt useful. Team talks honestly about what is broken, people raise issues, small improvements happen, everyone leaves feeling lighter. Simple.

But after enough projects and enough companies I swear half of retros now feel completely performative. Every sprint starts looking the same. Same sticky notes, same conversations about communication, same action items that sound good in the meeting and then quietly disappear a few days later because everybody already moved on to the next fire.

And honestly most of the time people in the room already know what the real problems are anyway. Deadlines are unrealistic, too much work gets started at the same time, dependencies between teams are messy, priorities change every week depending on who talked to leadership last. None of this is usually some big mystery. But instead somehow the conversation drifts into safe topics like ticket quality or whether standups should be 5 minutes shorter lol.

What also killed retros for me a little bit is noticing how fake they become once people stop feeling comfortable saying what they actually think. Then the whole thing turns into this weird corporate theater where everybody carefully picks problems that are acceptable to mention but not important enough to create tension. And sometimes I genuinely think the team does not need another retrospective at all. Sometimes they just need less meetings, less context switching, fewer priorities changing mid sprint and less pressure to constantly act like everything is manageable.

I’m not saying retros are useless. I’ve had some really good ones over the years. But lately it feels like agile teams became much better at talking about problems than actually removing them.

reddit.com
u/Agile_Syrup_4422 — 3 months ago