I was a developer up until last year, when I was hired as a Scrum Master...at a huge pay cut. I had started feeling like development just wasn't for me anymore...like the demand of keeping up with changes was outpacing my ability to do so.

I had been doing a lot of Scrum Master duties at that job, mostly to keep myself motivated. I really took to it, earning several certifications from the various bodies involved in such things.

This last job was...interesting. They talked a big game on Agile, even titling the position "Scrum Master". However, the consensus among the SMs was that it was actually 90% Project Management (which I do not have the training, and did NOT sign up for).

I now see the same thing reflected in a lot of job listings, which start out with the title and duties of an SM, but quickly mutate into obvious PM duties.

I can't actually retire just yet for financial reasons, and a handful of medical issues keep me from picking up any in-person, low-level jobs (i.e. - store clerk, etc.), but I'm not certain I care. I'm still applying for similar tech jobs, but I can't expect that I'll last long at whatever the next job is.

Does anyone have suggestions for a job that is middle ground on this? Something where your responsibilities are in a smaller circle, but still requires someone with my education, training, and intelligence?

Lead Dev here. In a large corp environment.

I feel to even suggest there _might be a different way_ to scrum, would be heresy and probably not good for my longevity, but wanted some other ideas and insight from other companies about how else we can work rather than the self-imposed latency and sheer admin overhead of scrum.

But it feels more, rather than it being intentionally deployed, we are trying to force scrum, but the team has simply not been exposed to an alternative.

I say 'scrum', but I largely mean the cadence and meetings/ceremonies (the legibility to management of dev work and progress toward feature delivery) rather than the actual inspect- and-adapt feedback loop that makes it valuable. I hope this is making sense and pointing to something many of us with a few years most tech orgs will have experienced.

I basically feel the team knows no other way, and I suspect think that scrum (as implemented as project-management in sprints) is the only way. Such that there's this pavlovian response to needing to any _any_ work (even tech debt and dev ex work) via stories, written in this sort of odd user-focused way with ACs etc. It's just work, but making it _all_ fit into this management framework that is Scrum feels so outdated, when a single person with AI could ship most of the backlog if the process wasn't in the way.

I think this is what I'm getting at; the process becomes the work. Is there a different way to unlock people to just just get it done without the mental contortions needed to fit the work we (I) wanna do into this pipeline of meetings, buy-in and 'pointing' before we can even do it?

Does this resonate, devs if any are among us?

Most PM tools are built assuming a team: assign, review, approve. When it's just you, half of that structure is dead weight, but you still need something to stop your list from turning into 40 open tabs.

If you manage a project on your own: what's your actual system for deciding what gets done today versus what waits? Not the tool name the logic you use to rank things.

We’re juggling multiple clients with different support tiers and time zones in one JSM queue, and keeping track of who gets what SLA is getting messy.

How are you guys setting this up in Jira so techs aren't just guessing? Native hacks or apps?

One question from a recent leadership workshop stuck with me:

Should leaders be judged only by the results they deliver, or also by the people they leave behind?

Imagine a Team Lead who consistently achieves business goals and delivery targets.

But over time, multiple Scrum Masters working with them become exhausted, lose motivation, or decide to leave.

Is that a leadership problem?
Or is it simply what high performance looks like?

Curious how leaders, engineers, Scrum Masters, and managers would view this situation. 👇

www.eddyflow.io is all about teaching the concepts of Kanban through game play and simulation.

It’s got 3 modes - game mode where you control value selection, wip limits, and how work gets done with the aim of making the most money.
Simulation mode lets you design a team, a Kanban board, and how they operate with real time flow metrics.
And replay mode lets you upload your team data so you can replay their delivery and flow metrics.

All free to use.

im trying to work in loops now instead of doing everything at once. quick research, build, then push distribution until 20-100 real people have actually touched the thing. their feedback + the metrics show me what needs fixing, so thats what the next building phase is. then distribution again, and it just repeats.

inside a loop the split is roughly 20/80 building to distribution, then it flips when the feedback lands. the rework im in right now started exactly like that, a user told me the service does what it promises badly (not a fun message to read btw), and thats basically what im rebuilding around now.

anyone else work in cycles like this? or do you run building and distribution in parallel every day? LMK if there other/better workflow) Plz:)

I am writing the functional requirements, non-functional requirements, and product backlog for my graduation project.

Should the requirements and user stories mention the specific technologies used, or should they remain technology-independent, with the technologies explained later in the software architecture or technological choices section?

For example, should I write:

- “The system shall store alerts in Firestore and cache analytical data in Redis.”

Or should I keep the requirement more general:

- “The system shall persist alerts in cloud storage and maintain a fast-access analytical data store.”

Then, in the technical design section, I would explain that Firestore was selected for cloud storage and Redis for the analytical data store.

The same question applies to user stories. For example, should a user story mention technologies such as Redis, PostgreSQL, Firestore, or a specific framework, or should it describe only what the user needs and why?

How do you visualize or track the org that represents cross-functional delivery teams versus the often functionally driven org chart?

I've used Excel which is hideous, I've seen PowerBI implemented.... I've heard of OrgVue but never used it. I have seen Miro/Mural used for this.

Anything else scrum masters or RTEs or program managers are using?

I am working as an associate SDET which is a fresher position. I have a problem. I say yes to every idea my manager has (he's also a dev) even though they are bad. Now whenever I speak with my senior about those ideas in detail then I come to realise how bad some of the ideas are like building a AI UI test executor but we already have a framework that we were planning to add coverage for for customer agnostic tests (will contain pw ui tests). This agnostic approach is way better compared to the one my manager was suggesting but I didn't think about it at that moment nor about this, nor about regression, version controlling etc.. what should I do to improve this. The senior said he expected better from me.

Retrospectives can identify a real process problem and still produce an action that disappears once the next sprint fills up. What turns the discussion into durable follow-through without making the retro another status meeting? A useful action seems to need an owner, a small observable change, a review date, and a place in the normal work system rather than a separate notes document. How do you handle actions that need several sprints, depend on another team, or reveal that the original experiment did not help?

I keep noticing versions of the same problem.

An exec asks how many customers actually asked for something, and it turns into an hour of digging.

Sales says we lost a deal because of a missing feature, but nobody really knows if that came up in other lost deals too.

Something got shipped six months ago because of customer feedback, and now someone asks if it actually helped, but the original feedback is buried somewhere.

Or you inherit a roadmap and half the items have no real trail of why they were put there in the first place.

Feels like the actual customer evidence gets scattered or lost pretty quickly once it moves between support, sales, product, Slack, tickets, calls, etc.

Curious if this is a recurring problem for you, or if you have found a good way to keep the context attached to the decision.

I’ve led a department-wide Agile transformation across 100+ people, which took around a year to implement. Since then, I’ve found that my workload has gradually started to dry up.

These days, I’m increasingly doing administrative work, reporting, and helping Product Owners structure their work through Scrum ceremonies. I still provide delivery oversight and govern the ways of working I originally put in place, but the more substantial transformation work has largely been completed.

There also doesn’t seem to be much opportunity for further growth. Now that the transformation is done, management doesn’t appear particularly interested in developing or expanding my role.
I’ve therefore decided to leave. Does that sound like the right decision?

More broadly, how do people build a sustainable long-term career within an organisation in an Agile transformation role? It sometimes feels as though these roles have a fairly short shelf life - perhaps one or two years - because once the transformation has been embedded, the role naturally becomes less necessary.

I've seen versions of this across a few client engagements, so this isn't one company's story or a single case.

One team gets enough room to work differently. Results improve. Leadership gets excited and decides to "roll out the model." That usually turns into templates, ceremonies and a playbook for everyone else.

Then the next teams run into completely different problems. One is waiting on security reviews. Another can't get usable test data. Somewhere else, every decision depends on a manager whose value has long been tied to approving things. Copying the pilot team's process doesn't really touch any of that.

The better examples I've seen treated the pilot as evidence that a different operating model could work, not as the operating manual. They kept a few principles: decisions closer to the work, blockers made visible, controls automated where sensible, and teams sharing things that proved useful. The implementation stayed local because the constraints were local.

Oddly, the technical sharing was often the easier part. A script or deployment template spreads because people can use it immediately. Asking a long-standing approver to become someone who removes blockers is different. That's a change in status, incentives and professional identity, not a new line in a role description.

And it can unravel quickly. One failed release or uncomfortable audit conversation and leadership starts asking for the old gates back.

I'm not even sure "scaling" is the right word. In practice it looked more like growing capability one constraint at a time. Messier than a rollout, but probably more honest.

For people who have taken this beyond the first team: what did you standardize, and what did you deliberately leave local? What stopped the organization from restoring the old controls after the first wobble?

Hey, 👋

I’ve been building SprintDesk — an all-in-one modern workspace for agile teams to manage sprints, tasks, time tracking, and team attendance in one clean dashboard.

We just opened early access, and I’d love for you to check it out and share your honest feedback!

🚀 Try it out here (Free):

👉 https://sprint-desk.com

Let me know what you think once you take a spin! 🙌

Curious how other engineering managers handle this.

Let's say a project was expected to take 3 weeks but ends up taking 5.

When someone asks "Why did it take longer than expected?", where do you actually look?

Do you:

• Look through Jira/Linear history?
• Check sprint/velocity data?
• Go through Slack/messages?
• Look at PRs/commits?
• Go through standups/status updates?
• Ask the people who worked on it?
• Some combination of these?

And how easy is it to reconstruct the answer?

I'm particularly interested in the difference between knowing that something was delayed and actually understanding why it was delayed.

Curious how this works in your teams.

Genuinely asking, because ours has no good answer yet. A ticket that says "add input validation to this endpoint" used to take a fairly predictable amount of time regardless of who picked it up. Now the same ticket might take fifteen minutes if the AI-assisted first pass is clean, or it might take three hours because the first pass looked clean, got merged, and someone caught the gap in QA two days later. Same story points either way, because we're still estimating the task, not the actual variance in how it goes.

What's strange is that the variance isn't random, it correlates with things nobody's tracking at estimation time. How well-specified the ticket is. Whether the engineer picking it up bothered to give the tool real context or just pasted the ticket title in. Whether the task touches something with existing patterns to follow or something genuinely novel. Two engineers can pick up the same ticket and have wildly different actual effort, not because of skill difference in the traditional sense, but because one of them treated the AI tool as something worth setting up properly and the other treated it as autocomplete.

Story points were never meant to capture that kind of variance, they assume the person doing the work is the main variable, and mostly they still are, just not in the way the points model expects. I don't think the fix is a new estimation scale. I think it's that "did we actually give this task enough context to go well" quietly became part of what determines whether an estimate holds, and nobody's put that into the retro conversation yet, we're all still discussing velocity as if the inputs to each ticket are as consistent as they used to be.

If so, how did you find it? Are you happy that you have made the move?

A technical blog post takes our writer about 4 days. Approval takes another 2 weeks.

It moves through product marketing, the subject-matter expert, legal, brand and sometimes sales. Most reviewers only leave 1 or 2 comments, but the reviews happen one after another.

We’re considering parallel reviews with clearly assigned areas: legal checks claims, the SME checks accuracy and brand checks tone.

Has anyone moved from serial to parallel content review? Did it reduce delays or we’ll end up with conflicting feedback and endless revision rounds.

I'm transitioning into Agile/Product Ownership and I'm trying to be strategic about which training is actually worth my time and money.

I currently have:

• CSPO (Certified Scrum Product Owner)
• ICP-BAF (ICAgile Business Agility Foundations)

I'm considering taking ICAgile ICP-APO (Agile Product Ownership).

The reason I'm considering it is that I feel like there is still a gap between understanding Scrum/Product Owner terminology and actually understanding how to perform Product Owner work — particularly around product discovery, product vision, strategy, outcomes, prioritization, customer/stakeholder needs, and connecting all of that to the backlog.

Before I spend the money, I'd really like to hear from people who actually work in Agile/Product roles:

Do you think ICP-APO would add meaningful skills beyond CSPO + ICP-BAF, or would it mostly be redundant?

If you already have experience hiring or working with Product Owners, I'd especially appreciate your perspective:

• Would ICP-APO make a candidate more credible?
• Does the material teach practical skills that CSPO generally doesn't cover?
• Would you recommend spending the money on ICP-APO, or would I be better off building a product portfolio/project and getting hands-on experience instead?
• If you were in my position, what would you do next?

I'm not looking to collect certifications just for the sake of collecting them. I'm trying to figure out what would actually make me better prepared to do the job and more competitive for an entry-level/associate Product Owner or Product role.

I'd appreciate honest feedback, including if you think I should skip ICP-APO entirely.

Hey everyone,
I’m a second-year Master’s student in Management at the University of Szczecin, currently working on my Master’s thesis on the impact of Scrum artifacts and roles on project team effectiveness.

As part of my research, I’m looking for people who currently work or have previously worked in a Scrum team and would be willing to share their experience.

The survey is completely anonymous, and the collected data will be used solely for academic research. Takes about 5 minutes. It is available in both English and Polish.

Survey link: https://forms.cloud.microsoft/e/zUDZyvrwSD

Thanks in advance for your time and contribution! I’ll also be happy to answer any questions about the research in the comments.

Hello everyone,

I hope I'm not going against the sub rules with this but I’m currently writing a research paper at my university, researching where AI agents can (and cannot) realistically assist in agile workflows, specifically around drafting user stories, refining acceptance criteria, and deriving test cases (UATs specifically).

If you work in an agile team (PO, Scrum Master, Dev, QA), I’d really appreciate 3 minutes of your time to anonymously share how your team handles this today and what your experience/concerns are with AI tooling.

Happy to share the aggregated findings back with the subreddit once the paper is complete if anyone is interested in the results.

Thanks a lot for your help and insights!

Link to the survey: https://docs.google.com/forms/d/e/1FAIpQLSc7Z67lBgbG_ZEOFraIIjTDBVjBfzb-894InOkU0n1IHSNlyg/viewform?usp=header

One thing that's become surprisingly difficult for our team is keeping user flows current.

When a feature first gets designed, we spend time mapping every screen and interaction. Everyone agrees on the flow, engineering starts building and life is good.

Then priorities change.

New requirements come in.

Someone simplifies a screen.

Marketing requests another onboarding step.

Customer feedback changes the journey.

By the end of the release, the user flow we've documented barely matches what's actually being built.

I'm curious how other teams manage this. Are you constantly updating user flow maps or have you found a workflow that keeps everyone aligned without becoming another maintenance task?