Big Agile

09/02/2026

A pilot that stalls does not fail. Failing is quick and you learn something on the way out. Stalling is the one that keeps its login and its budget line while the follow-up meeting quietly stops appearing on the calendar.

Six months later the honest answer to what happened to it is that nobody knows.

Wednesday's guide carries the Pilot-to-Production Readiness Checklist. Five sections: ownership, outcomes, decision rights, escalation, evidence. Who runs this in production by name. The one business result it has to move. Who can change it, pause it, or kill it. Who gets paged the night it fails. And what would count as it working, agreed before anyone scales anything.

It is a gate, not a rubric. All five filled, or the pilot does not graduate. No score, no readiness percentage, nothing ranked against anything else, because a score lets you pass with a gap.

Not graduating is not the same as being killed. It means the thing keeps running as a pilot, with a pilot's budget and a pilot's blast radius.

Blank checklist plus a worked example that fails its own gate: https://big-agile.com/blog/pilot-to-production-readiness

My bet is the blank section is escalation. Which would yours be?

09/01/2026

For years, Agile for Leaders has only run behind closed doors. A company brings me in, we spend a day with
their leadership team, and the people who need it most finally hear the part nobody says out loud: your
transformation is not stalling because your teams cannot learn Scrum. It is stalling because of what leaders
do, and stop doing, at each stage of the journey.

Enough of you have asked whether you can just come to it. So I am opening a public cohort.

No pitch today. If you lead teams, or you lead the people who lead teams, and you want a day that is honest
about what agility actually asks of you, get on the interest list. I will use the interest to set the date and keep
the room small.

This is not a certification course. It is a mirror.

Interested: https://big-agile.com/agile_for_leaders

08/31/2026

The demo worked. "This changes everything." Applause. Then six months later nobody can tell you what happened to the tool.

That's pilot purgatory, and this week Lance breaks down why AI pilots stall after the demo. Short version: it's almost never the model. It's that nobody owns the part that comes next.

He lays out the five ownership loops that decide whether a pilot ships, and a simple test you can run on any pilot this week.

Watch or read the full episode. Lhttps://big-agile.com/blog/nobody-owned-the-pilot-after-the-demo

Your AI demo wowed the room, then went nowhere. That's pilot purgatory. Pilots stall on ownership, not the model. Here are the 5 loops that get them shipped.

08/28/2026

There is a version of the visibility conversation that never reaches the leadership team because it does not appear to be a leadership problem.

It arrives looking like a tooling problem, and tooling problems get delegated.

But what decides whether a metric is worth producing at all is a decision right, and decision rights do not live in the reporting layer. They live where somebody can say no.

This week's LinkedIn Newsletter walks through a vendor survey in which the same block of questions reports both a quality problem and a quality success, what two consecutive years of DORA research actually support about AI and delivery stability, and why the most telling number in the whole report is the one about how involved executives are.

It ends somewhere I expect to get argued with: a term I coined, tested against the same audit I would apply to any dashboard, and then declined.

What is the last metric your leadership team retired, and what did it cost you to keep it that long?

Newsletter: https://www.linkedin.com/pulse/you-cannot-delegate-decision-dashboard-lance-dacy-1fsqc

08/28/2026

We have a good-sized group registered for next week's Certified ScrumMaster® workshop, and there is still room for a few more.

The best CSM classes I have run were never the ones where I talked the most. They were the ones where a Scrum Master out of healthcare, a product person out of logistics, and a team lead at a bank realized in the same breakout that they had the same problem and three completely different ways of handling it.

None of us is smarter than all of us. A room with more perspectives in it is a better room, and everyone in it gets more for the same two days.

September 2 and 3, 9:00 to 5:00 Eastern, live online. Sixteen hours. You leave with the certification, 14 PDUs, and 16 SEUs. Mostly, you leave with a way to think about the room you walk back into on Monday.

I have been training and coaching Scrum teams since 2008, from Fortune 20 companies to startups that did not survive. Plenty of scar tissue, and I will show you where it came from. Come join a good, healthy group of debates and learning next week!

Link: https://big-agile.com/certified-scrummaster,

08/26/2026

Every dashboard on your wall is a claim: that it changes what somebody decides. Most of them have never been asked to prove it.

That is not a data problem. A chart used to cost somebody real work to build and keep alive, and that cost quietly killed the metrics that were never going to earn their keep. A rollup is one prompt away now. Nothing filters, so the wall grows and the decisions do not.

Wednesday's guide carries the Dashboard-to-Decision Audit. One record per metric, five lines: METRIC, READ BY, LAST CHANGED, IF GONE, VERDICT. It ends in keep, cut, or merge, with one rule to keep everyone honest: a metric that has not changed a decision in 30 days is a candidate for removal. A candidate, not a removal, with a case to answer.

Guardrail metrics get the one exception, and IF GONE is the line that saves them.

Blank template plus three worked examples, one cut, one merge, one keep: https://big-agile.com/blog/too-many-dashboards-not-enough-decisions

Pick your most-watched dashboard and name the last decision it changed, and when. If you can name one, I want to hear it. That is the version of this nobody posts about.

08/24/2026

Even the dashboards have a dashboard now.

We've never had more visibility into how we build software, yet the people running those systems say delivery keeps getting harder. That's the visibility paradox, and it's getting worse because AI made producing another chart nearly free.

This week Lance hands you a simple 5-line audit to find the dashboards you keep but never actually act on, and the one rule that keeps everyone honest.

Watch or read the full episode. Link in the comments 👇

08/21/2026

I think our delivery organizations have two capacities. We typically staff only one of them.

The capacity to produce a plausible change is now close to free, and it is the one every dashboard reports. The capacity to look at a plausible change and decide whether it is right is finite, concentrated in a handful of people, and appears on no plan I have seen this year.

This week's issue is about what changes when a leadership team starts treating verification as a real capacity: who owns the number, what it costs to cap intake, and why celebrating raw output is now a measurement failure rather than a culture win more than ever.

Link: https://www.linkedin.com/pulse/verification-capacity-start-planning-like-one-lance-dacy-jsvhc

08/20/2026

Tomorrow morning, I am teaching AI for Scrum Masters Scrum Alliance Credential, and there are still seats.

I do this because most Scrum Masters I meet are already using AI. They are pasting retro notes into a chat window and hoping something useful comes back. That is not a workflow. That is a coin flip.

In one day, we fix that.

Prompt anatomy that actually holds up under real team context. Turning raw survey and retro data into something you can act on. Automated sprint summaries and refinement support. And the part almost nobody teaches, the guardrails: bias checks, hallucination spotting, and where the human stays in the loop.

You leave with a one-sprint experiment plan and a toolkit you can use on Monday.

Friday, August 21, 8:00am to 3:00pm CDT. Live online. $295. Co-designed with Scrum Alliance.

If you have been telling yourself you will get to AI later, later is tomorrow. Use GROUPPE code for 20% off.

Register: https://big-agile.com/ai-for-scrum-masters -workshops

08/19/2026

I ask teams how many changes they can genuinely review in a week, and I almost never get a number back- blank stares, LOL, no numbers.

What I get is a headcount and a feeling that review is busy.

That is not carelessness. Review capacity is genuinely hard to see. It sits on no balance sheet, it shows up in no burndown, and the people doing it are usually doing something else at the same time.

But once generation is cheap and verification is not, the capacity that nobody can see is the one that sets your delivery speed.

"Almost right" code is the expensive kind. It compiles, the tests pass, and somebody still has to decide whether it does what you meant.

Wednesday's post hands you four numbers that produce a ceiling: what your team can genuinely verify in a week. It also says plainly what it will not calculate for you, because a small honest number beats a large fragile one.

Try this first. Write down what you think your ceiling is. Then compute it. The distance between those two is the part worth talking about.

Link: https://big-agile.com/blog/verification-is-the-new-bottleneck