Our leadership is suddenly into DORA and wants us to improve deployment frequency and lead time. The problem is our process is bogged down with approvals and checks at every stage. We end up batching everything into these massive releases which makes things riskier. I get the theory but in practice I'm not sure what makes a difference without creating more work for us. Anyone been through this and improved their numbers?

Hey everyone,

I have been a scrum master for some years with 13 years of experience in total. I call myself as sr scrum master.

I have been victim of politics where the client had pushed back when my team has asked tons of questions related to application, cloud infra which wasnt under our scope. Our team was brand new and these were legacy products. Our team got ramped down due to asking "too many" questions and they expected us to know everything. I have worked in team where even pointing out the story pointing is not done right or asking why comments arent present is something they didnt encourage. I once asked a senior why he isnt joining the meetings. I got dialed in on team with threatening tone since I had pinged in the group about him not joining leaving him exposed.

Fast forward to now. Am helping a team implement scrum now this team is not vocal except one member who pushes back on what I say saying this is not the way he,she did in last organization. This person is new to org.

Conversations like having product backlog refinement, slicing the stories, challenging if description isn't clear, telling we should be categorizing work in epics that can be closed every 3 months, doing story pointing per complexity is something they dont understand easily and sometime I have been told they dont care about and tell me straight away they dont care how i decide to do. I thought of building norms with team and i got no response back and had pointers to refer to from my last teams to start the conversation and the response was I shouldnt be writing them without consulting them ehicj i agree but the purpose of meeting was that itself and I had shared the page with a resource weeks back via chat. This same person didnt share the feedback with me on chat and decided to say it in the call that I should not bring these pointers to enforce it. My purpose was to discuss, get consensus and not enforce. I cleared it in agenda.

Note this person is the only one vocal and built out the whole backlog using AI and team vision which I appreciate but neither I or PO was involved during creation. This person is unprofessional in responding to conversations related to scrum. This person also brought all the pain points about unclear backlog, roadmap and priorities in 1st ever retro I had. It was all valid but I felt this person is criticizing and blaming. I mean that was our 1st sprint, backlog refinement and setting product goals arent a game of 1 day.

The manager is thinking scrum isn't working due to tough convos and team being silent but I feel product owner has to step up in owning backlog and avoid letting someone else hijack it. The knowledge of backlog isnt decentralized and only one or 2 people know about the stories created. I know PO should prioritize, story point with devs, and write them but in my org everything is done by SM along with coaching and enforcing scrum ceremonies and discussions, removing blockers.

How do I handle this team ? What should I do as SM ? Let me know what wrong am doing. Many Thanks for reading it and giving time.

Edit: I suspect this vocal person is either not enough experienced or playing politics. Manager has not any strong opinion on this person but I do have that this person isn't helping the team implement scrum.

The team wants lot of flexibility in terms of closing stories, pulling stories whenever they want because they dont know what's gonna come next and when, they may come to know what all they planned for in sprint isnt even right because its ever changing due to experimentation nature of project. We arent building user product. We are building support service that will support product teams.

This team had difficulty when I asked the team to update comments frequently (not daily) and faced push back. I never told anyone to update comment since then.

Hi!
I’m conducting an anonymous survey for my bachelor’s thesis on communication in multicultural project teams. It takes around 8–10 minutes.

I would be very grateful if you could complete the survey or share it with someone who fits the criteria.
https://forms.gle/vRbbCudhSe8rhqDE6

Thank you for your help!

The uncomfortable answer is that updating the tool is probably no one's actual job. It's everyone's implied job, which means it loses to real work every single day, and honestly it should.

What worked for shops I've been in: stop asking everyone to keep everything current. Name one person whose job is a 15-minute weekly pass asking "what on this board is no longer true?" They don't update everything themselves. They just flag what's stale and chase down the truth on the few things that matter.

The team usually stops hating the tool once it stops being a chore everyone shares and starts being one person's short, defined task.

One thing worth checking before you change anything though: is it that they don't update it, or that they update it and nothing ever comes of the updates? Different problems. The first one is the fix above. The second one means the updates go into a void, and people quit updating tools no one reads. That one gets fixed by you, not them.

I’ve reached a bit of a career crossroads and would love to hear from people who’ve worked in both Delivery and Product.

I’ve spent much of my career in delivery and programme roles, helping teams plan, prioritise and deliver products.

Over the years, though, I’ve noticed that while delivery plays a huge role in successful outcomes, Product Managers often receive more visibility, recognition and career progression.

Many I’ve worked with have gone on to become Heads of Product or Product Directors, while delivery career paths seem much narrower.

Outside of work, I’ve recently built and launched a couple of AI-assisted mobile apps. I found I genuinely enjoyed identifying user problems, prioritising features, iterating based on feedback and deciding what to build. It made me realise I may enjoy product management more than delivery.

For those who’ve made the switch:

Was it the right move?

Is Product genuinely a better long-term career, or am I seeing it through rose-tinted glasses?

Has a delivery background helped you as a Product Manager?

I’d really appreciate hearing from people who’ve experienced both sides.

I've inherited a product team that apparently never deletes anything. There are boards from projects that finished years ago, old sprint plans, duplicate roadmaps and workshop notes that nobody has looked at since they were created.

I'm trying to clean things up but I'm also wondering whether this is just the natural lifecycle of every collaborative whiteboard. Has anyone found a solution that scales well as teams grow?

When I started preparing for the PMP exam, I made the mistake of collecting too many study resources. I spent more time deciding what to study than actually studying.

What worked much better was following a simple plan: understand the PMP Exam Content Outline first, study one domain at a time, practice questions every week and review the explanations behind both correct and incorrect answers. That approach helped me identify weak areas much earlier.

Another lesson was not to rely on memorization alone. The exam is designed to test how you apply project management principles in realistic situations, so working through scenario-based questions is far more useful than trying to remember definitions.

If you'd like to read it, it's here: https://www.snsccs.com/blogs/how-to-prepare-for-pmp-exam.

Everyone's study style is different, but having a consistent plan made a much bigger difference for me than constantly switching between resources.

been in agile long enough to feel weird about what's happening right now, curious if others are seeing it too.

scrum masters and coaches are getting cut everywhere and the easy explanation is AI took the job. but i don't buy that. AI isn't doing anything a good scrum master does. what it's automating is the stuff a lot of us got away with treating AS the job: running standups, nagging people to update tickets, pulling velocity charts, scheduling ceremonies. if that was 80% of your week, you were always going to be exposed eventually.

that's the uncomfortable part. i think this role got commoditized because we let it become process admin. two day cert, learn the ceremony script, keep the board tidy. companies looked at that and went why are we paying a salary for a meeting organizer and honestly that's hard to argue with once the role shrinks to that.

the actually valuable version is spotting when a team is quietly dysfunctional and naming it, mediating the conflict nobody wants to touch, building enough safety that people give you the real status instead of the safe one, untangling dependencies before they blow up, none of that is going anywhere and AI can't touch it. but that stuff never showed up neatly on a board, so it was always the easiest to overlook and hardest to defend at budget time.

so my honest take: agile isn't dying, but the ceremony runner version of the role is and maybe that's not entirely a bad thing even if it's brutal for the people living it. where does this group land? are you seeing the cuts too? genuinely AI or companies deciding they got what they wanted and dropping the change agents?

My company has grown a lot over the past year and while that's obviously a good problem to have it's exposed some weaknesses in how we plan work.

A typical sprint now involves product managers, developers, designers, QA, marketing and sometimes even customer success. Everyone has their own priorities and somehow we're expected to keep everything aligned.

The biggest issue isn't planning the sprint itself it's everything that happens before and after. Feature discussions happen in Slack, requirements live in Confluence, roadmaps are in another tool, someone sketches ideas during a meeting and then a week later nobody remembers where the final decision was made.

I'm starting to think we need a platform that combines planning with visual collaboration instead of relying on six different tools.

For teams running Agile at scale what are you using on your everyday work?

The mock exams for Agile Practitioner at The Knowledge Academy do not resemble the Practitioner exam at all. Like completely off when it comes to the purpose and format of the Practitioner exam. They are more tailered for the Foundation exam. The training course has too much repetition from the Foundation course and little novely. The only useful materials they provide are the Sampler 1 and Sampler 2 quizzes (100 questions in total) that follow the format of questions of the real Practitioner exam but are just in pdf format.

How do you guys successfully transitioned from Business Analyst to Product Owner.

Please share, I'm coming from a non-agile background.

Thank you!

Every "is SAFe good/bad" argument misses why it's actually everywhere. It's not delivery. SAFe is the only framework engineered to be sold.

The certification renews — $295 a year, every year. Twenty-plus certification tracks. Around two million people hold one. In 2021 a private equity firm paid ~$300M for the company behind it. You don't pay $300M for a training methodology. You pay it for a renewing revenue stream with two million people already locked in.

On the ground it produces PI planning: two days a quarter where a 50–125 person train stops delivering to plan ten weeks in a room full of sticky notes. Conservatively ~$800K/year in salaried time for a plan reality invalidates by week three. I've sat in those rooms. The plan isn't the point. The ceremony is.

Execs buy it because it's legible — a named, defensible thing to point at in a board deck. "We cut cross-team dependencies through better architecture" has no certification track, no colored diagram, no consultant who flies in to run it. Nobody gets fired for buying SAFe. That's the whole product.

The tell it was never about delivery: State of Agile has ~74% of orgs on hybrid/homegrown, ~63% saying they struggle to ship reliably. Disciplined Agile lost nearly half its adoption after PMI bought it — the moment it became a thing to sell, the practitioners left. Sutherland, who co-created Scrum, puts the failure rate at 65%. Those are the numbers of something that sells, not something that works.

Not saying don't use it. Saying stop asking whether SAFe works and start asking who it works for. Then follow the money.

Hey,

I'm a new PM/manager (came from a software engineering background, but I've also built and managed products in the past, some of them even my own). I joined this agency to take over a project that is now in week 9 of 16.

The team is small: 1 Tech Lead, 3 devs (1 senior, 2 mids), 1 QA and me as PM. We all work remotely. The situation is classic: messy project handover from the previous agency. Our job is to either fix the existing system or rewrite it to cover the client's critical use cases and hopefully earn a project extension.

The Tech Lead (working 5-10 hours/week on this project) and the senior dev joined first, about two weeks before everyone else. They came as a package from previous projects and they have tenure in this agency. I joined on week 3 and needed about two weeks to properly onboard, so you could say they drove the project for roughly the first four weeks.

The results were poor. The project I inherited was a collection of AI-generated Github Issues spread across multiple GitHub repos, with work happening mainly on low-value priorities while critical issues were either not clear or ignored. Tech Lead/Senior Dev aren't capable of managing other devs, all they can do is review some code and say a sentence or two in the daily standup, that's it. It's up to me to make sure devs are working on what they should be working, it's up to me to double check code scope with task scope, it's up to me to even track dev hours to make sure they are not billing for nothing (we had an issue in the past where 1 dev was billing like 2x the amount of hours he actually worked). We also didn't migrate from the previous agency's infrastructure until around week 5, which meant we couldn't even identify the real bottlenecks until then. Real development only started after I've onboarded and started pushing very hard for proper project and testing tools.

For the last 5 weeks I've been trying to get the project under control. I set up a proper Jira project, established daily team sync meetings, started running structured client meetings, managed the team and even bought out of my own pocket and personally delivered hardware just to unblock devs instead of waiting for delivery from the client overseas. Since then, delivery has noticeably improved.

The biggest challenge hasn't been the project itself. It's the leadership dynamic.

My expectation when I joined were simple. As a PM I expected to be able to decide what we build and when, while technical leadership advises me on how to implement it. Instead, I constantly feel like I'm fighting for ownership of the project. The two mid developers and QA have no issues with my structure. The problems are with the Tech Lead and the Senior developer.

1. Processes aren't being followed.

The senior dev (who for the record has very poor soft skills) regularly starts implementing "spike" tickets based on breadcrumbs from client meetings. Undocumented decisions end up being merged into production without acceptance criteria, documentation, or QA context. QA then asks me what they're supposed to test, and I end up reading code just to understand what changed. I also have no visibility on how much hours he's working as he logs these hours in the system only at the last day of the month, not daily how the rest of the team does it.

The Tech Lead (who is on this project only temporary and when he leaves the Senior Dev is supposed to become the new Tech Lead) spent weeks working on a UI redesign and last Friday decided that it's a good idea to demo it to the client before ever showing it to me or aligning on priorities. I have no visibility on what his goals and what he's working on.

2. Client communication is becoming messy.

I originally invited the Tech Lead and senior dev to client meetings because I wanted technical expertise in the room.

Instead, the now Tech Lead often dominates the first 30 minutes discussing long-term product/architectural vision or asking questions that should be asked on week 1 or week 2, not on week 9 of the project. It derails the meeting and makes it much harder to groom the work that actually matters right now. Tech Lead (who works maybe max 10 hours a week on this project) also feels that it's his place to decide on what are we commiting and what not, and feels like he's doing me some favours here, when in reality my decisions so far resulted in nothing but value for the client/project, while his decisions caused massive delays, in the beginning of the project.

3. Leadership isn't clear.

Basically it feels like I have all the responsibility but not the authority. I've tried bringing this up in our leadership chat groups with senior dev + tech lead but nothing is changing. I have experience driving much bigger projects successfuly and at this point having to deal with these two on such a small project is becomming surreal. They keep telling me that I'm the most responsible one here, but shouldn't freedom of decisions come with this as well?

I have over 400 hours on this project. The Tech Lead has around 80 max. I'm carrying the delivery responsibility, client communication, planning, prioritization, and day-to-day execution, but I'm still being second-guessed on decisions by someone whose contribution has mostly been a redesign proposal that won't even be used until if we don't get a project extension after 7 weeks. And the same Tech lead made very poor decisions initially, that basically are the root cause of us having to rush and having to do so much in such short time now.

Sometimes I feel like I don't know something here. Perhaps, the Tech Lead, since he has more tenure in this agency knows something I don't - perhaps contract that we signed was not for 3-4 months but for 6 or 12 and I'm just ramping everything here for no good reason. I don't know anymore.

Tomorrow I have a leadership sync meeting. My plan is to raise these issues and call for a separate meeting with the Tech Lead, CEO, and COO.

My proposal is to make Tech Lead and the Senior developer my direct reports and that all information should flow through me. I also want to have separate meetings with the client 1on1 so we could go through priority things, and move techlead's to a separate meeting.

We have 7 weeks left. We don't have time for competing leadership or same endless debates. Technical decisions remain theirs, but project direction should come from one person, who has most context, which happens to be me.

Am I looking at this the wrong way?

For those of you who've inherited struggling projects, how did you establish clear ownership when senior technical people resisted it?

I lead a team that delivers machine learning (ML) research for a large organisation (I will deliberately try and keep domain details sparse for obvious reasons).

For years, we have been given a statement of work for the year, but its largely been acknowledged that we're doing research and we'll be lead by the customer's actual demand and not follow the letter of the contract. We have followed XP by accident rather than by design, making a backlog of items we think we need, reviewing with the customer to decide on priorities, and it's been working really well.

We have caught the eye of bigger players in the organisation and are now being offered bigger contracts, but the drawback is that we're being asked to promise delivery of bigger things 'on time' so they can demonstrate value for money. I have pushed back, suggesting that we deliver in smaller chunks so they can see regular value coming in, rather than promise a big deliverable up front. This has been well received, but I'm ultimately going to have to communicate the small steps up through the customer in a way I haven't had to before.

The problem I have with this is that we're primarily focused on ML models, and I'm having trouble splitting up epics like "deliver X research to a specific TRL" into chunks that can be delivered regularly. My suspicion is that this kind of issue is not specific to ML at all, but all algorithmic work. However, I am finding it hard to learn how to do this well, because all the examples and tutorials are too far removed from my technical area.

My first thought is that I say that I can have user stories that deliver an ML model that can predict on a specific subclass of the problem to help certain users, or on a limited subset of the data, or in a way that fakes out some of the problem space to let us deliver in a limited way. Am I on the right track? Is there a better way to approach this?

I appreciate it may be hard to give concrete help because I'm hiding the problem domain, but any real-world examples will help me enormously.

Thanks in advance.

Edit: some great suggestions here. Thanks, everyone.

Raw upvoting rewards whoever has the biggest team, not the strongest idea structure scoring fixes most of it, fixed criteria about, feasibility, impact, effort, so a loud group can't just brigade their pet project the trick is keeping the scorecard light enough that evaluators actually fill it in, if it takes twenty minutes per idea it just doesn't happen so the balance is structure without friction.

Every planning poker tool I tried before this had the same two problems.

1. The site was littered with Amazon ads
2. Boring as hell

Either it was locked behind a paywall for basic stuff like voting history or custom card decks, or it was free but plastered in ads that made the whole session feel cheap and distracting mid meeting.

Neither felt right for something this simple.

Funny enough, I didn't actually build this one originally. It started as my ex co-founder's side project that was absorbed into our work, and I ended up taking it on and running with it.

Since then I've kept it lean and free, no paywalls, no ads, no upsells. As to solve the two issues at the top.

It is dead easy to use. Create a room, share the code, vote, reveal, done. No sign up needed to join a session.

It's called Scrum Planning (dot com) if you want to look it up.

Just crossed 100+ weekl teams using it and wanted to share the story rather than just drop a link. Curious what other teams use for estimation and whether you've run into the same pay to vote nonsense I did.

Agile already knows the loop — apply it to meaning, not only code

Agile’s useful habit is not “move fast.” It is closed loops: try something, get evidence, adjust the plan, keep the system coherent. Most teams apply that to backlog and code. Fewer apply it to the words that make the backlog speakable, or to the written intent that is supposed to stay true when the code teaches something new.

That is the pitch: treat shared language, frozen intent, change analysis, and elevation-after-discovery as one feedback system — not a waterfall of documents.

The loop (in agile terms)

Four pieces, one cycle:

1. Shared language — a living product dictionary (ubiquitous language made explicit): preferred terms, demoted synonyms, naming bridges across UI / config / CLI / tests / code. No algorithms here — only names that later feed acceptance criteria. Authoritative for the increment; provisional when evidence shows the words are wrong.
2. TIED — freeze intent as a linked stack: requirements (what must remain true), architecture decisions (structural how / boundaries), implementation design as step-wise pseudo-code (operational how), then tests and code. Traceability so you can walk obligation → structure → steps → proof. Any team can do this with lightweight docs; the acronym is optional.
3. CITDP — structured change analysis before coding the next cut: current vs desired behavior, non-goals, blast radius, risks, test plan. The inspect-and-adapt step for “what are we actually changing?” so you do not invent scope in the PR.
4. LEAP — when tests or code disagree with the written stack, elevate truth back through the same chain (implementation design → architecture → requirements) in the same work item, and refresh shared language when the concept changed. Delivery evidence updates the plan; the plan does not silently rot while source becomes the only ground truth.

The shared dictionary is one input to that loop — not the star of the show. Without it, requirements argue in false synonyms. Without TIED, language never becomes a testable obligation. Without CITDP, the next increment guesses blast radius. Without LEAP, the first surprising test result orphans the docs.

Two bad extremes (language edition)

One bad answer: “Let everyone use their own words; meaning will emerge in conversation.”

False consensus. Two people say “command,” one means open-a-file, another means run-a-process, a third means capture-stdout-at-snapshot. Agreement lasts until implementation splits three ways.

The other bad answer: “Define the glossary once and enforce it forever.”

Fossilized bias. Sponsor language hid two user jobs; the old architecture shaped the nouns; enforcement without revision freezes the first author’s framing into the contract.

The agile answer is the same as for code: make the choice explicit, use it for the increment, test it against reality, revise through the loop.

What each stage feeds back

• Requirements — Can this term express a testable obligation? Paragraphs of exceptions around one word usually mean the word hides multiple concepts.
• Architecture — Does one term cover two modules, owners, or lifecycle states?
• Implementation design — Step-wise pseudo-code forces actions, states, order, inputs, outputs. Prose that felt fine often fails at named branches.
• Tests — Same term, different tests → meaning was never shared.
• Code — Adapters, comment-crutches, and qualifier-stuffed names are naming friction signals.
• Review and use — Users bounce off team jargon; avoided synonyms sometimes name a real distinction.

None of those layers automatically define product meaning. They supply evidence. Humans still decide; the loop makes the decision visible and propagates it on purpose.

How the cycle stays coherent (not chaotic)

Intake (CITDP + language): Resolve sponsor words against current preferred terms; flag unclear mappings; write the change analysis before inventing behavior in chat or source.

During the increment (TIED): Prefer terms in acceptance criteria and named design steps; record new concepts and naming bridges while the reason they differ is still remembered.

When mismatch appears (LEAP): Propagate changed meaning through requirements, architecture, impl design, tests, code. If tests/code found it first, elevate in reverse order. Update the dictionary when the concept itself moved — not every time a symbol is renamed for taste.

Before done: Same concept, same name, everywhere the contract depends on it. Keep old words as avoided/legacy with an explicit replacement — search and migration matter.

Bias is inspectable design input

Every prescribed vocabulary carries bias: sponsor authority, incumbent architecture, legacy code, UI metaphor, platform jargon, whoever wrote the first glossary. Pretending otherwise only hides the force.

Make the framing an artifact the team can review: Whose distinction is this? What did it exclude? Does implemented behavior still justify it? User concept, implementation accident, or org habit?

That is the agile interest. Inspect and adapt applies to meaning, intent, and change analysis — not only to velocity charts. Freeze long enough to coordinate. Reopen when evidence changes what the words (and the obligations) should mean.

I don’t have strong product background. I’ve mainly been in enablement roles. I am considering taking on a scrum master position as a stepping stone into a product role. Would you be able to get good domain experience as a scrum master and also how difficult to make that transition to product role? I do not have a technical background

So, I (senior SWE) had a meeting with our CTO today (small corp, cca 200 heads in my COE). He was trying to understand how we are benefiting from using AI.

I can very simply explain how do I - manually working guy, benefiting from AI and that im 3-5x. I can show him my teams velocity and explain that we have lost 3 FTEs 6 months ago and our velocity is stable or positive and our predictability is robust. But 1. - he cares about higher levels than person or team and 2. - this just opens very simple counter - so why the fuck we don't earn more money?

Problem is obviously complex, in my teams reality, testing is now out bottleneck, but if Business Unit wont sell more (of our fantastic, packed with features product), its hard to find a correlation and calculate ROI in traditional terms.

So I just said I don't fucking know and I'll get back to him, so I got back home, vibed a research with Claude and I know nothing more.

How are you guys in your companies approaching this? Any good ideas on how to measure impact of AI on center level? Whatever good comments / insights, please?

I’ve noticed an uptick of job postings of companies practicing SAFe and looking for scrum masters with scaled experience. Do you see companies moving away from SAFe or moving towards it?

I'm considering getting the PSPO I certification and wanted to hear from people who've actually gone through it. Does it help with job applications or interviews, or is it more of a "nice to have" once you're already in a Product Owner-type role?

Any experiences or advice appreciated — thanks in advance!

Hi everyone!

I'm planning to take the PSK I (Professional Scrum with Kanban I) certification from Scrum.org, and I'd appreciate your advice.

Besides the study materials available on the Scrum.org website, are there any other resources you would recommend?

I'd also like to know:

- How difficult is the exam?

- Is it proctored or recorded?

- Is it generally considered easy to pass if you've prepared well?

- Do you have any tips or lessons learned that could help me prepare?

I'd really appreciate any recommendations or experiences you can share. Thank you!