r/agile

After spending most of the last decade working across project management, Scrum, Agile delivery, programme management and transformation, I’ve decided to move back into Product Management.

This wasn’t an easy decision because delivery has given me a really broad skillset: stakeholder management, planning, prioritisation, risk management, Agile, transformation and working across complex organisations.

But over the last year or so, I’ve become increasingly concerned about where the delivery profession is heading.

I’m seeing a lot of very experienced Scrum Masters, Agile Coaches, Delivery Managers and Project/Programme Managers struggling to find their next role. At the same time, it feels like organisations are consolidating roles and expecting Product Managers, Engineering Managers and other leaders to absorb more of the traditional delivery responsibilities.

I don’t think delivery is disappearing. Complex organisations will always need people who can actually get things done.

But personally, I didn’t want to keep specialising further and further into delivery and then find myself overly dependent on one type of role.
My background was already fairly broad. I started in technology, worked in Product Management earlier in my career, and then moved increasingly into Agile, delivery and business transformation.
So I’ve decided to move back towards Product, while taking all of that delivery and transformation experience with me.

What appeals to me about Product is being closer to the actual decisions: understanding user problems, setting direction, prioritising, making trade-offs, working with engineering and ultimately being accountable for whether something creates value.

I’m not saying Product is safer, better, or immune from the same market pressures. It isn’t.

For me, this is more about broadening my options rather than becoming increasingly specialised in one profession.

Has anyone else made the move from Delivery / Programme Management / Agile into Product?
Interested to hear whether you think the delivery profession is genuinely changing, or whether this is just a particularly bad job market.

At one of my clients we had a pilot team moving a lot faster than the rest of the org, and finance got pulled in because everyone was making claims about savings.

The first comparison was kind of ridiculous: around 10x more features a month from the pilot team versus the traditional teams. Cost per feature looked like roughly $40k versus $340k. I don't trust feature counts across different teams, but even after pushing on the assumptions the gap stayed big.

The more useful part was separating the costs. We counted time waiting for approvals, work delayed, rework caused by the delay, and the operational overhead around all of it. The annual estimate came out at more then $100m across all teams.

What changed was finance stopped asking only how much technology cost and started asking what customer value actually came out. Faster wasn't automatically better. A team had to show impact. But delay was no longer treated as free.

What metrics have you used that finance actually trusted without turning them into targets people gamed?

How do you count cost of delay and rework without inventing a giant attribution model?

Has outcome-based funding changed real decisions anywhere, or did it eventually turn back into annual budget allocation?

I think many engineering dashboards mix two very different categories: activity signals and outcome signals.

Commits, pull requests, tickets closed, review time, and deployment frequency can help explain how work moves through a system. But they become dangerous when treated as performance scores. Once a team knows an activity is being judged, the activity can become the target. More output may then look like better engineering even when the product becomes harder to maintain or customers see no meaningful improvement.

A framework I find useful is to separate the conversation into three layers:

Activity: What work happened?

System health: How safely and predictably can the team make changes?

Outcome: What became better for the business, product, or customer?

The first layer is diagnostic. The second shows engineering capability. The third provides direction. None should be read alone.

For example, a rise in pull request volume is not automatically good or bad. It becomes useful only when paired with context: Was important work delivered? Did reliability improve? Did the team reduce recurring operational pain? Are changes becoming easier or more fragile?

The uncomfortable part is that outcome metrics are usually shared across product, engineering, and the business. That makes individual attribution harder, but perhaps that is the point. Software development is a system, not a leaderboard.

How do you distinguish useful operational signals from activity metrics that quietly turn into performance targets?

My friend and I have been building a small project for the past two months, and went through completely different project management setups.

Before this, I was a startup founder of a 10+ member team. Back then, our team used Linear, I loved it, best-in-class UI in my opinion. But over time, I just found that we went to the Linear UI less and less. The advantages that I used to appreciate became worthless, because we just managed those tickets with MCP anyway.

Unfortunately, my startup did not work out. This time, when my friend and I started, it was just the two of us. We did not go back to Linear, as sleek UI stopped mattering to how we actually worked. But we went further: I vibed an agent to fully run a html-based board. I used the agent to update tickets, flag stale ones, the agent can even send PR fixes when docs drifted.

For a few weeks it worked. Then it quietly stopped working. It is not because the agent was lazy, but because as the specs and tickets kept growing, they lacked structure and a real lifecycle (html) like an API has. Whenever we changed a project decision, the old one never really left; residues of outdated documentation, decisions, specs accumulated, and eventually confused the agent.

So, we moved the underlying tracking to plain GitHub issues instead. It is free, as we use GitHub anyway. It got everything I needed — basic ticket tracking with a real lifecycle. I don't like the plain GitHub Project view, so we kept the vibed beautiful html board, which syncs with the GitHub issues underneath.

I genuinely think, as a small team, we don't see the case for a PM SaaS anymore. But we are a two-person, all-engineer team anyway, so it is probably different at bigger teams.

In IT projects, I'm often blocked waiting on information from other teams. Chaser emails and calls eventually get an answer, but by then we've lost days and have to adjust the timeline.

I know dependencies are part of the job. What do you actually do to get responses on time and unblock yourself quickly and without damaging working relationships?

Personal experience welcome. Anything you do differently that reliably works? not textbook advice.

Our calendar is packed with planning sessions, standups, backlog refinement, stakeholder updates and retros. The strange thing is that most of those meetings exist because someone doesn't have visibility into what another team is doing.

A few people have suggested moving more planning into a visual workspace instead of relying on status meetings but I'm wondering if that works or if it just becomes another thing someone has to keep updated.

I'm building something in this space, so I'll say that up front. There's no link in this post and nothing to sign up for. I'm trying to work out whether my premise is wrong before I spend another few months on it.

Here's the premise. Planning artifacts live outside the work. The story map or the roadmap is in a whiteboard tool, the work is in the tracker, and the only thing connecting them is a person copying between the two. I think that single fact causes two separate problems, and I'd like to know whether either is real for you, or whether I'm just describing my own bad habits.

The first is staleness. The map is accurate for exactly as long as someone keeps doing that hour of copying. The week nobody does it, it quietly stops being true. Nobody ever decides to abandon the map — people just stop opening it.

The second is that you are paying for the copy. In my case: source control, a whiteboard tool to think the product through, a tracker to run the week. Three subscriptions, and one of them exists only to hold a duplicate of what already lives in another one. I'm pre-seed and paying out of my own pocket, so I feel that sharply — though I'm aware that if you work somewhere with a budget, tool spend is someone else's problem and this second point may read as noise to you.

There's also an asymmetry I keep coming back to. Plenty of teams ship without a story map. No team ships without tickets. The map is optional and the tracker is not, which makes it strange that we keep putting the map somewhere the tracker can't reach. Whatever else a team does, the work passes through the tracker. That's the one artifact nobody gets to skip, and it's the only place a map could live and be guaranteed to stay true.

I built mine on GitHub, where the issues already sit next to the code, the pull requests and the releases. That's a narrower bet than I'd like, and I know it puts this outside where a lot of you actually work.

So, honestly:

1. When your map or roadmap went stale, did it cost you anything? Or did it do its job in the room, and going stale was simply fine?

2. Does tool sprawl register as a real problem where you work, or only as a line item procurement worries about? I genuinely can't tell whether "one fewer tool" is a benefit anyone but me cares about.

3. If planning lived directly inside the tracker — journeys across the top, releases as rows, moving a card changes the real issue — what would you lose? My guess is speculative planning: you'd want to shuffle things around to think out loud without touching the actual work. But I've only tested that on myself.

4. Is the reason this doesn't already exist that it's hard to build, or that it's been tried and teams didn't want it? That's the answer I'm most afraid of and the least able to find out from the inside.

For calibration: it's been quietly available for a while and almost nobody has signed up. From where I sit, "the marketing is bad" and "the idea is wrong" look identical, and I'd rather be told the second one now than in six months.

Hey everyone — solo builder here. I've been working on JGP (Jira Governance Platform), a tool

that connects to a Jira instance, runs an automated audit, and emails a clean report on a

schedule (daily/weekly).

The problem I'm solving: anyone who's managed Jira knows it gets messy over time — tickets

missing required fields, orphaned subtasks nobody remembers creating, statuses that never

move, SLAs quietly breached with nobody noticing until it's too late. JGP catches this

automatically instead of someone manually auditing it.

Right now it checks for:

- Missing required fields (story points, sprint, etc.)

- Orphaned/stale tickets

- SLA breaches

- Missing approval steps in the workflow

I'm pre-revenue and looking for 2-3 people who manage a real Jira instance to try it free and

give honest feedback before I start charging anyone. Setup on your end is just generating a Jira

API token — takes a few minutes.

If you (or someone you know) manages Jira and this sounds useful, I'd love to hear from you.

Happy to answer questions about how it's built too — it's running on n8n under the hood.

The biggest problem in knowledge work is that the work itself is completely invisible.

In a physical factory, you can walk the floor and instantly see where inventory is piling up. In an office or remote team, bottlenecks hide inside unread email threads, private Slack channels, and buried spreadsheets.

When you can't see the flow of work, management defaults to constant status meetings, micromanagement, and missed deadlines.

Visualization isn't just for shop floors or BI dashboards. Simple visual systems—like a clear Kanban board or a simple capacity tracker—externalize invisible work, expose bottlenecks early, and give your team the clarity to self-manage.

How do you keep work visible in your team? Do you use visual workflow tools, or rely on status updates and meetings?

I coach two Scrum teams split across India and the US, both running under a SAFe setup at a large enterprise. For a while both sides kept telling me the same thing, basically: the other team’s status doesn’t match what’s actually in the system. Classic distributed team headache, I figured, and went looking for a distributed team fix.

Took me longer than I’d like to admit to notice the actual issue. We had two systems doing the same job. Engineers logged defects with all the technical detail in one tool. But the reporting that leadership actually looked at lived in a completely separate work-tracking tool. So people would update one and just… not get around to the other. Not because they were careless, just because who has time to enter the same thing twice for no real reason.

I almost went the “let’s tighten up tool discipline” route, honestly. Glad I didn’t, because that would’ve just meant nagging people about a system that was already annoying them.

What actually worked was way less exciting. We set up a simple sync so that logging once, in whichever tool people were already using day to day, pushed the info over automatically. No new habit, no policy, nothing to enforce. Just removed the double entry.
Gaps in reporting basically disappeared within a few sprints. Nobody worked harder, we just stopped making them do the same task twice.

Not sure how universal this is but it’s a pattern I keep running into as a coach - stuff that looks like a “process compliance” problem is often just duplicate effort in disguise. Before pushing for more enforcement on something that isn’t sticking, worth asking whether people are quietly being asked to do double work for it.

Anyone else run into something like this, where the fix ended up being removing a step instead of adding a rule?

I mange several engineering teams around the globe and I had an interesting conversation with our Head of Product the other day while talking about engineering headcount, velocity, and delivery. Like most product leaders, he wants things to move faster. He mentioned that several of his contacts at other companies have said Agile is “dying” and that nobody really does Agile anymore.

That caught me by surprise especially but I know the quality of code being released at the other companies so I'm sort of not surprised.

I completely understand that a lot of companies have moved away from rigid Scrum ceremonies, story points, or doing Agile “by the book.” AI, code generation, and experienced engineers have definitely changed how teams work. I can also see why small teams, startups, or microservice-focused organizations can get away with much lighter processes.

What I’m less convinced of is that Agile itself is dead.

In my experience, the larger the product, the more engineers involved, and the longer the project lifespan, the more communication, planning, testing, and coordination become necessary. Whether you call it Agile or not, those problems still exist.

Over the last 20+ years I’ve worked on teams that were:

• Single developers building bespoke applications.
• Small consulting teams delivering fixed-scope work.
• Cross-functional teams with developers, QA, project managers, DevOps, and product managers with lots of ceremonies.
• Organizations where I’ve inherited organically grown systems and had to standardize processes so they could scale.
• Very fast startups that do POC and then work to refine afterwards.
• Massive institutional products that move slow and release very slow.

Every one of those environments required something different.

So I’m curious what everyone else is seeing.

• Does your company still consider itself Agile?
• If not, what replaced it?
• Are you running Kanban? Shape Up? Something homegrown? Just “ship it”?
• How large is your engineering organization?
• Has AI changed your development process in a meaningful way?
• How do you handle planning, testing, prioritization, and communication as teams grow?

I’m not looking to start an Agile vs. anti-Agile debate. I’m genuinely interested in understanding what successful engineering organizations are doing today, especially at scale. It feels like a lot of companies have abandoned the terminology, but I’m not sure they’ve actually abandoned the underlying practices.

I have my own opinions about much of this but I’d love to hear what’s working and what isn’t and what your take on the next trends for any dev at scale.

Sou concursado como dev. Porém, atualmente, minha função é gerenciar a equipe da empresa contratada para desenvolver os softwares utilizando scrum.

Entendo que meu papel no gerenciamento seja aquele de um Product Owner. Porém, quase todo dia tenho de ficar discutindo detalhes técnicos de implantação e de arquitetura, framework, melhoria de código, etc. Isso toma muito tempo além das dailies, planing e refinamento de backlog.

Vou dar um exemplo: quando contrato uma empresa pra construir minha casa usando scrum, não espero ficar discutindo com o mestre de obra sobre o projeto elétrico, encanamento, etc.

Minha visão está errada? Seria um problema de falta de senioridade na equipe de devs? Costuma acontecer assim com vocês? Como eu poderia levar isso pra meu gerente?

Quando atuava no mercado, na minha experiência, não era assim que funcionava.

For the first two years of my role as Delivery Manager, I worked closely alongside an Engineering Manager for the same team. I was accountable for delivery, including serving as a scrum master. He was their manager, holding them accountable to their job performance, approving time off, supporting them in their professional development.

It worked well enough, I thought. There was the challenge of timezones. I was in the states with the team. He was based across the world. There were only about 3-4 hours of overlap with him for the team or with me.

This year, he moved away from the team, and I absorbed the people leadership duties, and the responsibility of technical decisions and plans for the team.

I’m doing a well enough job with the team. And in some ways, it’s beneficial for me to have the authority to hold them accountable as it relates to their delivery of work. But I’m finding it to be a bit personally draining. I’m an empath and people leadership is hard. I don’t have a frame of reference to know if my struggle is with people leadership in general, or if I just prefer to focus on process management and team enablement because the role is better when it’s set up that way.

I’ve heard that there are plenty of Delivery Lead and Delivery Manager roles that do not involve people leadership. So, which is the optimal setup in your opinion?

~Tl;dr Is delivery management better with or without people leadership?

I keep seeing small product teams handle design in one of two ways.

Either design happens inside the same sprint as development.

So the ticket gets picked up, the developer starts asking what this state should look like, someone opens Figma, the PM makes a quick call, and half the UX gets decided while the thing is already being built.

Or design works way ahead.

Everything looks beautifully figured out in Figma, but by the time engineering gets to it the requirements have changed, technical constraints show up, and a bunch of the design gets reworked anyway.

Neither feels particularly good.

The setup that makes more sense to me is somewhere in between.

For anything meaningful, design gets just enough of a head start to answer the expensive questions before development starts.

What is the actual user flow?

What are the weird states?

What happens on mobile?

What happens when there is no data?

What part is genuinely uncertain?

What does engineering need clarified before they commit to building it?

Then once development starts, design doesn’t disappear.

Someone still checks what was actually built, answers the edge cases that inevitably show up, and catches the small things that get lost between Figma and production.

I think that last part gets overlooked a lot.

A design being “done” because the mockup was handed over seems like a strange definition of done if the user only ever experiences the implemented version.

For a small team I also don’t think this necessarily means having a designer sitting around full time.

What seems more important is that somebody consistently owns the design side of the work and stays close enough to engineering that it doesn’t become a handoff ceremony.

I’m curious how teams here actually run this.

Does design normally stay a sprint ahead, happen inside the sprint, or get pulled in only when engineering hits something that needs a decision?

And if you don’t have a full time designer, who ends up owning those decisions?

And most of them can’t see it.
Here’s the scenario:
A piece of work takes 6 days to get through your delivery process.

Leadership sees:
Cycle Time = 6 days
But when you actually map the work:
→ Analysis: 45 minutes
→ Wait: 9 hours
→ Development: 4 hours
→ Wait: 2.5 days
→ Testing: 2 hours
→ Wait: 1.5 days
→ Deployment: 30 minutes

The work wasn’t slow.
The system was.
That distinction matters.
Because if you diagnose this as a productivity problem, you’ll probably:
• Push teams harder
• Add people
• Set tighter deadlines
• Ask for more status reports
…and barely improve delivery.

But if you can see where work is actually sitting, you can start asking much better questions:
Why is it waiting here?
How much WIP is ahead of it?
Is this handoff creating rework?
What % arrives complete and accurate?
What would happen if we fixed this one constraint?
That’s where Value Stream Mapping gets powerful.
Not as a workshop artifact that gets photographed and forgotten.

As a continuous improvement system.
That’s a big part of why we built FolioSynth.
To help teams visualize the current state, expose the friction hiding between activities, model a better future state, and measure whether the changes actually improve flow.
If your dashboards tell you that delivery is getting slower, but not why, take a look:

👉 FolioSynth.com
And here’s a question I’d love delivery leaders to answer:

If you mapped one piece of work from request to delivery today, where do you think it would spend the most time doing absolutely nothing?

Quarterly planning has become harder every year and not because we don't have goals but because every department explains those goals differently. Leadership focuses on outcomes. Engineering thinks about delivery. Marketing has campaign timelines. Product has roadmaps.

By the end of planning, everyone agrees but somehow leaves with different interpretations.

Has anyone found a planning tool that helps connect all those moving pieces visually?

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?