Big Agile

11/02/2026

Every team seems to have one: the engineer who reviews everything. Fastest in the building. Everybody asks for her.

And slowly, everybody ends up waiting on her too.

This week Lance Dacy talks about why your best reviewer can become your biggest bottleneck, and the simple two-part fix we use with teams: smaller pull requests, and one named reviewer per pull request that rotates.

Watch the episode or read the article.

Your fastest code reviewer may be your biggest delivery risk. Cap pull request size and rotate one named reviewer so reviews stop depending on one person.

10/30/2026

Whatever goes on your leadership slide is what people will push. We've heard that in many languages and flavors.

This week's Next-Gen Agility is for the people who build that slide. It argues that you don't fix a gamed metric by watching it harder; you fix it by giving it company.

It covers what DORA's metrics guide says about measuring in sets, why the idea goes back to a 1992 Harvard Business Review article, which of its champions sell measurement, and the two leadership moves that decide whether a balanced board gets used.

Who in your organization is allowed to bring the uncomfortable number to the review?

Link: https://www.linkedin.com/pulse/give-your-gamed-metric-some-company-lance-dacy-fi9cf

10/28/2026

Look at the number your team gets praised for, the one that earns a slide. What sits next to it?

If the answer is nothing, it's a target to game, and it can't tell you when your team has become the exception.

Today's guide carries the Balanced Signal Board, a starter template you can copy. Every delivery metric gets two neighbors: an experience signal for what the number costs the people producing it, and an outcome signal for whether a customer or the business noticed. Each row carries one note, written in advance: if somebody games this number, which axis moves? 'Nowhere yet' is an answer.

Measuring in sets that pull against each other isn't my idea. DORA's metrics guide recommends it, and Kaplan and Norton's balanced scorecard argued it for executives long before. The pairings on the board are my practice, a starting point and not a standard.

What does your team's headline number cost the people producing it?

https://big-agile.com/blog/balanced-engineering-metrics

10/26/2026

A team we worked with started shipping 30 times a day. Great chart. Big milestone.

Their incident rate climbed right along with it, and nobody put that on a slide. It showed up as a 2 a.m. phone call instead.

This week Lance Dacy explains why one metric on its own is easy to game, and shares the simple board we use with teams to pair every delivery number with what it costs the people doing the work and what customers actually notice.

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

10/23/2026

A velocity chart books every feature as an asset.

Nothing on it books the liability: the copied function, the helper nobody consolidated, the module that got a little harder to change.

Today's newsletter is for the leaders who fund the work.

It reads GitClear's 2026 data, a second vendor's study, an independent academic study, and the counter-study, and lands on what I'd change (or actually do change) in a planning process so maintenance gets funded on purpose.

Who on your leadership team would notice first if the maintenance line went to zero?

Link: https://www.linkedin.com/pulse/cheapest-code-write-can-most-expensive-own-lance-dacy-3jydc

10/21/2026

Generating a new function can take seconds. Finding the one that already exists, understanding it, and folding your change into it still takes a conversation.

When one of those is nearly free, refactoring starts to feel optional. I rarely see a team write down what skipping it costs.

Today's guide hosts a free tool, the Refactoring Ledger. Run it on last sprint with your team, using only your pull requests and your backlog, and book each entry: inside new work, as a redesign item, as a working agreement to refactor mercilessly (the Extreme Programming practice), or as a deliberate loan you write down. No code-analytics product required.

Speed that you don't refactor is not throughput. It's a loan with a hidden rate.

If you run it, tell me which booking came up most.

https://big-agile.com/blog/ai-technical-debt-refactoring

10/20/2026

When someone tells me they want their CSPO and still haven’t booked it, it's rarely the price. It’s the time. Two days away mid-sprint is a hard sell to your manager, and a harder sell to yourself.

So check the time zone on my November 9 class. It’s scheduled for Australia, which puts it at 6:30 to 10:00 p.m. Central, Sunday through Wednesday evenings. Four evenings, no PTO, and you leave with the Certified Scrum Product Owner credential from Scrum Alliance.

Same class. Same exercises. Same me asking uncomfortable questions about your backlog. Just at an hour when your team isn’t waiting on you.

If daytime works better, my CSM runs November 12 and 13 (Eastern), and there are more CSPO and CSM dates in December. Early pricing is available right now.

Link: https://big-agile.com/events

10/19/2026

A team's velocity chart has never looked better. The roadmap is on track and the stakeholders are happy.

But in six weeks, that team made exactly one refactor.

Is that team fast, or is it borrowing?

This week Lance Dacy explains why skipped refactoring works like a loan, how the interest shows up (hint: the same bug, twice), and how to plan your team's capacity so the debt gets paid on purpose.
https://big-agile.com/blog/skipped-refactoring-is-a-loan

10/16/2026

A board asks what our development tools paid back. When engineering answers with how much the tools produced, I think we are answering a different question than what was asked.

That gap isn't a ledger or spreadsheet problem. I think it's a measurement problem, and this week's Next Gen Agility is about the numbers that close it and the claims a CFO will actually accept (in their language).

Who owns the ROI slide in your organization: engineering, finance, or nobody?

Newsletter: https://www.linkedin.com/pulse/your-ai-roi-problem-might-measurement-lance-dacy-af4oc

10/14/2026

Lines of code shipped would have climbed even if the AI tools had made delivery worse. Fixing defects is code too.

Keep it on a team dashboard as one signal among several. On the ROI slide, it needs a partner that can go down.

Today's guide hosts a free tool, the ROI Slide Swap. It takes each output number your team reports as return, pairs it with a flow or stability metric from DORA's software delivery metrics that could carry the claim, and flags which numbers are easiest to game. It computes no ROI and deletes nothing.

Where does lines of code shipped live in your organization today: on the ROI slide, a team dashboard, or both?

https://big-agile.com/blog/ai-roi-engineering-metrics