Hello everyone,
I’m looking for some advice on breaking into a Junior Scrum Master role.
I recently graduated with a Bachelor’s degree in Information Systems and earned my PSM I certification. Before that, I spent nearly five years working in entry-level accounting roles within state government, where I gained experience with business processes, cross-functional collaboration, problem-solving, and working with financial data

Despite applying consistently, I’m still not getting interviews or offers for Scrum Master or related roles.

For those of you who successfully made the transition into Agile or project management, what helped you land your first opportunity? Are there specific roles, skills, or strategies I should be targeting first?

I’d really appreciate any advice. Thanks in advance!

Hey guys,

I'm product owner (with CSPO cert.) I've just landed a new job in certain mid-size company in SEA for 6 months, I'm about 8 years into my product career. On paper we run scrum BUT:

1. No Scrum Master, the PO (me) runs all the ceremonies, you name it: planning, refinement, retrospectives, do scrumpoker even.
2. No business analyst. I write detailed PRDs, talk to stakeholders, users, spinup jira tickets and PBIs.
3. No system analyst. Dev lead designs architecture together with other devs.
4. No QA person. I once raised question to management "Devs test their own stuff, that's how it's always been here." ; always ended up with I do testing and with a lot of bugs in user journeys.
5. No SRE rehire, one last infra guy left and was never backfilled, so outages land on the backend engineers and no one know the rootcause once the incident hit (temporary they said; but already 3 months long)
6. "Data-driven company"... except there's no data engineer, the pipeline is ancient maze, and when tracking breaks the question is somehow "why PO missing data tracking"
7. And every month I hand-run BigQuery MCP to assemble the revenue report for finance. Pretty sure that was never in a PO job description but here we are.

I saw stories where scrummaster roles disappearing and getting absorbed into the PO. That matches what I'm living...
Except it's not just the SM role, it's every role the org never hired or rehired. A fresh-grad PO would not survive this setup; you only cope by having seen enough org to improvise.

Genuine questions:

Is this the norm outside the big-tech bubble? If your org runs "scrum" with half the roles missing,

How do you keep the PO from becoming the org's shock absorber?

Has anyone actually pushed back on this and won?

Officially, Scrum promises higher quality, "potentially releasable" increments, and continuous improvement.

In reality, technical debt often accumulates sprint after sprint, eventually becoming a taboo subject.

Problem #1 – Sprint pressure crushes quality

In many teams, the sprint feels like a race:

• commitment to a specific volume of user stories,

• implicit pressure regarding velocity,

• review dates turning into mini-deadlines driven by business needs.

The result: the feature "passes," but the code is fragile, under-tested, and hard to maintain.

Problem #2 – An overly permissive "Definition of Done"

In many Scrum teams, the "Definition of Done" (DoD) is limited to:

• "it compiles,"

• "it works on my machine,"

• "it is functionally validated."

Features are pushed to production, while invisible yet essential tasks are postponed: refactoring, automated testing, minimal documentation, and architectural upgrades.

Problem #3 – Technical debt is missing from the backlog

The team is aware of the debt... but it doesn't officially exist:

• no dedicated items in the Product Backlog,

• no explicit prioritization,

• no clear business-level trade-offs.

It becomes "ghost debt," addressed furtively whenever a developer "has a bit of time"—in other words, never really addressed at all.

Problem #4 – The Product Owner lacks the tools to make trade-offs

In practice, many Product Owners:

• lack the authority to prioritize technical debt,

• face pressure from stakeholders,

• lack the means to measure the medium-term technical impact. The result: the roadmap fills up with new features... while the product's capacity to evolve silently deteriorates.

Ultimately, the question to ask is: "Do we consciously accept the debt we are creating today... or do we prefer to bury our heads in the sand and suffer the consequences of this technical debt tomorrow?"

Scrum is neither the culprit nor a magic bullet.

Here are a few concrete ways to regain control:

Without claiming to offer a miracle cure, certain practices make a real difference on the ground:

• making the debt visible in the backlog,

• strengthening the Definition of Done,

• explicitly allocating sprint capacity for quality,

• using the retrospective to track technical metrics, not just interpersonal ones.

Technical debt does not simply disappear.

However, it becomes manageable once it is collectively acknowledged and owned.

What do you think of it?

Hey all, wanted to know if there is any app or software available that includes CPM/ToC to manage timeline and schedule runs mapping?

I am consulting with a company where my poc wants me to figure out a project management software to be in compliance with TOC implementation guidelines in the manufacturing plant of our company. The other underlying factor would be to not cost 10a of thousands in the software unless the toc is verified and successfully implemented company wide - which will be sometimes q4 2028.

Google search and my own knowledge in this space doesn’t really yield to a solution without me spending many hours researching. Before I reinvent that wheel, I thought I would come here and ask. Thanks in advance.

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 ;)

Every time I tried to explain why Agile feedback loops matter, I'd put up a slide, people would nod politely, and nothing would stick.

So I built Agile Battleships — a free browser game that shows the difference instead of explaining it.

Two rounds, same grid:

🔴 Round 1: You fire all your shots at once. No feedback until the end.

🟢 Round 2: You get instant feedback after every shot. Same shots, very different experience.

No signup. No install. Works on mobile too. I use it to open Agile training sessions — takes about 5 minutes and the "aha moment" lands much harder than any slide.

👉 agilebattleships.com

Would love to hear your feedback — and whether something like this could be useful in your context, whether that's Agile training, team building activities, retrospectives, or onboarding new team members to Scrum.

https://preview.redd.it/deu8ds0i6lah1.png?width=1200&format=png&auto=webp&s=d682576f166e453db352e17b408154b146abead3

Disclosure: my own tool, free alpha, not selling anything — I need honest signal from people who run real sprints. The premise: paste messy requirements, get INVEST-compliant stories with acceptance criteria, plus a per-criterion breakdown of what fails and why. The bit I care about isn't "did it produce stories" — it's whether you'd actually pull them into a sprint without rewriting. So my ask: run it on something real from your backlog and tell me your "ship-as-is rate" — what % of the output would you use as-is or with minor edits? If that number's under ~60%, I want to know exactly why. Link: https://story-craft-web.vercel.app (free). I'll be in the comments answering anything about how it scores Small/Independent in particular, since those are the ones it's strictest on.

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/

I have been out of work for about 3 years, during that time I tried to move away from technical jobs but I didn't have much success in my job applications.

I was recommended to get CSM certification as a way to bridge the gap and get me a job while I try to figure out my career path. And I do need a job.

It is expensive though, the course would cost about £850 so I'm wondering is it worth investing in this? For information, my background is in QA, software and hardware.

Check-in moments during rituals (like scrum retros/reviews) seem underrated in my experience.

At my organisation, they're mostly used as energy stimulants or to capture the vibe. But I've noticed potential to use them differently—to get conversations started and surface trends/gaps across the team or org.

How do you use these moments effectively? Do you have any structures, questions, or tools that help you get real value from them?

I’m an HR professional, currently managing benefits for a government entity (medical, retirement, FMLA, etc etc) and I’m trying to think of ways to pivot out. Someone suggested scrum as a next possibility. Thoughts? Any HR professionals here? HR is constantly looking for ways to improve processes, especially in my role. Other than learning what all being a scrum master is, are there any certifications I should get?

Edited to add- I do have my bachelors in human services, as well. If that matters at all.

From all the experienced folks out there, I want to know from you real experience of what are the challenges that you faced as a BA or as a SM in scrum ceremonies mainly.

I am preparing for both BA/SM roles and I want to see what challenges do people usually face, can also mention some unique/or once in a blue moon challenges as well, I'd be very interested!!

Thank you :)

I've spent years in enterprise Agile delivery and kept running into the same problem: people pass their SAFe or Scrum certifications and then freeze when the real scenarios hit. The cert teaches the theory. Nothing teaches the feel of an escalation loop, a PI planning breakdown, or a backlog that's completely off the rails.

So I built SimStack Lite. It's a scenario-based simulation app for six delivery roles: Scrum Master, Product Owner/PM, DevOps Practitioner, Release Train Engineer, AI Program Manager, and AI Workflow Designer.

Features inside:
- Role-based scenarios with XP and readiness tracking
- Daily Challenges (timed, intermediate/advanced difficulty)
- Rapid Review flashcard decks - 144 cards across all roles
- AI Concept Vault - 59 enterprise AI concepts for practitioners
- AI Career Coach - interview prep, resume bullets, career strategy

Genuinely want to know what scenarios or situations you would want simulated. What's the thing that certifications completely missed for you? I’m looking for honest feedback from experienced practitioners before I continue expanding it. What scenarios would you want to see included that most interview prep and certifications miss?

If anyone wants to try it, let me know and I’ll share the link.

Hey all, Scrum practitioners, I'd love your take on something that's quietly breaking our process.

Context: fullstack dev at a large enterprise. We run fairly standard Scrum: backlog refinement → sprint planning → user stories with acceptance criteria → sprint → review. The Product Owner / Business Analyst layer owns the backlog, and historically nothing entered a sprint until it was refined and pointed.

What changed: we're piloting AI-assisted, spec-driven development (BMAD-style agentic toolkit, with our own internal rules) on a project we're rebuilding: frontend overhaul, UX/UI rework, new features. We went in with a spec doc and a Figma mockup.

The problem: the increment ran way ahead of the backlog. Roughly 70% of the project got built in about a week, with almost no user stories written. Our PO/BA layer isn't on these tools yet, so refinement is now the bottleneck instead of the gate. We effectively have working code before we have stories.

So the Scrum flow is inverted: increment first, backlog and stories... after the fact.

My manager (reasonably) wants a proper trace of what was built stories, acceptance criteria, docs for the support/maintenance load that'll hit in a few years. But that artifact layer doesn't exist yet, and the people who'd write it can't keep up.

Questions for people who've hit this:

1. Does a fixed sprint cadence still make sense when a feature ships faster than you can even schedule refinement? Do you shorten sprints, drop them, move to flow/Kanban?
2. How do you handle the backlog when stories come after the code? Do you reverse-generate stories + acceptance criteria from the shipped increment? Does that still count as a backlog?
3. Where does the PO/BA role move — onto the AI tooling, into validation/acceptance, into guarding the Definition of Done?
4. How do you keep the Definition of Done meaningful (traceability, docs) when build speed outpaces refinement?

Not after AI hype or doom just real experiences from Scrum teams who've actually been through this. What adapted cleanly, what broke?

Thanks.

With massive respect to Jeff Sutherland and all the thought leaders who met at a ski lodge in Snowbird, Utah, in 2001 and created the Agile Manifesto - it might be time to revisit / refresh / revitalize the Agile Manifesto in light of the emergence of AI/LLMs.

The scarce resource is no longer programming capacity, but organizational clarity and architectural coherence.

As a thought exercise (and for fun) I took a stab at it. I would love to get some collaborative feedback to improve it. Of course I do not expect this to replace the Agile Manifesto but I'd like to use it when speaking to enterprises about how to think about Agile in today's world.

So any/all comments welcome!

ps - posted on my blog because of convenience. It is not monetized in any way. No ads, nothing. Cheers!

I have seen countless threads about the best one to manage sprints but most sprint failures experienced had very little to do with the software itself.

The bigger issues were scope changes, hidden dependencies, unclear priorities and unexpected work.

What has made the biggest difference?

Hey everyone, French tech vet here. I wrote this piece in French based on my experience, and used Gemini to translate it into English so I could share it here. Hope the translation holds up, looking forward to your feedback! 

To understand why the technological explosion of artificial intelligence is translating neither into macroeconomic growth nor into well-being at work, we have to look at the history of computer science, the physics of industrial flows, and the reality of employment statistics.

1. The original sin: how we imported civil engineering into software

In the beginning, the first software engineers did not have dedicated degrees. They were mostly self-taught. Faced with massive demand from corporations, industry founders like Serge Kampf (the creator of Capgemini) made a simple decision: "We will hire traditional engineers and turn them into programmers later."

The first wave of computer scientists was actually made up of chemists, physicists, and mechanical engineers. None of them had studied computer science.

The issue is that these people arrived with the only methodology they knew: waterfall (or the V-model).

In their physical world, this was a necessity. If you are building a bridge, you cannot change the number of lanes while pouring the concrete pillars without a massive financial disaster. But while it is quite hard for experts to completely fail a bridge, in software development, you can discover on inauguration day that the entire thing collapses under its own weight.

Software consulting built its foundations on methods borrowed from civil engineering that are completely unsuited to immaterial work. The result was decades of massive projects worth millions of dollars being thrown straight into the trash.

2. The agile hijack: being agile vs. doing "agile methods"

When you have created your own problem (the millions wasted on waterfall), you can conveniently forget that you were the one who made the mess, and arrive with a brand-new, "better" method. It is easy to look like a savior when you are fixing the exact system you broke.

But we need to make a fundamental distinction here that almost everyone misses: there is an absolute chasm between being agile (the mindset) and applying an agile method (the framework).

• Being agile is pure common sense. It is about adapting to reality, cutting out middle managers to talk directly, establishing short feedback loops, and being willing to change your mind when data or users prove you wrong.
• Agile methods are the exact opposite. They are a packaged marketing product created by consulting firms to be sold to executives.

To sell these frameworks, consulting firms did not look at how to build a bridge. They went a level lower into industrial production: the factory assembly line.

Cadence, predictability, and total control—these are incredibly seductive concepts for top-level management. So they took the logic of a manufacturing plant, added tracking tools, and packaged it into rigid systems like Scrum or SAFe.

Scrum was first conceptualized in the 1980s by Japanese theorists observing industries like Toyota, Honda, and Fuji-Xerox. For anyone who has ever worked a factory shift (like me in 2/8), the truth is obvious: the daily stand-up, the burndown chart, and the highly specialized sub-teams are just the basic mechanics of an assembly line. Under the guise of modern management, we have turned intellectual, creative professionals into factory workers on a digital line. We killed the agile spirit to sell heavy processes.

But to sell this to white-collar corporate workers, they had to repackage it. They used tangible, business-friendly vocabulary: product.

They introduced product managers and product owners (and the difference in the scope of these roles between tech and traditional industries is hilarious). They rebranded AMOA into product owners, project managers into product managers, and stole a few tricks from designers along the way (who were too dumb to speak the language of business at the time).

To make the organizational equation even more toxic, the industry designed the product manager as a "non-hierarchical manager." A PM has the mandate to direct, modify, and influence your daily work, but holds zero actual hierarchical authority over your career, team, or salary. This is the ultimate recipe for passive-aggressive politics. Because they cannot manage through formal authority, they have to manage through endless "alignment" sessions, workshops, and psychological negotiation, adding a massive layer of administrative fatigue to every single sprint.

And just like that, because waterfall was dead, they could no longer sell project managers. Instead, they sold you product owners and product managers. They are the exact same people from the exact same schools. The people who were ruining your projects yesterday are marketed as your saviors today.

This was guaranteed to work because the previous system was so broken that the bar was on the floor. Plus, this transition happened right when modern collaboration software was emerging. Comparing a 300-page Word specification document living in 17 different email threads with tools like Notion or Jira made the new approach look revolutionary. The methodology took the credit for the evolution of the tools.

If you don't agree with me, make a test. Take e team, on one iteration, remove the method, they can dow what they want. On the second one, remove the tools. See what happens

3. Rockefeller's oil and the golden handcuffs

To ensure no one in the organization would challenge this new bureaucracy, they established two unwritten rules:

Rule 1: the trap of systemic dependency

Much like in a bureaucracy, they ensured that the newly created roles cannot exist outside of the framework itself. A pure scrum master or agile coach has no real professional existence outside of the agile framework. You do not criticize the system that defines your title on LinkedIn and pays your mortgage.

Rule 2: Rockefeller's oil

They applied a classic strategy: "Rockefeller lamps only burn with Rockefeller oil." This means two highly cynical things:

1. You must buy the entire methodological package. If it fails, the consultant has a perfect excuse: "Ah, but you are not doing true scrum. You are not applying the framework by the book."
2. You completely erase any alternative approach, making any objective comparison impossible.

And the corporate machine kept running. Companies did not produce more value, product teams became bloated and slow, but managers could brag that they were "agile" because they had Jira boards. The goal was never efficiency; the goal was maintaining the fear of missing out.

4. The macroeconomic reality: a model for the 0.1%

Whenever a chief product officer defends these heavy, enterprise-scale agile frameworks by talking about "scalability," you just have to look at the actual data of the economy.

nb: this data are basics, feel free to correct me.

If we look at US business statistics, the reality is stark:

• 99.9% of all businesses in the US are classified as small businesses (fewer than 500 employees).
• 89% of all US firms employ fewer than 20 people.

(Source: US Small Business Administration, Office of Advocacy, 2024)

The massive, highly bureaucratic structures for which frameworks like SAFe or scale agile models are theorized represent less than 0.1% of the real economy.

By imposing enterprise agile and heavy product bureaucracies as the absolute industry standard, we are forcing small, nimble organizations to adopt the functional pathologies of bloated multinational corporations.

It is in this tiny fraction of massive enterprises that the work has become hyper-bureaucratized. And this is exactly where artificial intelligence is currently colliding with the system.

5. AI and the bottleneck trap: the theory of constraints at work

This is where the tech Cassandra theory comes into play. While everyone is bragging about AI productivity gains on social media, economic growth is flat, and employee burnout is at an all-time high. Why?

Because the throughput of any system is always dictated by its tightest bottleneck. This is the core of Eliyahu Goldratt's theory of constraints.

6. The illusion of local efficiency

AI has drastically increased individual production speed (the input). A software engineer can write code 40% faster, and a designer can generate five times more screens in an afternoon.

But the theory of constraints teaches us that optimizing a step that is not the bottleneck is a complete waste of time and money.

The bottleneck of a digital product is almost never the speed of writing code or drawing a UI. The bottleneck is political validation, stakeholder alignment, and the speed of human decision-making.

AI has not increased a manager's ability to take risks by a single second, nor has it sped up the budget approval process of a steering committee.

7. Saturated flows and cognitive overload

By flooding the decision bottleneck with an astronomical amount of AI-generated designs, code, and feature proposals, AI has actually increased the work in progress.

The system is now completely clogged. The agile meeting culture, with its endless synchronization rituals and alignment sessions, is collapsing under the weight of this overproduction. We are spending more time sorting, debating, and stressing over options than we did before.

By design, agile organizations simply cannot handle modern makers who possess both vertical and horizontal leverage. These frameworks are obsessed with cutting every single project into tiny, atomic tasks—isolating people into narrow, hyper-specialized silos. But when an AI-empowered creator can handle the entire end-to-end flow (or at least a significantly bigger part of it), this love of micro-slicing work turns against the system. We are trying to fit hyper-capable, cross-functional individuals into a rigid ticket assembly line designed for cogs.

• Makers (developers, designers) feel increasingly alienated because their high-speed, end-to-end output sits dormant in massive backlogs or dies in validation committees.
• Managers (the bottleneck) are facing intense cognitive overload as they try to filter, validate, and arbitrate this constant stream of proposals.
• The result is a widespread loss of meaning and a massive spike in burnout. We are working "faster," but achieving less because the organizational process is blocking the flow.

8. The only measurable return on investment: layoffs

Because this surge in production velocity cannot bypass the decision-making bottleneck, it does not translate into market growth. The business volume remains the same.

For finance departments, the accounting logic becomes like this:

>

This is the ROI of cost reduction, not the ROI of value creation. AI is not being used to achieve better outcomes; it is being used to reduce the cost of the excess output generated by broken, over-engineered methodologies.

9. Conclusion: the agile theater must change or drop the curtain

The bloated agile frameworks are losing their justification. They are being exposed for what they have always been: layers of bureaucratic sediment that slow down decisions under the guise of organizing them.

To break this cycle, we have to return to the true spirit of agility.

When you remove the political intermediaries, when you stop trying to predict everything, and when you let real usage data make the decisions instead of human opinion, you are practicing true agility. You are widening the decision bottleneck.

Today's typical enterprise does the exact opposite: it keeps its slow, rigid agile methods, injects AI to code faster, wonders why growth is stagnant, burns out its teams, and ends up laying people off to balance the books.

The theory of constraints isn't a complex strategy; it is simply the reality of the flow we refuse to see.

It’s quite a bit long, kudos to anybody that read this until the end !

Hey everyone, French tech vet here. I wrote this piece in French based on my experience, and used Gemini to translate it into English so I could share it here. Hope the translation holds up, looking forward to your feedback!

To understand why the technological explosion of artificial intelligence is translating neither into macroeconomic growth nor into well-being at work, we have to look at the history of computer science, the physics of industrial flows, and the reality of employment statistics.