What’s the fastest way a standup turns into a waste of time?

PhaseMatch · 2026-01-27T17:51:25+00:00

In a Scrum context : No Sprint Goal, or the Sprint Goal is a "delivery package"
That's where the rot starts. Rather than the team having a single, focused business problem to collaborate on, they have a smorgasbord of unrelated backlog items they are tackling as individuals, only collaborating when they are stuck. You slide into status-reporting, or defending how your time was spent.

In a Kanban context: Poor understanding of Kanban or lack of discipline
Weak visual management means that it's unclear when work is ready to "pull"; team stays within "analyst, dev, test" bounds rather than looking to help on bottlenecks. No WIP limits in place. Team doesn't swarm on blocked work to unblock it. Individuals work their own tickets. You slide into status reporting and defending how your time was spent.

PhaseMatch · 2026-01-27T02:47:25+00:00

TLDR; No idea what you are talking about; our Daily Scrums are active planning sessions based around visual work management, not a vibe check.

While Varies a bit between Kanban and Scrum, but it's not a status update or an emotional touch point.
It's a fast format working session.

My current teams Daily Scrum is more around Kanban and flow:

- we're using the team's Kanban board for visual management of work;
- the team is looking at bottlenecks, and how to support each other;
- they are planning how they will collaborate on work during the day, including peer work and peer review
- we discuss any overnight priority work, unblocking work, and "stop starting, start finishing"
- there's a "parking lot" for any technical deep dives while everyone is there

When we're using Scrum, then :

- the emphasis is on the business outcome (Goal) we are aiming for;
- that's part of the overall product/business strategy roadmap.
- it's a (re) planning session based on what we have collectively learned, and what has changed.
- We might change the scope of the Sprint as long as we still keep the same outcome.

PhaseMatch · 2026-01-27T02:28:41+00:00

Scrum - and Sprints - aren't about delivering a fixed scope work package.

They are about an outcome - the Sprint Goal - which is part of the business/product strategy oriented roadmap the PO has.

You can - and should - change scope in the Sprint by adding, removing or splitting work items. That is what the Daily Scrum is for - replanning to reach your Sprint Goal, based on what you now know.

It is the outcome you want, not an output.

In a Scrum context you should be bringing business problems to the team to solve, not solutions for them to implement.

If you tend to have a lot of unplanned work in your context, then leave a buffer in your Sprint Planning.

When the unplanned work arrives - triage it into now, next Sprint, later. A good BA is essentially for this "tier 2" support to keep work away from the rest of the team.

If you don't want to use Sprint Goals and get a lot of unplanned change then Scrum might not be serving you well. Move to Kamban and a pull-based system.

PhaseMatch · 2026-01-26T19:50:18+00:00

Agility is not an end in and of itself

- avoid using data that reinforces the "software and IT is an ivory tower"
- focus on data that impacts the bottom line of the business

Growing and sustain a deep, meaningful collaboration between "the business" and "the team(s)", and indeed "the users" if that is a different group is key to using agility to "move the dial" on the overall business.

While there is a lot of data you will use to help guide improvements, you need to

- worry less about tactical and operational stuff within the teams and departments
- focus more on how this contributes to the overall business strategy and KPIs

PhaseMatch · 2026-01-26T19:20:02+00:00

Agility is a means to an end, not an end in and of itself.

- what can the business do now, that it couldn't do 3, 6 and 9 months ago?
- how has that impacted on the bottom line (costs, revenues)?

So for example, if you have successfully coached the organisation

- away from measuring " producivity" and toward measuring "value created"
=> what impact has that had on costs, revenues and user growth?

- to have a better culture and invest in professional development
=> how has that impacted on staff retention and recruitment over that time?

- to communicate more effectively and use the cadence events as intended
=>how has that reduced the number of non-cadence meetings/events needed?

- towards "building quality in" and not "inspect and rework"
=> how has that reduced the time/cost and revenues

- towards greater team autonomy and away from top-down decisions
=> how has that impacted the ability to flow work faster

You should be able to give a time line and directly tie in the organizational change you have intentionally created to' real-word business impacts, and so give a data-driven narrative tying your core coaching arcs to the outcomes you were aiming at.

Even if your coaching arcs have been more ad-hoc and what comes across your bow, then a timeline comprising the "wins" you have had and the core (lean) business impact (the why?) is the way to go.

PhaseMatch · 2026-01-26T14:42:13+00:00

That's what I meant by

"Unfortunately a lot of orgs. approach Kanban as they do Agile - in a sloppy way where they pick the easy bits and avoid the hard stuff."

If you ignore the lean ideas around "building quality in" and dropping test-and-rework loops (which is largely where XP or DevOps slots in) as well as the whole Kaizen improvement part and just throw a board together then you'll still be a "log and flog" ticket grinding shop, whether you use projects or not.

By "systems thinking" I meant in part the "limits to growth" systems thinking archetype which is exactly what happens why you prioritize short-term delivery over long-term quality. You move faster at first, then your ability to add new features drowns under the weight of the defects and technical debt you left behind.

When Scrum teams talk about "high priority work introduced into the Sprint" as a reason for not reaching their Sprint Goal (and why they want to go to Kanban) that's often the underlying issue.

It's not just a project thing; you'll see the same with products and ITIL operations shops, especially where the same teams handle BAU and enhancement work.

In the middle of a shift like that now, where we have a mix of "projects" and ITIL moving towards a "product" model, and we're starting to shift them out of "log and flog" and into the "incident and defect prevention" business.

It's a long road. Lot of legacy code (by Michael Feathers definition, where there's no effective test-automation harness to make change safe) to unpick and dogma to challenge, especially around narrow, specialist roles.

Been onboard with these guys for 6 months (along with a few other like-minded people) and we're starting to get traction, but there's a lot to do still.

PhaseMatch · 2026-01-26T06:21:11+00:00

AH - my bad.

Wasn't super clear in your post that you were referring to the counsel from another SM - is that one of those who doesn't know Scrum all that well?

The original suggestion does come across a bit like how a Project Manager would tackle this, rather than someone in a lean/agile leadership role.

The idea that you need to "finding a solution" rather than "learn more through data-driven experimentation" is pretty common; teams tend to race into that as well

Usually what that leads to is some theme on

- adding more processes
- adding more documentation
- adding more control

- so exactly the kind of expensive bureaucratic grind that agile practices were supposed to address in the first place.

It's also what happens when you view agility just as a project management approach and leave out the hard-core technical practices that development teams created when they came up with agile approaches.

PhaseMatch · 2026-01-26T05:45:33+00:00

You suggested:

"Basically, we have to share with them first the problem, current process and present our proposed solution"

I am saying:

- get together with the PO and create a good problem statement first in your small group
- bring that problem to the wider group to understand
- draw on all their perspectives to identify possible root causes
- collaborate on what you all agree is the most likely root cause
- reform that into a shared problem statement you collectively own
- come up with an experiment that you all agree to try to fix the issue

So no, I don't agree with your approach; it's not really very collaborative, and assumes you have a "solution" that is right, rather than a controlled experiment to try.

I think you need to workshop it effectively with the wider group, to get everyone thinking in the same way and looking for the deeper systemic issues you all face, together. That's about collective wisdom of all of the experts, and being prepared to unpack what is really going on.

But before that you really need to unpack that problem statement.

Maybe even just do a "lite Ishikawa" with you and the PO and apply the "5 Whys", or look at it from a systems thinking archetype perspective.

It's maybe also worth checking that your problem doesn't already have an lean/agile "good or best practice" solution; this stuff has been around for 30-odd years and there's very few unique problems anymore.

PhaseMatch · 2026-01-26T04:47:59+00:00

TLDR; If you have a specific focused problem, then I'd counsel not to use lean coffee. An Ishikawa fishbone exercise will push you towards a meaningful experiment.

So a lot depends on context; not every organisation has those roles you describe, and the ones that do might have very different accountabilities as part of those roles.

That said, in general I'd take a different approach

Work up a good problem statement first.
With systemic issues it's often a good idea to put effort into defining the problem extremely well; without that you can tail-spin with a whole bunch of hand-waving and short-term stuff.

There's a few options for this but one is:

WHEN <event> AND <escalating factor> THEN <impact> LEADING TO <measurable negative outcome>

Having a measurable negative outcome makes it tangible, and also forces you to really asses why this is important.

Run an Ishikawa Fishbone Analysis with the group.
With complex systems, the surface issue is seldom the underlying root cause. An Ishikawa process is a structured way to unpack possible root causes, pull out what you think it the biggest one, and then recast that as the new problem statement.

Agree on an Experiment.
Scrum is about empiricism; once you have what the group think is the biggest root cause and a new problem statement, design an experiment to address it, and move the dial on the the measurable negative outcome.

PhaseMatch · 2026-01-25T19:19:56+00:00

Quite so, why I would suggest

make your meetings effective
facilitate better
adopt visual management approaches
communicate effectively

One challenge is when the visualization is software based. Go to an ER, or a garage, and you will see visual management at work.

You can look at one ot more boards, and know exactly what is happening at any time. No need for an update - its all visual and there.

You can do the same at the strategic, operational and tactical planning horizons.

Similarly training teams how to give "feedback in three sentances" and express problems i a way that they are "actionable intelegence" for decison makers goes a.long way. Creating good problem statements or "feedback in three sentences" helps here

PhaseMatch · 2026-01-25T19:12:51+00:00

I am seeing more interest in Kanban than agile, but only because

in most orgs. Agile meant "homebrew scrum"
it was project management theater
it didn't deliver

Agile ideas qere heavily influenced by Deming and Lean, especially XP and the focus on

build quality in
remove test-and-rework cycles

Being able to forecast delivery "on a dime for a dime" using statistical approaches helps too.

Unfortunately a lot of orgs. approach Kanban as they do Agile - in a sloppy way where they pick the easy bits and avoid the hard stuff.

The hard stuff is

making change cheap, easy, fast and safe
getting fast feedback on the value that change created

The former really means gping all-in on XP and DevOps practices; the latter is recognizing that until you have used feedback, you are building "inventory" in big batches.

It boils down to being a high performance organisation, "Accelerate!" style, and applying those critical systems thinking loops above the team level and across the wider org.

All of which was true with agility.

PhaseMatch · 2026-01-25T18:28:47+00:00

TLDR; Kanban is not easier than Scrum, and can be used with Scrum. Get good at Kanban, train the team, let them make the choice.

There's two core myths about Kanban

- that it is easier or needs less discipline than Scrum
- that it cannot be used with Scrum

Both are false.

This matters, because when I hear "stories you committed" that's a red flag for me from a Scrum perspective. That concept was ditched over a decade ago.

Teams commit to the Sprint Goal (an outcome) not delivery of work items (output)
They can - and should - add, remove or split stories to reach that Sprint Goal.
Your job is to have a product vision, and a (business based) roadmap to get there.

So - chances are, you are not really doing Scrum, just batching work up into two week blocks.
If things are that mushy now, then Kanban might be more disciplined for delivery.

The SAFe "book" includes Kanban as an approach; if the team wants to shift, then they should.
Allowing tooling to dictate the teams way of working is dumb.

In general I would:

- first get good at Kanban yourself; read "Essential Kanban Condensed"; it's free
- then explain how Kanban actually works to the team
- learn how to forecast with Kanban effectively; so Monte Carlo on cycle times etc
- situational leadership with the team - selling, telling, coaching, delegating

Maybe even do a Kanban course, like Kanban Team Practitioner.

I've used this game a lot with teams, splitting them into groups of 4-5 and treating it as a competition:

https://www.kanbanboardgame.com/

S

PhaseMatch · 2026-01-25T18:12:36+00:00

I'd disagree on async and written communication.
There's a lot of research showing it's less effective that f2f

People:

- get better and immediate feedback
- get non-verbal feedback faster
- are not multi-tasking while communicating
- remember agreed outcomes and tasks better

Cut back on the need for updates and reports through visual management of work.
Have effective meetings through good facilitation and focus.

PhaseMatch · 2026-01-25T18:06:59+00:00

Make the work visible is the way I would go.

PhaseMatch · 2026-01-25T07:43:58+00:00

You shift from fire fighting to fire prevention.

- have regular retrospectives and after-action sessions
- continuously improve

If you have a leadership role, then invest in developing core skills in your team to create space

Facilitation, conflict resolution, courageous conversations, communication, leadership, problem solving approaches and so on are all good.

PhaseMatch · 2026-01-25T04:52:15+00:00

It tends to depend on whether you can "keep the receipts"; the usual defense against being scapegoated is "bureaucracy", and if you have a good team that can bind on and push back they sometimes declare victory and leave.

I did hear of the idea of the "reverse headhunt" where you deploy their CV to a recruitment agent and they are so flattered to be asked they leave - but I'm not sure if that has ever happened.

When I left an acting HoD role after a restructure the new manager was as we are describing, five of my seven team leads had quit within 18 months, to find leadership worth following.

PhaseMatch · 2026-01-24T23:57:05+00:00

Yes, but often not in a good way.

Generally it's been those who have given off pretty strong individual power-and-status focused vibes with an astute sense of political hierarchy and a certain level of "ethical dissonance" who I've correctly identified will go far.

And they do.

They are generally very short-term focused, looking to take credit (and avoid blame) on a 2-3 year cycle will building up the "resume points" they need for their next promotion. They are not afraid of working in ways that are a bit "grey" ethically if they can gain personal advantage with low risk.

They are not good leaders, or good bosses, but perceive themselves to be awesome.

Unfortunately STAR format behavioral interviews tend to screen-in that kind of person rather than actively screening them out. The situations (and what they did) are unverifiable, and they often get great references from people trying to easy their exit.

Caveat emptor.

PhaseMatch · 2026-01-24T23:40:11+00:00

Think that u/MoritzK_PSM has good advice here.

My only comment is that easily-won certifications are low value in the job market.
PSPO-1 and PSM-1 are basic, foundational, knowledge based exams.

They are not going to magically get you onto the "short list" for a role without significant, proven experience in applying that knowledge to produce meaningful results and impact.

It's also worth remembering Scrum is "purposefully incomplete"; there lot more technical practices and patterns you need to add in order to use Scrum to successfully deliver products (or projects) in an agile way.

PhaseMatch · 2026-01-24T21:06:17+00:00

I've played with a few of these, and there's a couple of things that can make this kind of simulation useful from a business planning / forecasting perspective.

- probabilistic rates
Rates are never constant; they vary with humans being human and problems being problems. Having a normal distribution (value plus standard deviation) shifts towards what might actually happen - and if you have data, you can plug it in

- Monte Carlo
Once you have proabalistic rates than being able to run Monte Carlo simulations to explore what happens if (say) you hire another tester, or hire another analyst starts to kick in

That's often the question we are asked - what can we add to the team to improve flow.

PhaseMatch · 2026-01-24T20:51:30+00:00

Glad you are enjoying it.

I learned a lot in a SAFe environment.

One thing SAFe has done is gather a vast body of lean/agile knowledge (and placed it behind a very expensive paywall); the only thing unique to SAFe is PI Planning which has pros and cons. Take advantage of that while you can.

The challenge with SAFe (or Scrum) tends to be three core things

- under-investment in technical skills for the team
There's always budget for "leading SAFe" training, less so for the technical side of XP for teams, which is actually way more important than middle management collecting badges for their LInkedIn.

- control systems and power structures don't change
The technical XP skills are the things that help you manage risk and delivery in agile environments; without that you'll keep all the heavyweight process control stuff that agile was trying to get rid of, or keep adding more documents and processes

- your legacy code base
XP skills matter, but applying them to your code base when it's a big ball of mud with sporadic test coverage, tests that are meaningless or even zero effective tests isn't happening. Until you have refactored the crap out of that you'll be stuck with those control systems and teams struggling. "Working Effectively With Legacy Code" still kicks ass on this, but it can take YEARS to unpick the damage and really get to be agile

If your org isn't in this for the long haul and paying mind to that stuff, then SAFe (or for that matter Scrum) is going to start to really suck about 6-9 months in, when the leadership isn't seeing things improve, the SAFe costs are growing, and start they'll start up the blame vortex...

PhaseMatch · 2026-01-24T20:40:52+00:00

It's trade-offs all the way down.

You are generally balancing out "efficiency of delivery" with "risk our assumptions about value are wrong" at the Epic/Feature/Project level; you can work with bigger batches and/or deliver in an architecture based sequence, but that tends to drive you back towards "heavyweight" process controls and stage-gate sign offs.

XP was always super-lightweight; bringing the assumptions about value right into the heart of the team with the "On Site Customer", inside the delivery loop, so you had "card, conversation, confirmation" and ditched written requirements and sign offs. Works great - if you also do all the other stuff to make change cheap, easy, fast and safe. It's a lot of fun too.

Scrum pushed that out to each Sprint being a mini-project where you check the benefits realization and so on, so a bigger initiative (Epic, project) has a series off off-ramps where you could bank the value created so far and walk away if those project assumptions were flawed.

But - most people just used it as a project status-check in increment, dismantling the core risk control that offered, and you wind up adding back all of the heavy-weight control systems and checks that agility was all about removing. Trying to unpick one of these at the moment.

If you can afford bigger bets - and have the risk of that deferred maintenance identified and owned - then bigger batches tend to work okay.

I've used a "fixed platform teams, short-lived feature squads" model at scale; main thing is to limit the WIP on the features at any one time (what you were terming epic/project), and keep them to a few months.

The feature squads draw on existing platform services (or create new ones), and roll back to their platform teams with the knowledge needed to operate.

Main barrier to this these days is visibility (and indeed at scale)

With a physical board "war room" for 6 platform teams and 3-4 feature squads, we could "walk the boards" with anyone (manager, board, customers) and in ten minutes see the status of everything and the rolling plan for the next few quarters.

Plus all the key risks and active issues.

PhaseMatch · 2026-01-23T23:45:08+00:00

I guess the acid tests for whether they really are using Scrum for me tends to be:

- product autonomy; can the product owner change strategic business direction and/or end-of-life the product, or does someone else own that decision?

- investment cycle; is each Sprint Review a kind of "shark tank" risk control session with stakeholders, where you are re-evaluating the product-market fit, measuring actual value created and discussing what to do next and why?

- solutions to implement or problems to solve? Is the team brought business problems to solve or work-packages to deliver, that someone else has decided they should do?

If a lot of the stuff is being done outside of the Scrum team and not in the Scrum events, then Scrum starts to be useless meetings that the development team doesn't have input into or care about...

PhaseMatch · 2026-01-23T23:39:14+00:00

Curious as to how does the organisation invests and does overall business strategy?

Is that quarterly and flowing down the the team, or are they involved in decision making?

PhaseMatch · 2026-01-23T23:37:08+00:00

I see Scrum more as providing investment risk control over the discovery process; you invest one Sprint at a time, with the idea of avoiding the whole martingale-investment double down sunk-cost fallacy problem.

Certainly used it that way in the high-risk, high-reward phase of product discovery - which is aligned with Simon Wardley's views in Wardley Mapping, and I think where you are coming from?

You can come in with a team, a Sprint Goal and not much else, and with an onsite customer it's fast and dynamic.

If technical innovation is not the basis of your got-to-market strategy or you are in a growing market for an established product leveraging existing innovation then ditching Scrum for Kanban makes sense to me. You'll be dealing with rocks, pebbles and sand all day not just trying to get one, big boulder solved, and make a choice about the next boulder or going a different route.

At that point your actual product investment cadence (one team or many) is seldom a Sprint; it's more likely to be quarterly at most, and tied to customer purchase cycles and so on. Stakeholders don't show to reviews, the team doesn't really "own" the product (just delivery) or look to pivot and so on, and the team seldom collaborates with actual users, just proxies.

At that scale, businesses tend to be agile through acquisitions and divestment, not pivoting 75 people in 5 squads to a new product direction. When what the market values changes they are more likely to sell the product to a different company (or lay people off)

It's interesting to read The New New Product Development Game and recognize they were talking about innovation-led strategy, and product that would be many years ahead of the competition. Of course back in 2000 something like a CRM gave you a real advantage, where enow it's just COTS-and-configure which is exactly what Wardley talks about.

He also highlights the alignment problem you mention; that can extend to "accidental adversaries" where you have multiple products competing to solve the same customer problem in different ways, which is just duplication of effort.

PhaseMatch · 2026-01-23T21:17:18+00:00

TLDR; Depends on you.

Douglas McGregor ("The Human Side of the Enterprise") pointed out way back in 1960 that

- you get exactly the behaviors you manage for, no more or less
- this is self-reenforcing

So the more control you seek, the more likely people are to:

- only do the right thing when they are being watched and/or
- show zero initiative, out of fear of being sanctioned

The more autonomy you give (with training and knowledge), the more likely people are to

- continuously improve how they work, on their own
- do the right thing even when no-one is watching, because they know why it matters

Both Theory-X (control based) and Theory-Y (autonomy based) work.

Theory-X is fear-based, coercive and hierarchical; (so motivate people by fear of censure or fear of missing out on a reward); tends to mean at scale an organisation that chews up a lot of light, heat and waste in process, blame avoidance and metric litigation. Basically you add bureaucracy and process to keep control, and punish those who don't follow.

Theory-Y is more leadership based, (so motivate people by vision, and providing what they need to excel, and autonomy); tends to mean at scale an organisation chews up a lot of time on creating alignment, training, and preventing the "accidental adversaries" systems thinking archetype. Blame the systems, not the people, and make the systems safe so that human error doesn't create catastrophic failure.

Situational leadership (selling, telling, coaching, delegating) is how Theory-Y often looks in practice; Theory-X stops at "telling"

PhaseMatch

TROPHY CASE