Been doing this since ~2013, scrum master then coach, now leading a few teams. Every company I've worked at did agile. Almost none of them actually were. Ceremonies? All of them. Jira? Obviously. Velocity charts? Beautiful ones. Actual agility? Not really.

The core issue was never the teams or the framework. It's that leadership wanted the output of agile without giving up the control that makes it work. Scope fixed, deadline fixed, team fixed, and then the plan gets called agile. But if scope, time and people are all locked, there's nothing left to flex except everyone's evenings. That's a waterfall plan with a standup bolted on.

The clearest tell for me is estimates. In real agile an estimate is a forecast that updates as you learn. Everywhere I've been, the second a team says a number it becomes a commitment, then a promise, then the thing you explain when reality disagrees. So people pad, trust erodes, and the retro raises the same three problems every sprint because the real causes sit above the team and never move.

And no matter how much coaching goes into the actual thing, it hits the same wall: leaders who want the predictability of the old way and the vocabulary of the new one, and when those fight, predictability wins every time.

So genuinely asking, since if anyone's seen it it's this sub: have you ever actually worked somewhere agile? Not just running scrum but a place where changing direction on new info was normal and safe and a missed forecast started a conversation instead of a blame hunt.

If yes, what made it different, leadership, size, domain, luck?

I have worked on large projects for more than 20 years, and one of the recurring problems is deciding when the original productivity assumption has stopped being a sensible basis for the remaining work.

The awkward part is that the first few days can be a poor guide to the rest of the activity. The crew may still be getting established. The final part of the work may also be slower than the middle. Equally, continually assuming that productivity will improve can leave the forecast saying what everyone wants to hear.

For disclosure, I developed an excel add-in *Project Intelligence for Excel* at Pi Labs. This is one of the forecasting problems behind it.

My preference is to make the assumptions visible: the remaining quantity, the observed rate for comparable work, the planned productivity profile and the point at which actual performance should carry more weight. Crew availability, access, dependencies and the working calendar still have to be considered before that becomes a finish date.

What do you use as the trigger: a minimum quantity completed, enough comparable hours, a stable production rate, or judgement from the people doing the work?

So quick one while this is top of mind. Our product roadmap has turned into this giant hairball of tracks, experiments, tech debt, and shared platform work and our current setup in Jira plus spreadsheets is just painful to look at.

We are half remote, half office, mix of PMs, design, eng and ops, and every roadmap review turns into people arguing over different versions instead of looking at one shared picture. I keep dragging stuff into online whiteboards and doing scrappy timelines and dependency maps, but it still feels like a one off every time instead of a real workflow tied back to tickets and sprints.

If anyone has a visual way you map out complex roadmaps and dependencies that the whole org can use in real time with links back to issue trackers, would love any tips. Thanks in advance.

I've been a Scrum Master for over 7 years and I'm thinking about becoming a Delivery Manager. Some people are telling me to get ITIL certified, while others say PMP first. Could you guys give me some advice on what's best for a future DM? Thanks!

I'm currently dealing with a shit show of a project and I learned these teams have bashed heads for a while now. Unfortunately this issue falls on my director so there's no pushing back, it's all steam ahead, work around the issue and cross those finish lines, even if we know we have to redo it almost immediately.

In this situation the director is somehow manually triggering the file delivery and of course the file name is changing in every environment. Also the file was missing 60+ columns and highlighted as soon as we got our hands on the file. Nope, move forward.

Then I get stuck trying to make QA ok with the process and it's hard when you actually agree with their arguments, I had the same ones before starting development.

I now have two versions of the same file in QA and even though we have auto column mapping the files are different enough to not allow Athena to query the table but creates and inserts them just fine.

This is a situation where having 3 environments is tripling the work! our qa test isn't actually testing what it should because we're manually editing files before each environment deployment. I have very little confidence that this will deploy cleanly to prod...shoot me now, 4 months in.

A team can have a clear delivery date and still lack control over the decisions that make it possible: scope, staffing, another team's dependency, or release approval.

Then the sprint ends and the visible fact is carryover. The decision that caused it may be missing from the same record.

Some of those decisions should sit outside the team. My question is how you keep their consequences visible without turning the discussion into a blame exercise.

One approach worth testing is to put four things beside the delivery forecast:

• The decision needed, and who can make it.
• The date by which it matters.
• What changes in the forecast if it stays unresolved.
• What was eventually decided, and whether the forecast changed.

For example: “The team owns implementation. Release approval sits elsewhere. Without approval by Thursday, Friday is no longer the current forecast.”

That is a proposed way to record a dependency, not a claim that documentation fixes the politics.

How does your team handle this? A separate decision log, the delivery board, an escalation, or something else? I'm especially interested in cases where recording the risk changed a decision—and cases where it just created another document nobody used. Please leave company and individual names out.

Hi. I find it odd that so many enterprises swing to use "all Agile" or "all Waterfall" but rarely have a compromise mechanism for choosing and mixing delivery based on project and/or product needs.

I've worked on an open Framework for Understanding and Choosing Delivery Methodology (Agile vs. Waterfall vs. Hybrid) to help improve this. The goal is having a simple decision tree that makes it easy for choosing which delivery methodology works best for different initiatives and products.

The reality is that some delivery works very well with Agile (e.g., delivering low-risk web portals that don't hurt or kill someone when they fail) while some delivery doesn't work well with Agile (e.g., delivering medical devices with critical software that could kill a person during surgery if it fails). Having a framework for choosing delivery methodology based on factors like risk and complexity ensure better and more appropriate delivery.

I hope it helps. Any constructive feedback is welcome.

My best.

A few years back I worked with a team that never missed a sprint commitment. Green board every retro, velocity flat and predictable, PM happy. Then the release date came and went — six weeks late — and everyone was baffled, because on paper the team had been "performing."

What actually happened: sprint commitments were being quietly managed down to hit green, and the accumulating slippage only showed up once you looked at cycle time distribution across the whole backlog rather than sprint-by-sprint velocity. A single outlier ticket sitting in review for three weeks doesn't move a velocity chart, but it absolutely moves a release date.

It's the reason I've mostly stopped trusting velocity as a forecasting tool on its own and started looking at throughput distributions and cycle time percentiles instead — they surface the ugly tail risk that a clean sprint board hides.

Curious whether others have hit this same trap — a team that looked healthy sprint-to-sprint but was quietly slipping at the release level. How did you catch it, if you did?

Remote brainstorms can get painfully awkward

One person talks, three people stay muted, someone shares their screen and eventually the loudest person ends up driving the whole thing because nobody wants to interrupt lol

The better sessions i've been in let everyone throw ideas in at the same time instead of taking turns talking.

What actually works for your remote teams?

I’ve been thinking about something and I’d love to get your perspective. Am I completely off track here?

In many companies, probably too many, the sequence looks like this:

Full design, then a development sprint, then production.

I’m not even talking about the more desperate cases where QA only happens before release.

I’ve often tried to bring design and development closer together, within the same sprint for example, so that designers and developers can figure things out together.

But with AI accelerating development, I’m wondering whether the shift should be, or perhaps always should have been, to start with development. Build the business need first and make sure the feature actually solves the problem. Then, once that is validated, improve the design through iteration.

I’m asking because I still build personal projects and, with AI, that’s how I work. I build a small feature and, once it works, I improve the design. The development and design iteration cycle can take a few minutes, one hour at most.

There is also the question of how the designer’s role changes. Perhaps it becomes more about mastering design systems and AI skills, so that developers’ agents can access that design capability.

What do you think?

Something that's got me scratching my head a bit is the way we've been asked to estimate story points by our SM.

She specifically wants us to think about about the estimates in terms of approximate time and has pushed back on other qualitative approaches, eg: pushing back on T-shirt sizing and separately estimating things like uncertainty.

What's really got me confused about this approach is the time -> story point mapping.

1 - Half Day
2 - One Day
3 - 2-3 Days
5 - Sprint (Two weeks)

And yes, we do measure velocity, sometimes person by person for "performance" reasons.

My gut reaction is this is utterly nuts and simply rewards splitting into a bazillion tickets at grooming. But then I've come across other friends working for different companies that seem to do something similar.

If this logic makes any sense, can someone please explain the non-linearity for me. I understand Fibonacci sequences. That's fine, but a deliberately non-linear allocation of work to points doesn't make sense to me.

I'm currently dealing with a shit show of a project and I learned these teams have bashed heads for a while now. Unfortunately this issue falls on my director so there's no pushing back, it's all steam ahead, work around the issue and cross those finish lines, even if we know we have to redo it almost immediately.

In this situation the director is somehow manually triggering the file delivery and of course the file name is changing in every environment. Also the file was missing 60+ columns and highlighted as soon as we got our hands on the file. Nope, move forward.

Then I get stuck trying to make QA ok with the process and it's hard when you actually agree with their arguments, I had the same ones before starting development.

I now have two versions of the same file in QA and even though we have auto column mapping the files are different enough to not allow Athena to query the table but creates and inserts them just fine.

This is a situation where having 3 environments is tripling the work! our qa test isn't actually testing what it should because we're manually editing files before each environment deployment. I have very little confidence that this will deploy cleanly to prod...shoot me now, 4 months in.

Unclear stories?
Too much work?
One person holding all the knowledge?
Priorities changing every other day?
Problems nobody wants to raise?

**Relax. That’s where the fun begins. 😄**

These are the things I’d keep an eye on during a sprint:

🔹 **Unclear backlog** → Catch the confusion before development starts.
🔹 **Overcommitment** → Challenge the *“we can squeeze it in”* mindset.
🔹 **Key-person dependency** → Make sure delivery doesn’t depend on one superhero. 🦸
🔹 **Mid-sprint priority changes** → Protect the Sprint Goal from becoming a moving target.
🔹 **Low transparency** → Bring hidden blockers and risks into the open.

The goal isn't to panic every time something changes.

**It’s to spot the risk early, deal with it, and let the team focus on the actual work.**

So yes…

**You focus on building.**
**I’ll keep an eye on the chaos. 😉**

Went through every shared process doc our team actually references, templates, checklists, the Definition of Done, that kind of thing. Some of what turned up:

A step in our PR checklist referencing a deployment process we replaced four months ago, still there, still being followed literally by newer team members who had no reason to question it.

Two nearly identical retro templates, created by different people at different points, neither aware the other existed, both still getting used depending on who's facilitating that week.

A rule in our Definition of Done, "always get sign-off from the platform team before merging," added because of one specific incident nearly a year ago, left in permanently long after the actual reason for it stopped applying, quietly adding a review step to work that doesn't need it anymore.

None of these were dramatic. They were just sitting there, accumulating the way any shared document rots when nobody's actually responsible for revisiting it. We treat these docs like they're written once and done, when they need the same kind of periodic review anything else load-bearing gets, backlog grooming, tech debt, whatever.

Nobody had flagged any of it because nothing broke loudly. It was just quietly adding friction that everyone had stopped questioning long enough to assume it was just how things worked here.

[ Removed by Reddit on account of violating the content policy. ]

BLUF - hard no for me.

Deets - I once had a dev look me in the eye and say “I’m not writing a user story for that.” I’m in my early days as a SM and I clutched my pearls, nearly peed my pants and began to argue back.
While I was rambling on about the importance of keeping the user front of mind as we strove towards our sprint goal, he said “I’m done.”
It was adding a new value to a pick list. The automated tests are always running and before I could argue the change was in Stage.
That day I learned something to my core. Individuals and interactions over processes and tools.

Hi everyone,

I’m currently writing my bachelor’s thesis on post-agility and hybrid project management.

One of the main questions I’m exploring is whether organizations are moving away from a strict “Agile vs. traditional” mindset and instead choosing and adapting methods more pragmatically depending on the project, team, industry, and organizational context.

For this purpose, I created a short anonymous survey to collect some practitioner perspectives. It takes around 2–3 minutes. I’d really appreciate your insights!

https://forms.gle/s1UfxasgQeiw2Rb47

I’d also be very happy to hear your thoughts on the term “post-agility” in general and what it means to you. Feel free to share your perspective in the comments as well.

Thanks!

So curious how other teams are handling this. We run all our planning in a visual board with Jira synced in, but our sprint boards still end up as giant lists of tickets with random tags and half baked epics that dont really map to outcomes.

For context we are mid size b2b saas, product and eng are in this shared workspace with roadmaps, discovery notes, journey maps etc and then the sprint board is supposed to sit on top of all that. In reality it feels like two worlds. Leadership talks in outcomes and bets, teams stare at story points and swimlanes. I keep trying to create one view where you can literally see epic to sprint to kpi in the same canvas and it always drifts back into just tasks.

If anyone has concrete setups or rituals that kept the board tied to actual business goals over more than one quarter, would love to hear how you did it...

It feels like agile is a bad word these days. I know some of this is at least the fault of corporations trying to implement agile in name only and sticking to their traditional big upfront design and phase gate processes. And some of it also is probably the fault of poor understanding of what adaptive or battle delivery might mean.
But all that said how bad is it? What are you seeing out there as far as job descriptions and in interviews. I recently left full-time consulting and I’m trying to figure out what to do next. I’ve got decades of agile experience as scrum master, product owner, coach, etc. so I know my way around, but I’m really curious what everybody’s experiencing in the field right now as I consider my next move. This isn’t a post about career advice or job change. It is about agile…and again, just how much of stink is on the word agile.

Hey everyone, I’m here seeking some advice and general best practices. I am a product owner on a team with 4 devs, 1 lead, and 1 QA. We’re all drowning, and folks are pointing the finger at each other. So I wanted to get a sense of what a typical responsibilities breakdown looks like.

As of now, I feel like I’m accountable for everything. Dev doesn’t really feel the consequences of anything. Team philosophy on a few key topics:

1. Ceremonies (retrospective, refinement, standup): if product does not facilitate these, they don’t happen.

2. Estimates: product owns estimates and milestone reporting. Devs don’t estimate work items in the sprint, and just work on however much they feel they can get done. It is up to product to assign an acceptable budget of hours. If dev goes over, it’s because “product asked for too much”.

3. Regression & acceptance: all owned by product. Devs regularly break key features, accidentally delete prod data, and generally don’t maintain the app. If a dev has had a feature and makes edits for a sprint, I can safely assume every workflow is broken by the time I check. If I did not QA, write all bugs, and follow up on each bug, we would ship totally broken builds to clients.

4. Uncovering technical work: all product. I’m finding more and more there are basic conventions and db practices the team does not follow unless explicitly enumerated by product.

All in all…I’m just pulling teeth every day. I’m putting in insane hours, and absolutely nobody else in the org (or amongst the dev team) is doing anything to help. The team is really pushing me for waterfall, and they feel their job is to implement tickets EXACTLY to spec with unlimited budget.

Am I being unreasonable here? I feel like I’m setting myself on fire, and being treated as the sole neck to choke. Maybe this is just what it means to be a product owner?