r/agile

One thing that used to drive me crazy: we would leave a meeting with a kind of clear next step, then it would get discussed again in Slack, then someone would confirm something by email… and two weeks later the same question comes back:

“Who owns this? What is the final agreement, and why is it not finished by the deadline?”

And usually, nobody has a clean answer. Not because we don't know what we do, but because work rarely starts in Jira or Asana. It starts in conversations and is discussed over different communication platforms. Then everyone assumes someone else captured it properly.

That is one of the main struggles I used to have.

I’m building LigoFlow to help teams capture those commitments from the places where they actually happen, meetings, Slack, email and turn them into clear owners, deadlines, and follow-ups inside the tools they already use, with clear contextualization and escalation patterns to identify the unclear tasks from the clearly articulated ones

I do not want this to become another noisy task generator. If it creates more admin, it fails.

I’m trying to understand if this is painful enough to pay for, or if it is just one of those problems teams complain about but never budget for.

For people running teams:

• Where do follow ups usually get lost for you?
• Do missed commitments actually cost you money/time, or are they just annoying?
• What would make you uncomfortable about a tool helping track commitments across Slack, meetings, and email?

Not sharing a link yet. I’d rather get honest criticism first.

In my team I notice senior engineers write detailed explanations in Slack, but months later nobody can find them. Curious how others solve this.

Hi everyone,

I'm currently building a SaaS focused specifically on team decision-making. The idea itself is already well defined, but before I invest more time into development, I want to validate whether it solves a real problem for Agile teams.

The goal isn't to replace Jira, Azure DevOps or other PM tools. Instead, it's designed to help teams:

-compare alternatives before making important decisions,

-understand where disagreements come from,

-preserve the reasoning behind decisions,

-explore different decision scenarios,

-and build organizational memory around decisions.

I'd really appreciate your honest opinion.

Do Agile teams actually struggle with these problems, or do your existing tools and processes already solve them well?

If you think there is a gap, which part of team decision-making is the most frustrating today?

Landed a scrum master role at a medium Fortune 500 that pays considerably more but also a business analyst/product owner role at a smaller company working in digital experience for customers. With the way the industry is heading, which would be better experience to have to stay competitive in the market?

Hi guys,

I was an Agile Delivery Lead / Scrum Master and was let go as part of a mass layoff about a year ago. I have since attempted a pivot into Project Management however I am not getting anything back from any of the employers despite tailoring my resume for these roles, things such as listing traditional PM skills I obtained through my career as a Delivery Lead. I have refined my resume many times through AI tools and actual resume professionals however I rarely hear back from employers. I'm in Victoria, Australia.

Anyone else having trouble landing traditional Project Manager roles from an Agile background too? I'd love to hear some recommendations from those who managed to land a role.

Do you have a shared understanding of readiness across teams, several definitions for different kinds of work, or is it mostly handled informally?

Across an organisation, product, design, engineering, testing, operations and management may all look at the same item and judge readiness differently.

One person may mean ready to prioritise. Another may mean ready to explore. Someone else may mean ready to execute. It might even be ready to postpone, merge or toss.

So when your organisation or team defines an item as ready, what exactly is it ready for?

EDIT: I’m especially interested in concrete examples. What does “ready” actually mean in your team, and is that definition mainly for development or for different kinds of work?

I've been running retrospectives with my team for about six months now and I keep hitting the same wall. We surface the same issues sprint after sprint, people vent, we write down action items, and then nothing actually changes by the next retro. Rinse and repeat.

I've tried different formats like Start Stop Continue, 4Ls, Mad Sad Glad, and while they help mix things up, the core problem stays the same. The team talks, but followthrough accountability is weak. Nobody owns the action items in any real way and there's no mechanism to track whether improvements actually happened.

I'm starting to wonder if this is a facilitation problem, a culture problem, or just a sign that retros need to be structured differently altogether.

For those of you who have cracked this: how do you make retros produce real change rather than just cathartic venting? Do you limit action items to one or two per sprint? Do you open every retro by reviewing last sprint's commitments publicly? Is there a facilitation technique that actually builds accountability without making the whole thing feel like a performance review?

Would love to hear what has actually worked for your teams, not just in theory but in practice.

I’ve been noticing that thanks to AI, development teams are moving insanely fast now. Faster builds, faster releases, faster execution in general. (I wonder if the 2 weeks sprint still make sense nowadays!!!)... but not sure if this high speed means become faster at cost of any alignment.

I mean the users or stakeholders can keep the pace with this velocity?

Until few years ago the execution was the "bottleneck", With AI there is less "friction" from that side but if priorities aren’t clear, AI doesn’t fix that, and I wonder if we are just building the wrong thing faster.

This is maybe a hot take, but opening a discussion. I believe that agile is a framework invented by paper pushers (product managers) to avoid responsibility. It is inefficient, and introduces significant burden onto developers.

Here are some of my observations:

1. Agile gives product managers an out to “change their mind”. Sure, changing their mind on a ticket costs them nothing to rewrite, but the consequences of redoing architecture and reworking implementations are enormous. They waste time.

I always ask product managers: “can you guarantee me that every edge case is documented, and that these requirements will never change in at least 5-10 years?” If the answer is no, then the ticket is not ready.

2. Agile gives the paper pushes license to not think through the entire app. Before we build, EVERYTHING should be planned. If not, how can we accurately design the database with constraints, select architecture, etc.

A full product spec should be delivered up front, and developers build over a period of years.

3. Agile results on costly rework. I had one feature where we did an MVP, and then several augmentations over a period of years. I probably spent 40 days doing it. If everything was scoped up front and we did it years ago all at once? It would’ve taken 25-30 days. We churned through 10-15 days because the paper pushers said “we need client impact now” and “we have to make sales to fund the project”.

If upper management isn’t willing to make a long term commitment and up foot the bill early, then they shouldn’t be in the software business.

I was recently brought into a company specifically to help lead an Agile transformation. I’ve worked with the hiring manager before at two other organizations, and in both cases the transformations were successful.

In this situation, we’re starting to get pushback that the changes “aren’t working.” As a result, someone who isn’t very familiar with Agile is now proposing a new team structure and suggesting we eliminate some core Scrum ceremonies.

What’s making this tricky is that the leader who brought me in knows my track record and experience, but seems to be giving weight to feedback from someone without Agile background over established practices that have worked in prior transformations.

I’m curious how others have navigated situations like this—when Agile ways of working are being questioned early on, and decisions are being influenced by stakeholders who don’t have direct experience with it.

What’s worked for you in terms of stabilizing buy-in or course-correcting in environments like this?

To further back up my stance, reports show there has been a 20% increase in productivity in the 6 weeks we've been using Agile ;)

As a junior dev, I’m in this cycle every week: get assigned a bug or feature, the senior who owns that area is heads-down in meetings, and I’m left to reverse-engineer the codebase(which is dynamic these days), testing setup, and deploy pipeline on my own. By the time I actually understand enough to ship, half the day is gone.
What tools, browser extensions, IDE plugins, or scripts do you rely on to quickly spin up context on an unfamiliar part of the stack without basically bothering everyone?
OR leaning on tools is the way to go first of all
And solving it , another hustle!

TL;DR: I'm the only UI/UX designer supporting eight developers. I'm excluded from sprint planning, standups, and most development discussions, so I often only find out about work by accident. Developers sometimes build features before designs are complete, and many implementations don't match the designs. I'm looking to understand how other UI/UX Leads work with development teams and what a healthy design, development process looks like.

I'm a UI/UX Design Lead, but I'm also the only designer supporting a team of eight developers.

Lately I've been struggling with how we work together, and I'm trying to figure out if this is normal or if our process is fundamentally broken.

At the moment, the process looks something like this:

- A new project starts. Sometimes the Project Manager tells me about it, sometimes I find out later.

- I work on the designs and documentation mostly in isolation.

- Once everything is ready, I hand it over to the developers.

- Sometimes development starts before any designs or documentation are complete.

- The developers build the feature.

- I test it before deployment, if I'm informed...

- A lot of the implementation doesn't match the designs or requirements.

- The developers fix it, I test again, and we repeat the cycle until it's ready. If they don't bypass me completely.

The biggest challenge is that I'm completely disconnected from the development process. I'm not invited to sprint planning, backlog refinement, or daily standups. When I ask the developers what they'll need from me for the upcoming sprint, I usually don't get a response.

Most of the time I only accidentally discover that they need a design, have started developing something, or are about to deploy. By then it's usually too late to influence the solution, and I'm left finding issues during testing that could have been prevented much earlier.

I don't expect to control development, but I do feel like design should be part of planning instead of being treated as a handoff at the beginning and QA at the end.

For those of you who are UI/UX Leads or Senior Product Designers working in Agile teams:

- What's your design and development process?

- Do you attend sprint planning, standups, or backlog refinement?

- How do you make sure developers have what they need before a sprint starts?

- How do you prevent developers from building features before designs are complete?

- What has worked well for collaboration between design and development?

I'm trying to understand whether this is just the reality of being the only designer, or whether there are process changes I should be pushing for. Any advice or examples of how your team works would be greatly appreciated.

Or is it something to break down, simplify, understand better and improve before deciding whether it matters enough to act on?

How often does an item appear urgent simply because someone says it is, rather than because delaying it has a real consequence?

At what point does a backlog item become work you have actually chosen to do?

https://project-methodology-advisor-397643982268.us-west1.run.app/

This is a decision engine designed to help to see what is the most suitable method to use in project development simulate, and calibrate the optimal project management.

I created this because I was soo stressed.

Can someone review and tell me is it suitable or not.

Or anything that I need to improve on it?

If I'm not suppose to post this here, please tell me. I'll remove this later.

I was the Scrum Master when we first adopted Scrum — got the certification, then tried to actually get a team to follow it, in a context that should have been running Kanban from day one. I spent years watching ceremonies happen for the sake of ceremonies, forcing sprint cadence onto work that was actually flow-based and interrupt-driven, and wondering if I was the only one seeing how broken it all was.

So instead of just venting about it, I turned it into a structural argument. I took my actual team, exaggerated it into a space crew on a dying ship, and wrote out exactly how a textbook-bad Agile implementation actually breaks down — not as a rant, but as a real case study wearing a sci-fi costume. Somewhere in there I ended up naming the mechanism I kept watching play out in real life: a Team Lead role that doesn't exist in any Agile framework, inserting itself between the team and leadership anyway, filtering what gets through and taking credit for what makes it out clean. I'm calling it the Shielded Incompetence Layer — zero certification, zero accountability, full veto power, just by sitting in the right spot in the org chart.

And because apparently catastrophe isn't complete without something absurd in the background, there are also nine retired astronaut monkeys who keep drifting into frame mid-meeting, because every team needs a pet on camera, and these ones happen to glow.

It's called Agility Horizon (woohoo, I'm on Amazon). If you've ever watched someone with no certification and no accountability install themselves as the single point of failure between your team and the people who could actually fix things, you'll probably recognize a lot of this.

Genuinely curious if this resonates with anyone else here, or if I'm just describing my own personal nightmare.

I've spent months collecting the most common consulting failure complaints from ops leaders, CI professionals, and manufacturing executives. Six Sigma practitioners, BPM practitioners, Lean practitioners, people who had been through it and felt the sting.

The complaints weren't about incompetent consultants. They were about a system that's structurally misaligned. Specifically: most consulting models are paid by activity, not outcomes.

Here are the five patterns that kept appearing:

1. Expertise was rented, not transferred
2. "Cultural resistance" was actually design feedback
3. Sustainability was treated as a nice-to-have
4. The Control phase was always skipped
5. The savings rarely exceeded the fees

What's been your experience? Genuinely curious, particularly from people who've been on the client side of a failed engagement.

ive been doing this long enough (started around 2012, scrum master then coach, now leading a couple teams) that ive gotten kind of cynical and im hoping someone here can talk me out of it.

every company ive been at has done agile. we had the ceremonies. we had the board. we had the certifications on linkedin. and almost none of it felt agile in any way that actually mattered. it was more like we adopted the vocabulary and the meetings and skipped the entire point.

heres the tell for me. the second a team says we don't think we'll hit that date, here's what we learned and what we'd suggest instead, watch what leadership does. in a real agile place thats a good day, thats the system working, you got new info and you're adjusting. everywhere ive been it gets treated as a failure to manage. someone asks why the estimate was wrong. dates get recommitted. and everyone quietly learns to stop being honest in planning. so you end up with sprints full of padding and a roadmap nobody believes, which is just waterfall wearing a costume.

and i dont even fully blame the teams or the frameworks. its mostly above us. leaders want the predictability of the old way AND the buzzwords of the new way and when those two things fight, predictability wins every single time. agile becomes a delivery factory you measure, not a way of working you actually trust.

i used to think more coaching would fix it. now im not sure you can coach your way out of a culture that fundamentally doesnt want to be surprised. so im honestly asking, has anyone worked somewhere that was the real thing? where changing direction based on what you learned was normal and not a fire drill? if yes i really want to know what made it different. was it the leadership, the size, the industry, luck?

A friend recently showed it to me. I liked that it focuses on ticketing and boards without a lot of extra complexity, and the pricing seems reasonable. Curious if anyone here has used it or has thoughts on how it compares with Jira, Linear, or Trello. https://wannatrack.com/

At what point does the team know it understands the problem well enough to start designing a solution?

Is there a conversation or activity that gets us there, or do we mostly assume it happens during refinement?