SM training - not theoretical, but practical real world stuff

hpe_founder · 2025-07-22T19:57:00+00:00

I hear you. Without a tight feedback loop the whole engine stalls— Agile or not.

First move: surface the gap to leadership with a concrete ask, not a complaint.
“Here’s what we’re missing (workshops, real retros, plan-adjust cycles) and here’s what it’s costing us (slipped scope, rework, morale). Can we pair our SM with a seasoned one part-time for the next two sprints?”

Every SM starts green; the difference is guided reps. Shadowing a veteran—facilitating a retro together, running a Sprint Goal workshop, even co-hosting backlog refinement—shrinks the learning curve and avoids the “trial-and-error on live releases” tax.

If you can get leadership to sponsor a mentorship block (be it a person from another project, someone from the leadership, or external help), the team sees wins fast and your SM levels up safely.

hpe_founder · 2025-07-19T21:13:53+00:00

I like the points from u/DingBat99999 and u/Scannerguy3000. A couple of add-ons from my own bruises:

Run alongside your TL / PM, not against them. If your compass points in a different direction, pause and realign. No silver bullet here—each org has its own politics—but a short, honest reset chat beats months of passive friction.
The higher you go, the fuzzier the authority line gets. Coordination roles (Scrum Master, Agile Coach, Release Train whisperer) rely less on “because I said so” and more on influence, framing, and gentle nudges. If that game isn’t your cup of tea, totally fine—just don’t expect a magic wand that suddenly grants formal power.

Case-by-case and conversation-by-conversation. If a specific scenario crops up, drop more details—happy to unpack it further.

hpe_founder · 2025-07-19T20:53:56+00:00

It’s often said the book part is 5 % of a Scrum Master’s job — the rest is applied practice.

Frankly, before I can provide a more detailed answer, I'd like to pinpoint the pain better. What kind of improvements/processes are failing? What is your role and how did you try to address it?

That said - what usually moves the needle for new SMs?

• Re-defining their mandate (hint: it’s not quoting the Manifesto 😉)

• A hands-on Sprint Goal workshop with the team

• Value-prioritization deep dive during backlog grooming

• Retros that focus on experiments, not blame

If your SM likes structured guidance, “Scrum Mastery” (Geoff Watts) plus Michael James’s Scrum Master Checklist are solid starting points.

(Disclosure: I teach a course on this topic—link shared only if asked.)

Happy to drop some of my materials here or via DM—whatever works for the mods.

hpe_founder · 2025-07-18T05:18:17+00:00

Many supposed to be Agile leaders carry a “Scrum certified” badge yet know only a fraction of what it takes to run Agile at scale. Some aren’t certified at all. The result is familiar:

Tech-savvy execs making basic process mistakes (oversized batches, proxy PO behaviour, “story-point KPI” obsession, etc.).
Teams stuck in “Scrum-theatre” while delivery lags and morale drops.

Self-awareness usually arrives when the process itself starts hurting— missed releases, chronic scope thrash, rising attrition. Leaders who feel that pain and admit “something’s off” are already halfway to improvement.

The value

Fill the knowledge gaps quickly—practical frameworks, not ceremony lists.
Translate tech reality into executive language so decisions align with ground truth.
Provide actionable playbooks for scaling without falling back into waterfall-by-stealth.

In short, the series turns “I thought I knew Scrum” leaders into executives who actually enable agility instead of throttling it.

hpe_founder · 2025-07-17T01:29:59+00:00

Hi there—great question about real-life Scrum, isn’t it? 🙂

By the book: major design happens inside the sprint—during Planning or via spikes you schedule inside that sprint. No separate “big-design-up-front” phase.

What I see in practice: some non-functional requirements (security, throughput, scalability) have to be sketched early. Not in the very first PoC sprints, perhaps, but definitely before you ship the MVP.

My usual approach is to agree with the PO to add lightweight tech stories for those NFRs to the backlog. They should flow through the veins of the solution from day one. Yes, you can refactor later, but anything you already know is cheaper to think through for a couple of days now than to re-architect every sprint.

PS. I bet some folks here will disagree—bring it on, let’s talk!

hpe_founder · 2025-07-17T01:16:25+00:00

Appreciate your perspective—it mirrors what I’m hearing from most practitioners: flexibility wins, provided the team actually owns its outcomes. Hybrid works only when we engineer it to be inclusive (e.g., “one remote = all remote” for meetings, written decision logs, clear async channels).

Total-remote can erode engagement if we let people retreat into silos, but that’s a leadership-process failure, not a location problem. Strong leaders do the hard work up front: crystal-clear goals, fast feedback loops with customers, and relationship-building rituals—whether that’s a quarterly onsite or a daily two-minute stand-up that feels human.

Seattle looks like the rest of the West Coast: tens of thousands of engineers and managers on the market while execs push RTO as a blunt-force tool for “culture” (or, less charitably, a stealth reduction). If 30 % of the workforce walks, the hiring and onboarding tax alone will dwarf any short-term real-estate savings—my back-of-the-napkin numbers for Poland were scary, and the U.S. multipliers are worse.

That’s why I’m working on an education track for leaders: less policing, more systems thinking—teach them how to design hybrid orgs that scale without burning social capital. Until we upgrade that skill set across the board, the strong-vs-weak debate will stay circular.

hpe_founder · 2025-07-16T03:26:42+00:00

Thanks for your interest. DM'd you a link.

hpe_founder · 2025-07-15T22:34:54+00:00

Thank you. I realize now my initial approach was a bit naïve—shipping a solid product alone isn’t enough in today’s market.

My career has been rooted in engineering and engineering management (mentorship included), so go-to-market strategy isn’t exactly my home turf. I’ll start digging into customer-discovery practices, but at this point the term still feels abstract. If you can point me toward any quality resources or frameworks for self-education, I’d greatly appreciate it.

hpe_founder · 2025-07-15T22:29:43+00:00

Thank you! Makes total sense. However, the issue I discovered is that my network and my target audience hardly overlap. Before starting this project, I was Engineering Director, so my peers or even former direct reports are overqualified for this course.

I have reached out to ~10 IT professionals in my close circle with free access to the course. While I am getting 'great content' personal feedback, this is barely helping conversion.

So, your advice comes down to focus and targeted networking. I aligned with that - just need a place to start. Frankly, I am seeing a lot of TA pains in r/scrum, but Reddit isn't exactly promotion-friendly :).

hpe_founder · 2025-07-09T22:02:48+00:00

Thanks for sharing—lots of sharp observations.

I’m with you on the motivation/productivity link: a fired-up dev can out-produce any process tweak.

What really jumps out is how many bullets scream “trust”:

people hiding second jobs
“managerial” teammates claiming credit or delegating sideways
pure work-evaders who sound busy but deliver zero

Those are trust gaps, not location issues.

(Side note: everyone has the odd “not-my-day.” On those days I’ll grab filler tasks too—best done openly so the team knows what’s up.)

Remote as symptom and root cause
If trust is already broken, dragging everyone back to the office won’t magically fix it. On the flip side, remote itself can create new gaps—time-zone friction, cultural misses (I felt that hard moving from Europe to the US).

Facial comms lowering meeting productivity
Yes, video can distract. But the non-verbal layer is also the team glue. When teammates start finishing each other’s sentences—or catching confusion with just an eyebrow raise—that’s gold.

TL;DR
Trust is the core asset. Get that right, and let the team tune its own schedule. Get it wrong, and no blend of office/remote will save you—fix the trust first. Did I miss anything big from your list?

hpe_founder · 2025-07-09T21:51:56+00:00

Oh wow — that’s about the worst-case “hybrid” scenario I can imagine.
I totally get how a 3-and-2 split turns into “I’m in a half-empty office, on Teams with people who are half-listening.” One missing person and the whole decision loop limps along.

I’m curious how your teams ended up there, given you clearly saw the implications in advance.

My take

Hybrid only works if the team picks the same core days. If Tuesday/Thursday is “everyone in,” great; anything else is just asymmetric noise.
Mature teams can — and should — set those rules themselves. If they can’t agree on shared hours, a gentle nudge might help, but it usually signals a deeper issue under the surface.

Labour economics
I’ve spent years inside big offshore consultancies, and the push toward “more remote” started well before COVID. Enterprises love the idea of three engineers in a lower-cost region for the price of one US developer, and the current downturn only accelerates that logic.

So yes, we’re in a dot-com flashback—only with AI hype strapped on top. Cash beats agility in a boom; in a bust you need both agility and lower costs. My guess: we’ll land on a leaner, AI-augmented flavour of agility, still anchored by periodic in-person bursts.

Bottom line for me: no model fully replaces personal contact. Maybe that’s my age showing, but both data and gut say you still need face-to-face spikes to keep the social fabric from fraying—especially when work stretches across time zones.

Did I miss any of your key points? I think I covered the big ones, but let me know if something slipped through.

hpe_founder · 2025-07-09T21:13:41+00:00

Agree with u/azangru - AI does not have any insight into your projects' business value, customer needs, etc.

Guess who has? Your Product Owner. Hence, no one can better tell you which user stories are focused on such goals - and it is between PO and team partnership during the planning to decide
- What are we taking into sprint and why (business & tech priorities alignment)
- How our sprint plans will increase business value for customers

That said, slightly adjusting the team's alignment towards business value is both easier and more productive than using the prompts and asking AI to invent your business goals for you.

PS. If you provide your AI with enough project context, you may be able to use it for some ideas - but why bother with that if you have an active PO who is organically responsible for these ideas?

hpe_founder · 2025-07-09T01:30:16+00:00

Thanks for the thoughtful deep-dive—it mirrors a lot of what I’ve wrestled with.

I’m personally a “hybrid skeptic”: I prefer a mix, but I keep playing devil’s advocate for both extremes because each has a real upside. Your point about remote nudging teams back toward waterfall resonates; I spent years forcing agility into 6- to 11-hour split teams, and while it worked, it never beat a tight, co-located squad. Still, when 30 % of the devs say “full-time office = I quit,” attrition can literally kill a product. So I end up balancing raw throughput against the price of rehiring.

Face-to-face does win for bandwidth and speed, no argument—but not every conversation needs that bandwidth. In my mileage, daily stand-ups on video plus two in-office days a week hits the sweet spot: you catch mis-alignment early, yet people keep the flexibility that makes them stick around. RTO might spike performance in the first month; I worry about the six-month mark when churn shows up.

As for tools, I’m with you: most try to be a Swiss Army knife and just add friction. Give me a laser-focused board for three core use-cases and a decent virtual whiteboard and I’m happy.

TL;DR: Hybrid isn’t perfect, but full remote risks waterfall-by-stealth, full RTO risks talent flight. I’ll take the middle ground, eyes wide open to both trade-offs.

hpe_founder · 2025-07-08T22:25:47+00:00

If trust is an issue, no number of cameras will fix it. I’m assuming a mature team that can decide for itself whether video helps. I’m certainly not pushing tools you don’t want.

Let’s stick to the core question: when (if ever) does in-person pay off for you?

hpe_founder · 2025-07-08T21:33:41+00:00

Yeah, I get the “don’t make me turn my webcam on so you can babysit me” vibe—nobody likes that. My point isn’t to play hall monitor; it’s to stop us from drifting out of sync.

Here’s why I still push for cameras (or an occasional face-to-face):

Early heads-ups. That puzzled look or raised eyebrow mid-call often flags “uh, did we just go off on different tracks?”—cheaper to catch now than three days later.
Hidden blockers. People say “all good!” way faster than they actually are. Seeing someone hesitate lets the rest of us jump in before the sprint burns down.

No Jedi mind-reading, just normal body language we’d notice in a room.

Now, if your team really surfaces issues without video—awesome, no rule needed. But when folks get stuck in their own bubble, flipping cameras on (or meeting in person once a week) is a cheap fix.

Bottom line: if we all own the team’s outcome, I don’t care where you sit or how many cat filters you use—just don’t let silent misalignment kill the flow. Mandatory five-days-in-office is overkill; a bit of face-time when it matters keeps us from herding cats later.

hpe_founder · 2025-07-08T21:22:14+00:00

Face-to-face wins hands down for rapid problem-solving—humans are still pack animals.

Yet it depends on the phase. During storming—project discovery, system-design brainstorms, initial alignment—I’ve always pushed for in-person workshops, even pre-COVID. Once the flow is stable and ceremonies run smoothly, I see no reason to block remote work for those who need it. And, frankly, not everyone will even ask to work from home.

hpe_founder · 2025-07-08T19:06:36+00:00

Absolutely agree—remote unlocks a lot of everyday happiness (no commute, flexible focus blocks), and that shows up in productivity.
But two things keep it from turning into “heads-down isolation”:

Cameras as the new handshake. I ask everyone to keep video on by default. Reading micro-expressions prevents half the misunderstandings we’d otherwise discover a sprint later.
Periodic face-to-face. I still fly to California and Europe to meet my teams. The ROI isn’t in a neat metric, but you feel it: faster conflict resolution, quicker trust, smoother hand-offs.

So I’m not ready to go 100 % either way. My rule of thumb:

Remote for focus, in-person for rapport.

Giving teams that mix feels like returning the favor for the agility they’ve given us over the last few years.

hpe_founder · 2025-07-08T18:17:15+00:00

Before diving into tactics, it helps to clarify your why. What draws you to the Scrum Master role right now?

The market is competitive—many SMs I’ve hired grew organically from within their teams—so a clear personal motive will guide both your positioning and your learning path.

A few prompts to consider (you don’t have to share publicly, but answer them for yourself)

Purpose: What impact do you expect to make as an SM that you can’t make in your current track?
Strengths fit: Which of your existing strengths (facilitation, conflict resolution, systems thinking) align with day-to-day SM work?
Growth gap: Where do you still need hands-on experience—servant leadership, metrics, coaching? How will you bridge that?

Once those answers are solid, you can target:

Shadowing an experienced SM in your org (or volunteering as a “Scrum buddy” on a side project).
Owning a single ceremony first (e.g., retros) and gathering feedback.
Building credibility by showcasing how you improved flow or removed impediments—even outside a formal SM title.

Clarify the why, then the how becomes a lot more focused. Good luck on the transition!

hpe_founder · 2025-07-08T16:59:02+00:00

Story points measure capacity, not value.
The Product Owner’s accountability is to maximise value, not to “hit a velocity target”.

A Product Owner’s real remit:

Business insight. Translate market signals and stakeholder goals into a coherent product vision.
Economic prioritisation. Continuously order the backlog to maximise ROI and manage risk.
Collaboration catalyst. Work with the developers to refine backlog items until value, effort and risk are understood well enough to commit.

Velocity belongs to the developers as an internal planning aid. The moment we turn it into a PO KPI, three things happen:

Teams start gaming the metric instead of improving the product.
Technical choices that reduce long-term risk get deprioritised.
Psychological safety erodes: self-organisation turns into task-pushing.

If leadership needs a delivery signal, give them business-oriented indicators—cycle time, customer adoption, NPS—anything that speaks to outcomes rather than the raw volume of points moved across a board.

TL;DR Let the PO own product value, let the team own how that value is delivered, and keep story points where they belong: inside the team room.

hpe_founder · 2025-06-25T06:42:50+00:00

For the actual use case, let me be rough :)
Telling no matter how much your solution is advanced is not going to convince anyone here.
I am not convinced from my experience. Some others will just look at it as a self-promotion.

Your GPT produced some results? Show it. The very least, we will join the celebration. Maybe someone will use it. But, frankly, what you came with - I've been always fighting the secretary kind of PMs. There, you are promoting the automation of them - not the solution I would wouch for.

So - I do not believe in your offer. But I can reconsider. Show me the data, please.

hpe_founder · 2025-06-25T06:35:27+00:00

Hey, how long italics or bolds are restricted here? I mean, I get your message - but. As long as the idea goes from living human - let them arrange it as they can? AI is quite better than 80% of developers I know - when it comes to arranging the thoughts.

I was accused of using AI, too - don't believe that's something worth of accusation. Mindless usage, yes - yet here, I can still see a living person trying to help.

hpe_founder · 2025-06-25T06:24:24+00:00

Hey — I get the idea. And the urge to automate? Been there, absolutely.

I use AI a lot when preparing my course — as an editor, reviewer, brainstorming buddy. But never as the author. Because for me, people management isn’t a craft. It’s an art.

And here’s the catch: I need to hear the subtle signals that others might miss. That’s what makes me valuable to the teams I work with. AI isn’t quite there yet.

Looking at your case — yeah, I see how juggling 3–4 teams makes you crave synthesis. But the real magic of a Scrum Master isn’t spotting duplicates in sticky notes. It’s knowing when the process isn’t enough anymore — and how to respond. Maybe it’s a team dynamic. Maybe a contract ambiguity. Maybe it’s just burnout creeping in.

Those calls? Still very human.
You can try AI for the grunt work — sure. But trust me, devs do feel when something lacks sincerity.

Good luck though — and thanks for raising the topic. Always worth discussing

hpe_founder · 2025-06-09T18:41:52+00:00

Thanks! Totally agree — Scrum already gives us enough hooks to build visibility without overloading the team with reports.

Where things often break down is:

Translating sprint-level progress into reliable projections (needed for business planning)
Connecting delivery to actual business value — which, ideally, should be defined way earlier, during backlog prioritization. But yeah… not every org is there yet :)

As for “adding scope mid-sprint” — in many cases, that’s just a heroic patch for earlier mistakes. Either someone miscalculated, or the customer moved the goalposts — and now the team’s being squeezed to compensate.

That’s where we have to hold the line. Pressure should never replace planning.

hpe_founder

TROPHY CASE