r/agile

I'm starting to wonder if our team is really doing agile development or if we're just going through motions

We switched to agile about 18 months ago and have all the usual stuff - daily standups, sprint planning sessions, retrospectives, sprint demos, backlog refinement. We use project tracking software, estimate story points, measure team velocity. Our scrum master even has proper certification

Here's what bothers me though

Our sprints are basically just taking a roadmap that executives created 4-5 months ago and chopping it into 2-week pieces. If we want to change anything during a sprint we need to get approval from upper management first

Every retrospective we end up with same action items about "better communication" or "more accurate estimates" but nothing actually changes in how we work. We've been saying we'll fix the same issues for like 6-7 months now

All our requirements come from management as complete specifications. When they say "collaboration" they just mean we figure out technical implementation. Nobody on the team ever talks with real users

We spend way more time updating tickets and explaining why our velocity changed than actually writing code

When we try pushing back about unrealistic timelines or too much scope, management says "you need to be more agile - agile means adapting fast"

We still can't deploy anything without going through change approval process that takes 2-3 weeks, but then leadership wonders why we're not delivering faster

I've read the agile manifesto and it talks about responding to change, working software over documentation, collaborating with customers, having empowered teams

But it feels like we just do whatever was decided months ago, except we do it in 2-week chunks and call it agile

Few questions for people here:

- Is this how most companies do agile or is something wrong with ours?

- What does real agile actually look like in practice?

- How much autonomy should agile teams really have?

- Am I expecting too much from agile methodology?

so i stumbled on this term from japanese engineers — メテオフォール型開発 (meteor-fall dev). basically means your boss is a god who randomly throws meteors at your project and obliterates whatever you were doing.

Read from this blog: https://autotomy.dev/blog/meteor-development-is-real

That’s pretty funny ngl

Just for clarification, I'm not a scrum master. I'm just a grunt.

The last few months have been pretty rough for my team. The issues have been stacking and the releases have been more last minute and stressful. Everyone seems on edge all the time now.

With this, the last few retrospectives have all started with "guys, why are we getting so many defects?" from management and leads.

To combat the defects, they introduced more planning and even more meetings, but frankly I think all of it wastes more time, makes processes more convoluted, and completely misses why we might be having issues.

I could blame a lot of things for the defects, like introducing more testing, including other metrics in defect counts, or the push for AI usage, but overall, I believe that we're trying to move too fast and get too many things in before deadlines.

Because we're crunching constantly, we don't have enough time to test or check what AIs doing, so we get more defects. It always rolls over into the next sprint. All of this is adding technical debt and makes it worse for us going forward.

The problem is, I'm worried about not being able to articulate this, others not feeling the same, and getting fired because all of this goes against what management wants.

Additionally, I don't even know how to fix this. Re-do priorities? Switch to Moscow method? Get rid of the stupid weights and estimates? I have no ideas.

I was wondering if anyone here knows how I can bring this up or if I should just shut up and do my work. Any advice is appreciated. Thanks in advance.

Hello,

I'm building a small solution starting from a situation identified at the work place: a system to approve releases in production (software or infrastructure modification etc). What I mean by this? Imagine that there is a release approval hierarchy: Team Lead, Product Owner, Director and the list continues. And they all need to approve a release in production, a new feature.

Most of the things found on internet are very focused on pipelines and code deployments, running tests etc.

What is needed at the company where I work is an excel file where a release for a product is explained and then a committee validates it, but it's not related to any deployment pipelines. Just approvals and some kind of validations from different people that the release is tested, validated, has a deployment plan and a rollback plan.

What I am trying to understand is if it's worth it? I don't want to invest months of work and features if it's not a good idea. Tools like Jira Service Management and others are over complicated for this kind of stuff.

Thanks a lot for your opinions!

Hi all,

I am working as Lead BA for some time now. I want to transition into product owner role. I have the sufficient experience and knowledge but since I never had an actual PO title, my applications are bouncing back. I was thinking maybe getting one of these certificates would help me crack that door. I am aware it is asked a lot here but I wanted to if any of these certificates helped anyone break into PO role from BA/Senior BA roles.

Thanks all!

Ok, so I dont have ANY experience being an actual Scrum Master... however, due to other volunteer experience that I have quite a few of my friends who already work for the governmen think that it will be a perfect job for me... The problem comes in that I just found out that two of my degrees are now null and void...because the college lost their accreditation before I graduated. Is it possible to become a Scrum Master without a college degree?? But also, what's the best way to start learning about Agile methodology from ground Zero??

Our team's daily standup has slowly devolved into a mind-numbing "attendance and status check." Basically, we go around the virtual room, everyone lists out the exact 3 Jira tickets they touched yesterday, states they are working on the exact same things today, and says "no blockers."

It feels like a massive waste of everyone's time, and the team is completely checked out.

For those of you who have successfully fixed this: How did you transition your standup from a rigid status report into an actual collaborative, team-syncing conversation?

What specific questions, formats, or facilitation tricks worked best to get your team engaged and talking to each other rather than just reporting to the manager?

I’m at the point where I genuinely dont know if the problem is the tools or just what happens when agile teams scale past a certain size. Right now we are struggling with this weird middle ground where simple tools stop working but heavier tools slowly kill flexibility.

Trello style boards are nice at first because everybody actually uses them but once you start having multiple teams, dependencies, shared resources and roadmap planning, everything becomes labels, workarounds and wait which board is the real source of truth? moments.

Then you move to something more enterprise and suddenly the opposite problem appears. Too many workflows, too many fields, too much updating, too many layers between work happening and work represented in the system. Feels like the tool slowly turns the team into administrators.

Main things we are struggling with currently: seeing dependencies across teams without building giant Gantt monsters, keeping backlog/workflow simple enough that engineers dont hate updating it and roadmap + day to day execution living together in a way that actually makes sense. What I DONT want is another system that looks amazing in demos but turns into process gravity 6 months later.

What agile teams here are actually using long term once projects become more complex?

Running workshops for hybrid teams where half are in office and half remote. Office people dominate the conversation every time, remote ones go silent or just lurk on camera. Tried breakout rooms but they end up awkward with nobody talking.

We have online whiteboard stuff and visual collaboration tools with infinite canvas which seem perfect but keeping remote brainstorming flowing is hard. 

Tried jira integrations to prep but still nobody participates equally. Smart meetings sound good in theory. Remote brainstorming just dies.

How do you make this work?

We run a planning poker tool and have been collecting anonymised session data for the past 6 months. Published our first analysis last week.

A few things that surprised us:

84% of sessions never produce an estimate above 5 points. The "planning poker is for complex uncertain work" framing in most agile books doesn't match how teams actually use it. Most teams use it to confirm small work is as small as it looks.

Thursday is peak day — not Monday. Only 17% of sessions happen on Monday. 25% happen on Thursday. Most teams have moved away from the sprint-start ceremony model entirely.

1 in 3 teams has a measurable outlier voter — someone who consistently estimates higher or lower than the rest of the team across sessions. Usually they're seeing something the others aren't.

75% of active teams run 3+ sessions per month — treating it as a continuous backlog habit rather than a bi-weekly ceremony.

Curious whether this matches what you see with your teams.

I've been working with Agile since 2018. I've led multiple products with this methodology in Brazil, and now I've got my first experience managing an international team with Agile and it's been frustrating as hell.

In the teams I've worked with in Brazil, whether you are an employee or a consultant, the whole team follows and applies the methodology to the best of their abilities. If something from the methodology doesn't work, we adapt, but we always stick to the best practices.

What I'm seeing at my current company is that once you get a job as an international contractor, fuck the methodology. Hell, even the company employees don't care about it. Is Agile a joke?

The daily stand-up is a simple attendance sheet. Developers don't participate in the refinement; they just want to be handed tasks. When they face blockers or anything that prevents them from working on their assigned tasks, they wait until the end of the sprint to say so, just shrugging their shoulders and saying, "I wasn't able to complete this."

I started with a team of 10. I've replaced 4 people so far, and the interviews were a horror show. Whenever I asked the contractors to explain how they work with Scrum, their answer was: "I used Jira." But once I got into details, such as task management, refinement, planning, roadmap, etc., they'd just look at the camera in panic. There was even this one time that the AGILE LEAD said: "But this is the responsibility of the Scrum Master." "This" was the developer managing their own cards and updating their status.

And the best part: they don't care. If you replace them, they just find a job somewhere else and keep getting their paycheck until they get fired again.

Before joining this company, I'd always hear how "perfect" working with Americans was because they'd stick to the methodology, apply it, follow it, document stuff, be organized, etc. What I'm seeing now is chaos, blue-collar kids with crayons up their noses.

Hello PM, PO and scrum masters and everyone, I would like to know what kind of project management tool is being used in your org part from JIRA.

Jira is currently managed in my order and it's heavily customized.

Customized as in - we have different types for different workflows means I've a board for architects, developers testers and every type follows a different workflow for every project

In order to switch to another tool, what do you recommend

I’ve been on five different teams in six years. Every team has the same conversation every two weeks: how many points is this? Nobody knows. We guess. We’re wrong. Repeat.

The thing that frustrates me most is that we have all the data to do this better. We have years of git history showing which parts of the codebase are complex. We have Jira history showing how long similar tasks actually took. We know who on the team has deep knowledge of which modules.

But none of this gets used during planning. We still sit in a room and play cards.

I’ve been thinking about what it would look like if planning used actual data instead of intuition - not just velocity metrics, but real signals: codebase complexity at the file level, individual developer patterns, historical risk of specific modules.

Honest questions:
1. Has your team ever tried data-driven estimation? What happened?
2. What would make you actually trust an automated estimate?
3. Is the real problem the estimates themselves, or is it that nobody respects them anyway?
4. Would you pay for a tool that improved planning accuracy if it could prove it with your own historical data?

Not a product pitch. I’m at the research stage and want to hear from people actually doing this work before I build anything.

Also how exactly is your PO or BA validating requirements with the stakeholders? Do they literally have the stakeholders review the finale user stories, acceptance criteria and all?

Every sprint it's the same. We sit down to plan, open the backlog, and half the bugs are marked Critical or P1. Engineers file them that way because they know P3s never get looked at. Sales escalate whatever their biggest customer complained about last week. And I'm left re-ranking everything manually before we can even start the conversation.

The result: sprint planning turns into a negotiation instead of a decision. Half the time we're not even talking about what to build we're arguing about whose bug matters more.

What actually helped us was switching the triage question from "how severe is this?" to "what breaks for a paying customer if this ships?" That one reframe cuts through the politics faster than any priority matrix I've tried. A bug that crashes the app for free users drops. A bug that silently corrupts data for enterprise accounts rises even if it was filed as Medium.

Curious if others are dealing with the same thing. How does your team handle severity inflation? Do you have a framework that actually sticks, or does it devolve into whoever shouts loudest?

Hi everyone

I’m transitioning from a non-IT background into IT as a Business Analyst and have an upcoming managerial interview. I need help preparing for deep-dive Agile and scenario-based questions.

Looking for questions/answers on:

I kept my fullest efforts to clear my first round please help me through this

Sprint ceremonies (planning, standups, reviews, retrospectives)

User stories & acceptance criteria

Backlog refinement & prioritization

Stakeholder management

UAT handling and defect management

Agile vs Waterfall scenarios

Real-time BA challenges in Scrum teams

Best ways BAs can use AI tools in daily work

Day to day activities

Would really appreciate interview tips, beginner-to-intermediate guidance, real project examples, and managerial round expectations from experienced BAs/Scrum professionals. Thanks!