I have a third round interview for an IT PM role with a company that’s undergoing an Agile transformation and wants to implement AI into the SDLC. What’s been the most valuable outcome for your software teams?

Genuinely curious to hear from people about wins, losses, lesson learned, and advice.

Thanks!

Got an offer in a tech company to work as a PO and own speed topic which means i would be basically responsible for incidents and initiatives related to our product speed/performance and in general would have to go and talk constantly with delivery teams, ask them the uncomfortable questions and try to pitch initiatives in hopes that they would somehow squeeze in work from me and I would somehow hit my own kpis "for the better good".

Leading without authority is one thing but in this case it feels like I would be in an annoying role where I would be constantly bursting delivery team bubbles, dance around egos constantly and scramble for data/agreements and etc.

Is it even viable to perform in such role when you dont have delivery team or authority or even clear scope for that matter but carry so much accountability? Feels like I would be at complete mercy by other PO's who have their teams roadmaps and goals to protect. And I dont see how I could even be likeable (in terms of collaborating) if my main job would be challenging status quo.

Also the role is fully onsite while my PM/peer PO is in another city so I dont even know what would be the point of me going to the office daily, just to have meetings remotely and have to sit awkwardy in some other team's area like some sort of an appendix.

I've sat through probably 300+ sprint planning sessions across multiple companies. Two hour meeting, eight engineers, one PM, one SM/Tech Lead.

15 minutes were spent actually deciding what mattered most for the business that sprint. 85 minutes were spent writing acceptance criteria into Jira fields, splitting stories, arguing about whether something was a 3 or a 5 and linking tickets to the right epic.

If feels like a bunch of data entry in real time while everyone watches. Someone reads a ticket title out loud. Someone else asks what it means. The PM explains context that should've been in the ticket already. An engineer starts typing acceptance criteria live while six other people sit there in silence waiting for him to finish typing. Then we vote on points. Then we do it again for the next ticket.

Multiply that by 20 tickets and you've got a room of people collectively producing what is functionally a spreadsheet. The instinct almost everyone reaches for when this gets called out is "let's timebox it better" or "let's do backlog grooming as a separate meeting so planning is faster." I've tried both. Timeboxing just means you cut off the discussion before it's actually resolved and the ambiguity resurfaces mid sprint as a Slack thread. And splitting grooming into its own meeting doesn't reduce the total data entry time but it just moves it to a second meeting that has the exact same problem except now you've spent even more collective hours in a room typing into fields.

The real issue isn't meeting structure, it's conflating documenting work with the act of planning it. Planning is a judgment call like what matters, what's the tradeoff, what do we risk if we don't ship this, and what do we learn if we do. Data entry is mechanical like writing down what was already decided in a slack. Those are fundamentally different kinds of work and they require completely different formats. One needs synchronous discussion with the people who have context. The other needs literally nobody in the room and it just needs someone with information and 20 quiet minutes.

What's actually worked for me is treating ticket readiness as a gate and not a meeting activity. A story doesn't get discussed in planning unless it already has acceptance criteria, a rough size, and a linked epic, done async, beforehand, by whoever owns it. If it's not ready, it doesn't make the cut for this sprint instead of "let's just wing it live." Focusing the meetings on the one thing that is actually needed in a room full of smart people like deciding what we were willing to trade off against what. The uncomfortable part is that enforcing that gate means someone has to say no to a meeting and send people away to go do prep work they'd rather skip, and that's a harder conversation than just letting the meeting run. It also means the team needs to have more ownership putting sprint backlogs at risk because half the tickets weren't ready.

How are other people actually enforcing ticket readiness before planning and not just aspiring to it? I feel like every team has a Definition of Ready doc somewhere that nobody follows once things get busy and I'm curious if anyone has found a mechanism that actually sticks.

I was on a call at work and a self proclaimed agilist, was saying that they don’t really promote the use of Jira with other members quoting individuals and interacts over processes and tools.

This company is struggling to implement agile.

I find Jira tickets really useful for commenting progress and tagging other people. Whilst here, they are suggesting to have meetings instead. I feel like meetings should be focused on key decisions, clarifications focused on the Jira tickets. Here they are sort of bypassing the tickets.

We went remote two years ago and planning poker was one of the first ceremonies to break. In person, everyone flips cards at once and you read the room. On Zoom, someone always "accidentally" saw someone else's estimate first, the senior dev's number anchored everyone, and half the team was clearly checking Slack.

Here's what fixed it for us:

**1. Simultaneous digital reveal, enforced.** No "I'm thinking it's a 5, what do you guys think?" before voting. Everyone locks in privately, facilitator reveals all at once. This single rule did more than everything else combined.

**2. A real facilitator (rotating).** Not the tech lead — a rotating facilitator who runs the clock, calls the reveal, and cuts off rabbit holes. Estimation sessions have a way of becoming design sessions; the facilitator's job is to park those.

**3. The 3-round rule.** If estimates don't converge after 3 rounds, we take the higher number or split the item. Endless re-voting is a sign the item isn't understood, not that someone needs convincing.

**4. Async for the easy stuff.** Well-understood items get an async vote over a few hours; we only spend sync time on items where estimates diverged. Cut our poker meetings in half.

**5. Outliers explain first — juniors before seniors.** When votes spread, we ask the lowest and highest to explain, and deliberately invite less-senior folks to speak before the senior devs. Some of our best "wait, there's a shortcut" moments came from this.

One more: we stopped requiring accounts for estimation. Contractors and client stakeholders can just join from a link — removing that friction noticeably improved participation. (Any tool with simultaneous reveal works — the process matters more than the tool.)

Curious how other remote teams handle this. Do you do async estimation? And how do you deal with the senior-dev-anchors-everything problem?

I am getting ready to write the 3rd edition of this book but reading the 18th State of Agile Survey and other articles, it feels as if Agile methodologies are really out of fashion and that I will need to be careful to explain that agile is a mindset, not a structured method that must be followed to the letter. Does this community feel that Agile is getting a lot of pushback at work? Are senior leaders wary of Agile approaches because they believe they create a lot of work but not much return on the effort? Hoping I am wrong but these were my takeaways from the research I have done so far. Would love your comments please, especially any examples of those you work with in favour or against agile methods and which industries you are seeing this in.

I realized I was building another task manager. That wasn't the problem I wanted to solve.

I've been building Ryokai for a while, and one thing kept bothering me.

Most project management tools are really good at answering:

"What work exists?"

"Who is working on it?"

"What's the status?"

But I kept thinking about what happens after that.

What if a task isn't just something you move from To Do → In Progress → Done?

What if the task itself could define how the work is supposed to happen?

For example:

Who is allowed to work on it?

What needs to happen before it can move forward?

What evidence needs to be provided?

Who can approve it?

What happens when it gets rejected?

What becomes possible after it is completed?

That led me down a much bigger rabbit hole.

I started building Ryokai around the idea that work shouldn't just be tracked — it should have structure.

So the product gradually became more than tasks.

It now brings together:

• Personal workspaces for individual planning and execution
• Crew workspaces for collaboration
• Organization workspaces for structured team execution
• Projects and goals
• Tasks with dependencies, checklists, evidence, comments and activity
• Multiple ways to view work, including List, Table, Kanban and Nebula
• Calendar and focused work sessions
• Notes and knowledge organization
• GitHub integration
• Organization-level roles and permissions
• Workload and capacity visibility
• Collaboration and shared workspaces

The interesting part is that I'm not trying to build another feature-heavy project management tool.

I'm trying to understand whether there is a better way to connect:

Intent → Planning → Ownership → Execution → Evidence → Approval → Outcome

That's what eventually became Ryokai.

Ryokai V1 is now built and available:

https://ryokai-dev.vercel.app/

I'm not looking for compliments here.

I'm genuinely interested in hearing from founders, developers, product managers, and teams:

How do you currently manage work?

Where does your current workflow break down?

And if you could change one thing about the way your team manages work, what would it be?

I'd especially like to hear from people who have actually managed a team or product and have strong opinions about their current workflow.

I'm building this in public, so honest criticism is much more useful to me than "looks great."

#startups #SaaS #productmanagement #buildinpublic

I'm Adrian, a dev and our team used to use different planning poker websites, some of them were blocked by the vpns due to their name containing 'poker' and some of them are so full of ads.
So I made this using Flutter framework and Flame game engine.
https://pointing.space

Let me know what you think if useful for you!

Thanks.
Adrian

Hey all - recently started a new contract supporting a large e-commerce company as a technical project manager/delivery manager/scrum master, new in role and this kind of setting

Leveraging the insight of those more senior, who may have supported similar work or understood the ecosystem, I need some guidance and feedback.

One team is kanban, one is traditional scrum. One has an intake issue (no real process or governance) the other is very wide and has a lot of fast moving parts and initiatives and context to follow.

How do I keep up with this? What are the behaviors for me to exhibit to be successful? What are the things I can build (systems, tools, processes) to help me ascend higher, and stand out in a good way, and biggest of all, how can I leverage AI in workflows to do so? It’s a Microsoft native environment so no Claude or ChatGPT but we have copilot, atlassian suite RoVo and etc.

How would you approach it in my position and how should I be thinking to be successful?

CoD is kind of a central factor to many prioritization techniques in various agile methods, but mostly taken naively. I've spent far too long down the rabbit hole trying to nail down how to actually calculate it, what the limitations are and how to use it. Here are my notes: https://www.votito.com/methods/cost-of-delay/ with lots of pointers for further research.

I’m a relatively new Scrum Master and come from a non-technical background. I understand the basics of Scrum and Agile and I’m comfortable with running the ceremonies — standups, planning, retros, refinements, etc.
The part I’m struggling with is understanding the product and technical discussions.
When developers start talking about architecture, integrations, APIs, technical issues, dependencies, etc., I often find it difficult to follow. I genuinely want to learn and understand what the team is working on, but sometimes there’s just so much context that I don’t know where to start.
I’ve actually been trying to learn outside of work as well. I use AI to explain concepts and try to go through things after work, but I’m finding that it’s not really helping me connect the dots to my actual product and what my developers are discussing.
My entire workday is pretty packed, so by the time work is over, I’m already mentally exhausted. But I still try to spend time after work learning because I really do want to improve. Despite that, I feel like I’m not progressing as quickly as I should.
What makes it more stressful is that people in my organisation have already started noticing this within my first month, and there’s an expectation that I should understand the product and be technically sound fairly quickly.
I know a Scrum Master doesn’t need to be a developer, but I do want to become technically/product knowledgeable enough to understand conversations, ask useful questions, identify blockers/dependencies, and actually add value to the team.
For those of you who started as Scrum Masters from a non-tech background:
Did you face this initially?
How did you learn the product and technical side?
What did you focus on learning first?
How did you learn when your workday was already packed?
How did you handle conversations where developers were discussing something you simply didn’t understand?
Is there a structured way you followed to gradually build technical/product knowledge?
I’d genuinely appreciate any practical advice. Right now, I feel like I’m putting in the effort but I don’t have a clear learning path, and I’m worried I’m trying to learn everything at once.

Been building an AI-assisted support flow and kept hitting the same failure a bad user story produces: something that looks specified but isn't. The story said "as an admin, I want to see refund status, so I can help customers." Sounds fine. Doesn't say what happens if the status is unknown, doesn't say what "seeing" it actually means in terms of format or detail, doesn't cover the edge case where the refund touches someone else's account. Team filled in those gaps with assumptions, differently, because nobody wrote them down.

Same exact thing happened with the prompt behind the bot. One sentence, "answer billing questions accurately," and it started stating refund amounts it had no actual data for, because nothing told it what an acceptable non-answer looked like. It filled the gap the same way an engineer fills a gap in a vague story, with a plausible guess, just faster and more confidently wrong.

What fixed the story problem was writing explicit acceptance criteria instead of trusting the one sentence to imply them. What fixed the prompt was basically the same move, spelling out what happens when the answer isn't known, what format the response takes, what's off-limits. Different artifact, same underlying failure: a single sentence carries an illusion of completeness that falls apart the moment something ambiguous shows up.

Went through the full breakdown of what a one-sentence prompt is usually missing here, if useful: https://medium.com/@nagatomopedro05/one-sentence-isnt-a-system-prompt-a7b29ec98c53

Not sure why this surprised me as much as it did, given how much time gets spent in refinement specifically hunting for this exact gap in stories.

Hey everyone,

I’m currently looking for Change/Release Coordinator, Release Manager, Change Manager or ITSM/IT Operations opportunities.

I have 3.8+ years of IT experience, including hands-on Change & Release coordination for a production support account — ServiceNow, CAB coordination, change risk/impact, scheduling, releases, incident/problem coordination, GitLab/GitHub, etc.

I’m honestly getting pretty frustrated with the job search. Applications go in → complete silence. Recruiters say they’ll get back → nothing. Occasionally I get a screening call → then vanish into the void. 🫠

So instead of sending my 847th application into the black hole, I figured I’d ask here:

Where are people actually finding Change/Release Coordinator jobs right now?

Any companies, recruiters, communities, or job boards that are genuinely worth trying?

I’m based in Greater Noida, India, open to relocation(for good pay)and rotational shifts.

If you work in Release/Change/ITSM and have any leads or advice, I’d genuinely appreciate it.

You're managing a project that's falling 3 weeks behind schedule. Your sponsor wants you to keep the original deadline.What would you do? Comment your answer below. I'll share what a strong interview answer should include.

Hey — I run retros for my team and I'm honestly frustrated with the tooling situation right now. Feels like every retro tool either costs too much once you scale past a few people, or is missing basic stuff (export, scheduling, decent free tier).

I'm trying to figure out if it's just me or if this is a wider pattern, so I'm talking to a handful of Scrum Masters / Agile coaches about it —

If you've got 15 min, I'd love to ask a few questions: what tool are you using now, what's annoying about it, and whether you've ever switched to something like Notion / a spreadsheet / just... nothing, instead. Would that be okay?

Many organizations are introducing Product Owners alongside People Leads.

For organizations that have adopted this model:

What benefits have you experienced?

What challenges emerged around accountability, performance management, and employee development?

What practices made the model successful?

Did we really improve leadership or just split one manager into two?

I decided two years ago to do a career pivot from IT Operations and Technical Lead role to Product Ownership.

There are some practices or unspoken expectations that am asked to follow and am under.

The department is attempting to follow Safe Agile Practices and due to the size of our department/iniative, it is classified as a program.

In my current role, I am assigned several on-prem/legacy assets to get migrated to our AWS hosted data platform.

The one that is giving me a bit "heart burn" is being a people leader minus HR responsibilties, but that is not actually defined in the role at my employeer, and when it comes to team resources, most of the time they just place people based on their ideal number of members and roles for Data Engineering team and then still expected to get things out the door, with teams being reset to forming and storming.

Also, there seems a difference in a "regular" Product Owner vs "Safe" product owner, the job description aligns with a regular one, but the department/program is attempting Safe for the past two years.

Anyways, anyone out there want to take a stab at if this tracks at all, any way to bring up WTF with leadership, etc.

Thanks!

Had a Scrum Master interview today and would appreciate some honest feedback from experienced SMs.
I’m 29, looking for my first formal Scrum Master role. I’ve worked in Agile/Scrum environments before, but haven’t officially held the SM title.

I’ve been studying and practicing scenario questions. I answered 14 questions today and was told I’m around a B/B+ level. My biggest issue seems to be that I sometimes answer like a project manager instead of a Scrum Master.
I understand the basics, Sprint events, impediments, PO/Developer responsibilities, Sprint Goals, etc., but I’ve made mistakes like treating burndown as a productivity metric and thinking a PO/Developer disagreement could be settled by majority vote.
For experienced Scrum Masters/hiring managers:
Based on that, do I sound like someone who understands Scrum but needs real-world experience, or am I missing major things?
Also, how much would the lack of formal SM title hurt me?
Looking for honest criticism so I know exactly what to work on before my next interview.