The first was a study. Stephen Poletto’s team at Span looked at 248,099 pull requests and 65,697 production incidents and went hunting for the headline everyone expects by now: does AI write buggier code? They couldn’t find it. AI authorship, on its own, wasn’t a statistically significant driver of defect rate. The teams shipping AI-assisted code cleanly and the teams shipping it into a dumpster fire had the same AI. What separated them was everything around the AI — review discipline, ownership boundaries, how much room they left for refactoring, whether anyone capped the size of a pull request.

The second was a reflection. Jamie Sharp wrote about learning to build software in the early 2000s, when “design was the work” and “the code was an artifact” — when engineers shared a vocabulary of patterns and watched complexity on purpose. His worry about now isn’t that the tools got worse. It’s that we quietly decided the standard was optional: ask an agent to “build the thing,” accept whatever comes back, ship it. No spec, no design, no bar the output has to clear. His line stuck with me: the tools didn’t lower the bar — we did, by deciding the bar was optional.

One post is data. One is memory. They point at the same conclusion. The quality problem people blame on AI isn’t coming from the AI.

The patterns didn’t go anywhere

Here’s the part that should be reassuring and is mostly just inconvenient: every practice that made code good before still makes code good now. Single responsibility. Clear boundaries. Dependencies pointing the right direction. Small, reviewable changes. Tests that double as design feedback. None of that got repealed. Span’s findings are basically a measurement of those practices — the teams with PR discipline and real ownership are the ones AI made faster, not messier.

What changed is that the patterns stopped being automatic. For twenty years they rode along inside the act of typing. You couldn’t write a class without deciding what it was responsible for, because you had to write every line of it. The friction did some of the thinking for you. Generation removed the friction, and it took the accidental discipline with it. The patterns are still sitting right there. They’re just no longer free.

AI is a junior dev who never internalizes anything

The mental model I keep coming back to: an AI agent is the most capable junior developer you will ever work with, and also the one who will never, on its own, develop judgment.

A good junior gets a vague ticket, takes a swing, and hands you something that works and is shaped wrong. You don’t conclude the junior is hopeless. You tell them: this method’s doing three things, split it; this reaches into another module’s internals, pass it in; this needs a test, and if the test is hard to write, the design is the problem, not the test. Say it enough times and a human junior starts doing it before you ask. That’s what “getting more senior” is — internalizing the standard so it stops needing to be said.

The agent never makes that move. It will apply every pattern you name, cleanly and instantly, and forget to apply a single one you didn’t. It has no standard of its own to fall back on. Which means the standard has to come from you, every time, out loud. The teams getting great results aren’t using better models. They’re the ones still doing the senior half of the job — naming the patterns the agent should follow, the way they’d direct a junior who hasn’t learned them yet.

Garbage in, garbage out — now at full speed

“Ship the thing” is a garbage prompt, and it produces exactly what it asks for: code with no spec to satisfy, no design to honor, no bar to clear. It compiles. It might even pass tests. And, in Sharp’s words, nobody — human or agent — can safely change it later, because there was never a design to change. That’s not an AI failure. Feed that brief to a contractor and you’d get the same slop, just slower.

Flip the inputs and the output flips with it. Tell the agent the responsibility each piece owns. Point it at the seam you actually want. Hand it the constraints a good reviewer would enforce anyway. Cap the change so the review surface stays human-sized — Span singled this out, because the one thing AI reliably does inflate is PR size, and a giant diff is where review quietly stops happening. Same model, same afternoon, completely different code. Garbage in, garbage out is not a new law. AI just removed the wait between the garbage going in and coming back out, which makes the quality of your inputs the whole game.

The bar is a choice you make on purpose now

I’ve written before about treating AI like a pair who types at 300 words a minute, not a lead architect — letting it draft, then spending ten minutes on responsibilities, boundaries, and names before anything merges. That checklist matters more now, not less, because the thing it’s really defending is the bar itself. The discipline used to be enforced by how slow writing code was. It now has to be enforced by you, deliberately, against a tool whose entire appeal is that it removed the slowness that used to enforce it.

That’s the uncomfortable shift hiding inside both posts. The standard didn’t move and the patterns didn’t expire. They just lost their free ride. Holding the line on code quality is no longer something that happens to you while you work — it’s a decision you make, out loud, on every change, or it doesn’t happen at all.

So the question Sharp leaves you with is the right one to sit with: are you using these tools to ship faster, or to skip the part of the job that was always the actual job? The good news, and the Span data backs this up, is that the teams who kept doing the actual job are the ones pulling ahead. The patterns work. They always did. You just have to ask.

— Roger

Further reading

• Poletto, Stephen. “We looked at 248,099 PRs and 65,697 production incidents.” — the Span study finding that AI authorship isn’t the defect driver; the engineering environment around it is.
• Sharp, Jamie. “When I learned to build software in the early 2000s…” — on design as the real work, and the bar we decided was optional.

No new business logic. No deploy carrying a behavior change. The same code that had been running quietly in production for ages now fell over on cold start, crashing before it could handle a single request. The logs pointed at something deep in startup, and the first instinct — the wrong one — was to go hunting through our own code for what we broke.

We didn’t break anything. That’s the unsettling part, and it’s also the whole story. The worst production bugs aren’t the ones where someone shipped a bad line. They’re the ones where the ground shifted underneath code that never moved.

Three suspects, none guilty alone

It took my team a while to accept the shape of this bug, because it doesn’t have a single cause. It has three. Each one, on its own, was completely fine. They had coexisted happily for a long time. The crash only appeared when all three lined up at once — and the day they lined up, nobody on the team had done anything to make it happen.

Here are the three suspects.

Suspect one: AWS quietly updated the runtime

The function runs on the managed .NET 8 Lambda runtime. AWS owns that runtime, patches it, and rolls out new builds on its own schedule. At some point it moved to a newer build (dotnet:8.v88).

That newer runtime ships its own AWS bootstrap library — the glue that sits between Lambda’s execution environment and your handler. And the new bootstrap was built against a newer Amazon.Lambda.Core, one that introduces a brand-new type: ILambdaResponseStream.

This is normal. Runtimes get updated. New types get added. Nobody asked us, and nobody needed to. From AWS’s side, this was an ordinary improvement.

Suspect two: our bundled library was older

Our function still bundles Amazon.Lambda.Core 2.8.1. That version does not contain ILambdaResponseStream. My team confirmed it the tedious way — by inspecting every installed version of the library up to 2.8.1. None of them have the type.

So now there are two copies of the same AWS library in play: the newer one AWS brought with its updated runtime, and the older one we packaged ourselves. They disagree about which types exist.

On its own, this is still harmless. A version skew like this sits dormant all the time. Two libraries can hold slightly different views of the world and never collide — right up until something forces them to be reconciled. Nothing in normal operation reads every type in every loaded assembly.

Until something does.

Suspect three: the upgrade that made everything strict

The third suspect is the only thing that actually changed on our side, and it looked completely innocent: a routine dependency-upgrade PR that bumped AutoMapper (and, alongside it, MediatR).

Both of those libraries work by scanning assemblies at startup to discover what they need — AutoMapper looks for mapping profiles, MediatR looks for handlers. And the way we’d wired them up, we asked them to scan every loaded assembly. That’s a common pattern, and it had worked for years.

But “every loaded assembly” includes AWS’s runtime bootstrap library. When the upgraded AutoMapper walked that library and tried to enumerate its types, it hit the reference to ILambdaResponseStream — a type that lived in the newer Amazon.Lambda.Core but not in the 2.8.1 we’d bundled. The reference couldn’t be resolved, the type load blew up, and because this happened during startup scanning, it took the entire function down with it.

The detail that makes this maddening: before the upgrade, the scan tolerated this. The older scanning behavior shrugged at a type it couldn’t fully resolve. The new version is stricter. Same instruction from us — “scan everything” — but now “everything” was enforced to the letter.

So that’s the full collision. A new AWS runtime brought a library with a new type. Our old bundled library lacked that type. And a newly strict scan insisted on reading every type in every assembly, including AWS’s. Remove any one of the three and there’s no crash. Put them together and startup dies.

The fix

Once the cause is clear, the fix is almost boring — which is exactly what you want from a root-cause fix.

AutoMapper and MediatR never had any reason to inspect AWS’s internal runtime libraries. There are no mapping profiles of ours in there. There are no handlers of ours in there. We were asking two of our libraries to rummage through infrastructure we don’t own, looking for things that could only ever live in code we wrote.

So we stopped doing that. Instead of scanning every loaded assembly, we scan only our own:

// Before — scans EVERY loaded assembly, including AWS's runtime libraries
services.AddAutoMapper(AppDomain.CurrentDomain.GetAssemblies());
services.AddMediatR(cfg => cfg.RegisterServicesFromAssemblies(
    AppDomain.CurrentDomain.GetAssemblies()));

// After — scan only our own assemblies
var ourAssemblies = AppDomain.CurrentDomain.GetAssemblies()
    .Where(a => a.GetName().Name?.StartsWith("YourApp.") == true)
    .ToArray();

services.AddAutoMapper(ourAssemblies);
services.AddMediatR(cfg => cfg.RegisterServicesFromAssemblies(ourAssemblies));

(That’s illustrative — your filter is whatever prefix your own assemblies share — but the shape is the point.)

No functional behavior changes. The mappings and handlers that mattered all live in our assemblies, so narrowing the scan finds exactly the same set of them. The build passes cleanly. And as a bonus, the function is now immune to this entire class of problem: AWS can update its runtime, swap its bundled libraries, and add as many new types as it likes, and our startup scan will never look at any of it.

The lesson

The narrow, technical takeaway is simple: scan only what you own. When a library discovers your types by reflection, point it at your code, not at the whole process. Reaching into assemblies you don’t control to find your own mappings is asking to be surprised by someone else’s release notes.

The broader lesson is the one I keep relearning. Dangerous production bugs are usually combinations, not single causes. Each ingredient here passed its own review. The AWS runtime update was correct. Our bundled library version was fine. The dependency upgrade was a clean, sensible bump. There was no bad commit to find, because the bug didn’t live in any one change — it lived in the intersection of three.

And “nothing changed” is almost never true. Our code didn’t change, but the environment it runs in did, and a managed runtime is part of your dependency graph whether you think about it that way or not. Latent version skew is sitting in most systems right now, invisible, waiting for something to force every type to be enumerated. The upgrade that finally did the forcing got the blame, but it was only the third domino.

The fix took just minutes. Understanding why three innocent things added up to a crash took longer — and was the part actually worth writing down.

— Roger

Last week I argued that AI didn’t kill Agile — it moved the constraint: when building got cheap, the bottleneck slid downstream from can we build it? to can anyone actually absorb it? I made the case that Jobs to be Done is how you decide what to point all that cheap capability at. But I left a thread hanging on purpose. Knowing which job to chase tells you where to aim. It says nothing about how fast an organization can actually take the hit.

That second number — the rate — is the whole game now. And a guy in a 1984 business novel already told us how it works.

Goldratt’s uncomfortable little rule

Eliyahu Goldratt’s Theory of Constraints is almost annoyingly simple. Any system has exactly one constraint at a time — one step that sets the pace for the whole line. The throughput of the entire system is the throughput of that one step. And here’s the part people hate: improving anything that isn’t the constraint does nothing for the system. It just feels like progress.

For twenty years, engineering was the constraint, so every productivity gain there was real — it moved the whole line. That’s the muscle memory we’re all still running on. Make the developers faster, ship more, win.

Then we made building cheap, and the constraint moved. It’s now sitting squarely on the organization’s ability to absorb change. Which means most of the effort we’re still pouring into building faster is, in Goldratt’s terms, optimizing a non-constraint. It feels like progress. It produces a graveyard.

Building faster just grows the pile

Here’s the mechanism, because it’s the part that matters. In a factory, when you run a non-bottleneck machine flat out, you don’t get more finished product. You get inventory — half-built stuff stacking up in front of the slow step, going stale, tying up cash, hiding problems.

Swap “inventory” for “unadopted capability” and you’ve described every AI initiative graveyard I’ve ever seen. The forty-one tools. The pilot that never rolled out. The copilot with twelve daily users out of four thousand seats. That pile isn’t evidence of productivity — it’s work-in-progress stacked in front of the constraint, quietly rotting. Goldratt’s line was that an hour saved at a non-constraint is a mirage. A tool shipped past your absorption limit is worse: it’s a mirage with a maintenance cost.

The move nobody wants to make

Theory of Constraints is blunt about what comes next. Once you’ve found the constraint, you subordinate everything else to it. Every other step runs at the constraint’s pace, not its own — deliberately, even when it could go faster.

Translated, that’s a genuinely unpopular instruction: stop pushing capability into the organization faster than the organization can absorb it. Cap how much change is in flight at once — a WIP limit, but for transformation instead of tickets. Let the edge pull the next capability when it has digested the last one, instead of a central team pushing a firehose just because the firehose is cheap now.

This cuts against every instinct we built during the scarcity years, when the cardinal sin was an idle engineer. The idle engineer isn’t the expensive thing anymore. The half-absorbed change is.

Adoption has a speed limit, and it’s human

Why can’t you just turn the rate up? Because the constraint is people changing how they work, and Everett Rogers mapped that curve sixty years ago. A new way of working spreads through a population at a rate — innovators first, then early adopters, then the majority dragged across one reluctant cohort at a time. You can grease it. You cannot skip it. Push harder than the curve allows and you don’t accelerate adoption; you manufacture resistance, which is negative progress.

That’s the thing a dashboard full of shipped-feature counts will never show you. The capability side is now effectively infinite. The human side moves at the speed of trust, habit, and how much disruption a team can hold before it stops doing its actual job.

You can raise the ceiling — slowly

The good news, such as it is: the constraint isn’t fixed. Goldratt’s last step is to elevate it — invest until it’s no longer the bottleneck. But absorptive capacity, the way Cohen and Levinthal described it, is not something you buy in a quarter. An organization’s ability to take in something new depends on what it already knows and how well it’s wired to spread that knowledge around. It compounds. The teams that can absorb fast in 2026 are the ones that built the muscle in 2024.

So elevating the constraint is real work, and most of it is unglamorous: putting engineers at the edge to lower the anxiety and break the habit — the forces I wrote about last time — building the connective tissue that lets one team’s adoption teach the next, and treating can we absorb this? as a capability you invest in rather than a thing you assume. That’s the actual leverage point now. Not another model. The metabolic rate.

Where this leaves you

The first post was about finding the bottleneck. This one is about the discipline that finding it demands: stop optimizing the thing that is no longer the constraint. Building was the hard part for so long that we’ve mistaken it for the point. It isn’t anymore.

The teams that win the next few years won’t be the ones generating the most capability. They’ll be the ones who matched their build rate to their absorption rate, defended that limit when it felt like leaving speed on the table, and spent their real energy raising the ceiling one compounding quarter at a time.

Goldratt would have found the whole thing familiar. We just gave the bottleneck a new address.

Further reading

• Goldratt, Eliyahu M., and Jeff Cox. The Goal: A Process of Ongoing Improvement. North River Press, 1984. — the original Theory of Constraints, delivered as a factory novel.
• Rogers, Everett M. Diffusion of Innovations. Free Press, 1962 (5th ed., 2003). — the adoption curve and how new practices actually spread through a population.
• Cohen, Wesley M., and Daniel A. Levinthal. “Absorptive Capacity: A New Perspective on Learning and Innovation.” Administrative Science Quarterly 35, no. 1 (1990): 128–152. — why an organization’s ability to absorb the new depends on what it already knows.

Two nights at Leech Lake. Here’s how it went.

The Weekend

Another Corps of Engineers campground, another reminder that the COE quietly runs some of the best campgrounds in the country. Leech Lake Recreation Area was excellent — well maintained, genuinely quiet, and the bathrooms and showers were clean the entire weekend. Site 15 had everything we needed and then some. If you’ve been reading along, you know I have a soft spot for these places, and Leech Lake did nothing to change that.

The weather was the headline, and not in the way you’d expect for mid-June. Cloudy and cool the whole time, with a high of only 58°F on Saturday. No rain, though — which, after the Winni weekend got rained on for two days straight, I’ll take cool-and-dry every single time. And here’s the thing: 58 degrees and overcast is husky heaven. Echo and Dee were in their element. No panting, no hunting for shade, no frozen-water-bottle babysitting. They just got to be sled dogs in the woods for two days, which is all they’ve ever wanted out of life.

One repeat heads-up from the last trip: no firewood sold at the campground itself. There’s a gift shop across the highway that sells bundles — we grabbed two, both good and dry. Fair warning, though: they burned fast. Two bundles didn’t even cover late Saturday afternoon into the evening. Next time I’m buying more than I think I need, and then some.

The paddleboards stayed home this time. I’d been watching the forecast all week, and once it locked in at 58 and cloudy with mid-60s water, the call made itself. No sense hauling the Paddle Norths four hours round-trip to look at them. They’ll get their weekend.

The Saturday Drive

Saturday afternoon we pointed the truck north and drove from the Leech Lake dam up to Lake Winnibigoshish. If that name rings a bell, it’s because Echo and I camped on Winnie over Memorial Day — but this was the other side of the lake, which was fun to see. Same big water, completely different angle on it.

On the way we found some forest trails worth poking around on. We ran 91 to 2348 to 2948 and back to 91 — an easy loop overall. Like a lot of the routes out here right now, everything’s lush and green, with a few puddles scattered along the way. Nothing deep, but enough to keep things interesting. Some ruts here and there, but nothing a stock vehicle can’t handle. The one knock: a few stretches were a bit narrow for a full-size R1T — branches reaching in close, not a lot of room to swing wide. We managed fine, but a Tacoma-sized rig would’ve been happier in spots. Quiet out there, too — we passed exactly one other party, an ATV, the whole time.

Saturday evening we didn’t do much of anything, and that was exactly the plan. Built a campfire, made s’mores — which were excellent — and let the camp go quiet around us. The FireCan rode along as insurance in case campfires were banned, but the fire ring was open, so it never left the truck. Always nice to have the propane backup and not need it.

What’s Working Well

Thermacell Zone repellers. I went into this trip braced for the usual Chippewa National Forest mosquito assault, and it just… didn’t materialize. Partly the cool weather, sure, but the Thermacell Zones earned real credit. Set them around the site and the bugs basically left us alone. After years of swatting my way through northern Minnesota Junes, this felt like cheating.

Cool weather for the dogs. I’m filing this under gear even though it’s just the sky. June heat is the thing I worry about most with two huskies, and this trip removed the worry entirely. If I could special-order 58 and cloudy for every summer trip, I would.

The R1T off the pavement. The truck continues to be a fantastic basecamp and a capable trail rig. Those forest roads up by Winnie were an easy outing, but it’s nice to be reminded the R1T will happily go find the puddles when you point it that way.

What Could Be Better

JetBoil Genesis Basecamp. This is the real gear story of the weekend, and not a happy one. I could not get the thing to stay lit. The included windscreen is supposed to snap into place and it just wouldn’t seat right, and the burner kept dying on me. The Genesis was supposed to run the Dutch oven for Saturday’s planned ribeyes-and-cheesy-potatoes dinner, and with the stove being uncooperative I bailed on that whole plan (more on the menu pivot below). I’m going to pull it apart on the bench this week and figure out what’s going on — could be the windscreen, could be the regulator, could be me. I’ll report back once I’ve diagnosed it.

That firewood burn rate. Not a complaint about the wood — it was dry and good. Just a planning note to myself: two bundles isn’t even one full Saturday afternoon-into-night. Buy extra.

Late start, skipped meals. Minor, and honestly fine, but we got a slow start Saturday and a couple of meals fell off the board (see below). No regrets, but if I’d wanted to hit the full menu I’d have needed to move quicker in the morning.

The Menu

So the meal plan I packed and the meal plan we actually ate diverged a bit — which is camping. Here’s what really happened.

Friday

• Dinner — Beer-braised brats with grilled peppers and onions, plus baked beans. Exactly as planned, and exactly what you want after a three-hour drive.

Saturday

• Breakfast — Loaded breakfast burritos (sausage, peppers, onions, hash browns, eggs, cheddar). As planned, and a strong start to the day.
• Lunch — Skipped. Late start, and we were out chasing trails.
• Dinner — Chicken Caesar wraps. These were supposed to be Saturday lunch, but with the JetBoil refusing to cooperate, I promoted lunch to dinner and kept things simple. No shame in lunch-for-dinner.
• Dessert — S’mores, and they delivered.

Sunday

• Breakfast — Skipped. We packed up and got on the road instead.
• Lunch — The Deerstand on the drive home. Stop here. The ribs and the burger were both excellent, and there’s a great outdoor space where Echo and Dee could hang out while we ate. Highly recommend if you’re passing through.

As for those Saturday ribeyes that never got cooked at camp — they came home with us and got the proper treatment Sunday evening, once everything was unpacked. Smoked low on the Traeger, then finished with a hard sear on the grill, with corn going alongside. Honestly? They might’ve been better off for the delay. Reverse-seared ribeye in your own backyard with the gear cooperating beats a balky JetBoil any day.

The Whole Crew

Last trip I closed by listing who I missed — Dee OhGee stayed home, and Jayson was off in Chicago. So it feels worth noting that this time everyone was here. Jayson, Echo, and Dee, all in the woods, all in the cool air, all where they belong. Two huskies who got to actually be cold for once, a husband to share the fire with, and a quiet site under a gray northern sky. That’s the trip I was hoping for back in May, and this was it.

That’s Leech Lake. The JetBoil and I have a date with a workbench this week, and the boards are still dry, so they owe me a paddle.

Up next: Forestville Mystery Cave State Park. Should be a fun one.

More to come — here and on Mastodon. Thanks for reading.

That silence is the whole story of AI and Agile right now. We got very good at building things, very fast. We did not get any better at the part that comes after.

A lot of people have read that silence as proof that Agile is finished — that sprints and backlogs and refinement were scaffolding for a slow era we’ve now left behind. I don’t think that’s right. Agile didn’t die. The thing it was quietly built to manage just stopped being the problem.

The constraint we built Agile around

For twenty years, engineering capacity was the scarce resource. Good engineers were expensive, hard to hire, and easy to waste. So we built an entire discipline around protecting them.

Be honest about what the ceremonies were really for. The backlog rationed attention. The sprint boundary kept stakeholders from re-pointing the team every afternoon. Estimation was a polite way of saying no, not this quarter. Prioritization, intake gates, the whole governance apparatus — all of it existed to take a small, costly pool of build capacity and aim it at the highest-value work while defending it from thrash.

That wasn’t bureaucracy for its own sake. It was a sensible response to a real constraint. When you can only build a little, deciding what to build is the entire game.

When the scarce thing stops being scarce

Now drop the price of building by an order of magnitude.

When a single engineer with the right tooling can produce in an afternoon what used to take a team a sprint, the math underneath all those ceremonies quietly breaks. The gate you built to protect a scarce resource doesn’t protect anything anymore — it just adds latency to a resource that’s no longer scarce. Every careful brake you installed is now drag.

This is the part teams feel before they can name it. The process that used to feel like discipline starts to feel like wading through wet sand. People assume they’re doing Agile wrong. They’re not. They’re running a system tuned for scarcity in a world that just got abundant on one specific axis.

The bottleneck didn’t vanish — it moved

Here’s the trap, though. Cheap building does not mean fast value. It just moves the jam somewhere else.

Look at almost any organization with real AI investment and you’ll find the same landscape: a pile of copilots, agents, internal tools, model integrations, three pilots that demoed beautifully, and a quiet graveyard of prototypes nobody folded into how the work actually gets done. The capability is sitting right there. The absorption isn’t.

The constraint moved downstream. It used to live in can we build it? Now it lives in can anyone put it to work and prove it was worth it? That’s not an engineering question. It’s an organizational one — about workflows, trust, change, and the unglamorous labor of getting a new capability all the way into someone’s daily job.

Agility’s job just inverted

For two decades, agility pointed inward. Its instinct was to protect engineering from the organization — buffer the team, hold the line, keep the demands out.

If the bottleneck is now adoption, that instinct is exactly backwards. The job isn’t to wall engineering off from the business. It’s to push engineering into it — out to the front lines, pointed straight at the highest-value adoption problems, close enough to the work to see whether anything actually changed.

Same word, opposite motion. Agility used to mean defend the scarce thing. Now it means get the abundant thing into contact with reality as fast as possible.

What you replace the brakes with

The fear, reasonably, is that removing the brakes just gives you faster chaos. And it would — speed pointed in no particular direction is simply waste, accelerated. The answer isn’t no brakes. It’s swapping the external brakes of scarcity for internal ones built on direction.

A few of the shifts I’d bet on:

Goal-driven over spec-driven. When building is cheap, a fat specification is a liability — you’ve over-constrained the implementation before you’ve learned anything. Give teams a sharp goal and the guardrails, and let them find the shape. (I’ve argued before that for AI agents this has to be explicit; for humans, direction beats a script.)

Opportunity backlogs over feature backlogs. Stop listing things to build. Start listing outcomes you’re trying to move. A feature list assumes building was the hard part. It isn’t anymore.

Value metrics over velocity. Velocity measured how fast you converted the scarce resource. Nobody cares now. Measure adoption, measure realized impact, measure whether the thing you shipped last month is load-bearing in someone’s work today.

A thin spine, thick edges. Keep the central process light enough that learning at the edge compounds instead of waiting on a committee. Empower teams, hold them to outcomes, and resist the urge to re-add a gate every time something goes sideways.

None of this is permission to abandon rigor. It’s a relocation of it — from controlling input to being honest about output.

Which job is worth absorbing?

Two of those shifts — opportunity backlogs and goal-driven work — quietly lean on a muscle most teams never had to build. Rationing scarce engineering, you mostly needed to know what to build next. When building is nearly free, you need to know what’s worth building at all — and the sharpest name for that skill is Clayton Christensen’s Jobs to be Done.

The premise is relentlessly demand-side: people don’t buy products, they hire them to make progress in a particular circumstance. Nobody wants a quarter-inch drill; they want a quarter-inch hole, and really they want the shelf up before the in-laws arrive. When building was the expensive part, you could start from the drill and survive. When building is free, the only scarce thing left is knowing which job is worth doing — and whether your shiny new capability is a better hire than whatever the person is using today, switching costs included.

It’s also the cleanest explanation I’ve found for the prototype graveyard. Christensen frames every switch as a tug-of-war: the pull of the new thing against two forces of inertia — the anxiety of trying it and the habit of what’s already there. Most dead pilots had plenty of pull and made no accounting for the inertia. The job was never really hired, so the capability never got absorbed.

I’d be honest about the limit, though. Jobs to be Done is a targeting system, not a throughput one. It tells you which job to aim abundant capability at; it does nothing on its own to raise how much change an organization can stomach in a quarter. That ceiling is a different problem, and pretending one framework solves both is how you get a tidy theory and the same graveyard. Where it pays off twice is measurement: Tony Ulwick’s outcome-driven spin turns a job into the measurable outcomes people judge progress by — a far better source for those value metrics than velocity ever was, and the same instinct as writing acceptance you can actually run. Define done as the job getting done.

Forward-deployed, because the value is at the edge

The pattern that keeps proving itself here is forward-deployed engineering: putting engineers right at the point where the capability meets a real user, a real workflow, a real customer. It’s an old idea. It’s newly essential, because the gap that matters now is the one between built and used, and that gap is only visible from the edge.

You cannot close an adoption gap from the center of the org chart. You close it by standing next to the person who’s supposed to be getting value and watching where it falls apart.

The real work now

I don’t think the teams that win the next few years will be the ones that build the most. Building is becoming table stakes. The ones that win will have built something harder to copy: a system for continuously absorbing new capability into evolving human work — and the honesty to keep asking who’s actually using it until the room stops going quiet.

Agile was always about responding to change over following a plan. The change showed up. It just landed one step downstream of where we were looking.

This post was sparked by Scrum.org’s AI Didn’t Kill Agile. It Moved the Bottleneck — worth reading in full. The argument here is my own take on the same idea.

Alright, on to the trip.

The Weekend

Three nights at Lake Winni Dam, and I have to say — this is hands down one of the nicest Corps of Engineers campgrounds I’ve stayed at. The sites are spacious and well laid out, each with electric hookup, a fire pit, and a picnic table. Some sites even have a clothesline, which is a nice touch I don’t see often. The restrooms were spotless and well kept the entire weekend, and you’re within easy walking distance of both the river and the lake. One small heads-up: there’s no firewood sold at the campground itself, but there’s a place about two miles down the road where you can grab a bundle on your way in. Quiet and peaceful the whole time. Highly recommend it.

Friday and Saturday were both rainy — not a washout, but enough to keep us under the awning more than I’d have liked. Saturday morning we got a quick thunderstorm that rolled through fast and loud, and then mellowed back into steady drizzle. Sunday and Monday are looking sunny and a lot drier, which I’m here for.

Echo and I did sneak in a hike over to the lake between the rain bands. Lots of fishermen out in boats — I counted at least a dozen at one point, all spread out across the water doing their thing. There’s something really calming about watching boats from shore on a gray morning. Echo was less calm about it. He wanted to swim.

What’s Working Well

The R1T as basecamp. Having electric at the site means I can keep the truck topped up overnight, and the truck in turn keeps the BougeRV fridge’s battery topped up during the day. (And yes, every single time I type “BougeRV” I crack up. Whoever named that company — bless you.) It’s a really nice closed loop.

BougeRV Rocky 41 QT mobile fridge. Game-changer over a traditional cooler. Stuff stays dry, temperature is rock-solid, and I’m not draining meltwater every morning. The internal battery lasts about 10 hours before it needs a recharge, but that’s easy thanks to the power outlet in the R1T’s bed. If you’ve been on the fence about ditching the cooler, this is your sign.

iKamper SkyCamp Mini. Setup is genuinely fast — I had it deployed before Echo had finished his perimeter sniff. Slept great. The one thing I’d flag is that I think I inflated the mattress a touch too much this time. It felt firmer than it did on the Colorado trip, and I noticed it. Easy fix next time: less air.

Blackstone 22” griddle. This thing absolutely earned its keep. Burgers came out perfect, did fajitas one night, pancakes for breakfast, and shrimp tacos that I’m still thinking about. The flat-top is so much more versatile than I thought it would be when I bought it.

What Could Be Better

Forgotten items. Two this trip: the micro USB cable for Echo’s light-up collar (which is genuinely useful at night and useless without juice), and a dog brush. Siberian Huskies do not stop shedding. Ever. The truck is going to need a serious vacuum when I get home.

An outdoor blanket for the dogs. Right now they kind of just flop wherever, which is fine in dry conditions but less fine when the ground is wet. I want something dedicated — durable, washable, ideally quick-drying — that I can throw down outside the tent or under the awning.

The tent-stairs sand/dirt problem. I tried putting a blanket at the bottom of the ladder to keep grit from getting tracked up into the tent. With the rain, the blanket got soaked through and became part of the problem instead of the solution. I need a better idea here. Maybe an actual outdoor mat with drainage, or one of those folding step platforms. Open to suggestions if anyone has solved this.

The Blackstone’s footprint. As much as I love it, the 22” griddle takes up a ton of space in the R1T bed. With the full camping load, it’s a real Tetris challenge. I think it’s going to become a special-occasions piece of kit — group trips, longer stays, anything where griddle cooking is the point — rather than something I bring every time.

The Menu

Three dinners, three breakfasts, two lunches. Brought it all from home, no resupply.

Friday

• Dinner — Hamburgers and BBQ beans

Saturday

• Breakfast — Cast iron pancakes with breakfast sausage
• Lunch — Italian sandwich on sourdough (provolone, mayo, pepperoni, salami, ham)
• Dinner — Steak fajitas (sliced ribeye, peppers, onions, flour tortillas)

Sunday

• Breakfast — Steak and eggs (using the leftover ribeye from Saturday)
• Lunch — Steak quesadilla (more leftover ribeye, plus cheese)
• Dinner — Garlic butter shrimp tacos

Monday

• Breakfast — Cereal with milk

The big win this trip was cooking the full pound of ribeye on Saturday and stretching it across three meals. Saved a ton of time and fuel. The shrimp tacos on Sunday were the standout — easily my favorite meal of the weekend.

Who I Missed

Two notable absences this weekend: Dee OhGee, our other Husky, who stayed home, and my husband Jayson, who’s in Chicago with friends. Echo and I had a great time, but the crew wasn’t complete. Looking forward to having everyone back together for the next one.

That’s the trip. More to come — both here and on Mastodon. Thanks for reading.

It was, technically, a working implementation. It was also completely wrong.

The ticket wasn’t bad. A human engineer on the team would have glanced at it, walked to the next desk (or opened a Slack DM), confirmed three unspoken assumptions, and shipped something reasonable by lunch. The story assumed a conversation. The agent didn’t have one.

This is the problem that catches most teams off guard when they bring AI agents into real delivery work. The backlog we’ve spent fifteen years refining is a beautifully human artifact. It rewards empathy, tolerates ambiguity, and leaves space for tacit knowledge. Drop an autonomous agent into the middle of that same pipeline and every helpful ambiguity turns into a failure mode.

The hidden contract of a user story

A well-written user story is less a specification than an invitation. “As a user, I want…” is a prompt for a conversation between the developer, the product owner, and whatever stakeholder is about to be inconvenienced by an ill-considered implementation. The story carries maybe twenty percent of the information; the other eighty lives in the heads of the people working on it.

Humans are exceptional at reading that eighty percent from context. We know which module owns the authentication path. We’ve been burned before by the ORM’s quirks. We remember that the CTO has Strong Opinions about rate limiting. Agents know none of this. They have a context window and whatever you put in it.

So the first shift is an uncomfortable one: for work an agent will pick up, the ticket has to stop being a conversation starter and start being an actual contract.

What a machine-ready ticket looks like

The tickets I’ve seen work best for agents share a few structural traits.

A concrete interface. Not “the API should return the user’s saved searches” but the exact request and response shapes, field names and types included. If it’s a database change, the table and column. If it’s a UI change, the component file and the props it accepts. The agent cannot ask what you mean.

An explicit blast radius. A short list of files or modules the agent is allowed to modify, and — more importantly — a list of ones it must not touch. Without this, agents have a habit of “improving” things while they’re in the neighborhood. Last week I saw one refactor an entire logging utility because it thought it could be cleaner. It could be. That wasn’t the ticket.

The context, inline. If the work depends on a specific doc, the relevant section goes in the ticket. If it depends on a library version, the version goes in the ticket. The agent won’t wander off to Confluence to check. Whatever’s not in the context window might as well not exist.

Acceptance in executable form. Tests, cURL commands, or a short script that can be run to verify the change. Pass/fail is the kind of signal agents can actually work with. “Looks good to me” is not.

None of this is especially novel — a rigorous human engineer would welcome the same artifact. The difference is that for humans it’s a nice-to-have, and for agents it’s the difference between shipping and an expensive PR full of confident nonsense.

Refinement, with a machine in the loop

Backlog refinement has always been the place where tickets get sharp enough to work on. The interesting move some teams are making is putting a model in that loop before the humans get there.

The pattern is simple: a cheap model reads every new ticket and flags the ones that are missing the things agents need — no schema, no explicit scope, no verifiable acceptance criteria. It doesn’t write the ticket. It just refuses to let a fuzzy one through the gate, with a note like “no defined response schema; an agent cannot execute this safely.”

This catches problems that would otherwise surface as a failed agent run three days later. And, almost as a side effect, it tends to make the tickets better for the humans too. Turns out precision scales.

Estimation, when the worker bills per token

Story points were always a proxy — a way to talk about complexity and risk without pretending we could predict wall-clock time. They work because humans share a rough intuition for what “a 3” feels like.

Agents don’t have that intuition, and their costs are structured completely differently. A ticket that would take a senior engineer an hour might cost ten cents or ten dollars for an agent to run, depending almost entirely on how much context has to be loaded and how many tool calls are needed to converge on an answer.

Teams running hybrid workflows are starting to estimate two things on a ticket: the human complexity (still useful, still fuzzy) and the agent cost envelope, in tokens or dollars or compute minutes. The second number unlocks a call that didn’t exist before — is this ticket worth $30 of agent time, or is it better handled by a human while the bot works on something higher-leverage? That tradeoff is a real one now, and it belongs on the ticket.

Pinning the strategy to the agent itself

Here is the trickiest part. A good human engineer carries the product’s strategy around in their head. They won’t build the feature the right way if they don’t know what “the right way” means for this product, this quarter, this company. That intuition shapes a thousand small decisions that never show up in a ticket.

Agents start every task fresh. Unless you put the strategy into their context, they don’t have one.

The teams doing this well are treating the product direction — the current quarter’s goal, the architectural guardrails, the non-negotiables — as something they inject into every agent prompt via retrieval. Not as a slogan pinned above the coffee machine, but as literal text the model sees before it writes a single line of code. “This quarter we’re optimizing for latency over throughput” stops being a Notion page and starts being a constraint the model is measured against on every pull request.

When you do this, the strategy stops being decorative. It becomes load-bearing.

The backlog is the interface

The throughline in all of this is that the backlog has quietly changed jobs. It used to be a shared to-do list. Now, for any team with agents in the mix, it’s the primary interface between human intent and machine execution. It’s where ambiguity is either resolved or becomes a bug. It’s where strategy either shows up in the work or doesn’t.

That’s not a small shift, and I suspect most teams will make it by accident, one painful PR at a time. The ones that make it deliberately — treating tickets as contracts, refinement as a pipeline with both human and machine gates, estimation as a real cost question, and strategy as something the agents can actually see — are the ones who’ll get real leverage from autonomous tools instead of just faster ways to generate confident nonsense.

The backlog was always supposed to be the source of truth. It just has to earn the title now.

Over the past several months, my company Alpine Blue has been working on Lamplit — a daily acrostic puzzle game for iPhone and iPad. We’re in early beta, and I wanted to share what it is, why we built it, and a few of the decisions that shaped it.

What’s an acrostic?

If you’ve never encountered the form, an acrostic is a word puzzle where you solve a series of clues — each answer is a word or phrase — and then the first letter of every answer, read top to bottom, spells a hidden word. That hidden word is the “spine.”

The double acrostic variant goes further: both the first and last letters of each answer contribute — spelling two words simultaneously, one down each edge of the grid. If you’ve ever solved one in The Atlantic or the Sunday newspaper, you know the particular satisfaction of watching a mystery word emerge letter by letter as you work through the clues.

Acrostics have a long history. The Victorian era loved them — they were a parlor game, a literary form, a way to hide messages in plain sight. We wanted to bring that warmth and wordplay to a modern mobile game.

What is Lamplit?

Lamplit is a daily acrostic puzzle game with a warm, unhurried aesthetic. Each day there’s one puzzle: single acrostics on weekdays, double acrostics on weekends. You solve it at your own pace — there are no timers, no streaks that punish a missed day, no ads.

The game ships with two clue modes:

• Modern mode gives you clean, direct clues. Clear, fair, and accessible.
• Classic mode reaches back to the Victorian tradition — cryptic, allusive, sometimes delightfully oblique. It unlocks after you’ve completed about 25 puzzles, which felt like the right moment: once you’ve internalized the structure of the puzzle, the puzzle itself can become more interesting.

The UI is dark-mode only, built around an amber and cream palette with New York serif typography throughout. The name comes from that aesthetic — the feeling of solving a puzzle by lamplight. Warm, focused, a little out of time.

The business model is a one-time purchase (roughly $4.99) rather than a subscription. We think word game fans are tired of paying indefinitely for content that should just be there. Optional themed puzzle packs and small consumable bundles (hint tokens, streak shields) let players support the game beyond the initial unlock, but nothing is gated behind a paywall that degrades the core experience.

Lamplit works fully offline. No account required to play.

A few decisions worth explaining

Why dark-mode only? It was an aesthetic choice first. The amber-on-dark palette is central to the feeling we wanted — something that genuinely looks and feels like lamplight. We didn’t want to compromise that with a light mode that would need its own palette design and feel like a different product. We may revisit this, but for now the constraint is also the identity.

Why Classic mode unlocks gradually? Victorian cryptic clues are genuinely harder. Not harder in a punishing way — harder in the way that a crossword clue with wordplay requires more fluency with the form than a straight definition. We didn’t want new players encountering Classic clues before they’d built up comfort with acrostics as a format. The unlock threshold is an invitation, not a gate.

Why SwiftUI and Swift 6? Partly because it’s the right tool for a new iOS app in 2026 — the framework has matured considerably and the concurrency model in Swift 6 is genuinely good. Partly because I find it interesting to work close to the platform when building something from scratch. SwiftData handles local persistence cleanly, and StoreKit 2 makes the in-app purchase flow about as simple as it can be.

Where things stand

Lamplit is in early beta. The core puzzle engine works. Daily delivery works. The purchase flow works. What we’re refining: puzzle content, clue quality, onboarding, and a handful of polish items that need more time in real players’ hands.

We’re not ready to announce a launch date. What we’re ready to do is start building a list of people who want to be notified when we go live.

Sign up for early access

If any of this sounds like something you’d enjoy — or if you know a word game enthusiast who might — head to lamplit.games and leave your email. We’ll reach out when the game is ready for the App Store.

I’ve spent a lot of years thinking about software from the outside. Building Lamplit has been a good reminder of why I got into this in the first place. I hope it’s something word game fans love.

If you have questions about the game, the tech, or the design decisions, leave a comment below — I’d enjoy the conversation.

Andrew Stellman captured this dynamic well in his piece on AI-resistant technical debt: “vibe coding”—rapid prompt → generate → run → paste errors → regenerate—can turn exploration into accidental architecture if we don’t check it. The result is familiar: over-coupling, god objects, needless layers, and eventually shotgun surgery for simple changes. The trap isn’t that AI is wrong. It’s that AI is convincing. It compiles, it passes tests, it feels done. But design debt accrues silently. See the original commentary here: Building AI-Resistant Technical Debt.

My stance

AI is a great accelerator for working software. It is a terrible decider of design. I treat it like a pair who can type at 300 WPM, not a lead architect. That mindset shift keeps me fast without locking bad decisions into the foundation.

The failure modes I watch for

• Over-engineered indirection for simple I/O
• Hidden coupling (helper classes reaching into internals)
• Abstractions created to satisfy tests instead of improving design
• Test pain as an early warning system (if adding a test feels hard, the design is hard)

Guardrails that actually work in practice

1. Trust, then verify (quickly)

   Let AI draft. Then I do a 5–10 minute design pass: responsibilities, boundaries, and names. If I can’t describe each unit’s single responsibility in one sentence, I refactor before merging.

2. Prefer simpler seams over frameworks

   Instead of wrapping I/O in a mini-architecture, pass inputs as parameters and return values. Push complexity to the edges only when genuinely needed.

3. Tests as design feedback, not just safety nets

   When a test is hard to write, I stop and adjust the API or dependency direction. Pain here is a feature; it points to structure that wants to change.

4. Time-boxed exploration, deliberate consolidation

   I allow messy exploratory branches. But I always follow with a consolidation commit: rename for clarity, inline accidental abstractions, extract true seams, delete dead code.

5. Naming is a design act

   I take an explicit naming pass. Clear names reduce the surface area of confusion more than another layer of code ever will.

A lightweight working checklist

Use this when accepting AI-generated code:

• Single responsibility per module or class?
• Dependencies point inward (domain) vs. outward (frameworks)?
• Input/Output handled at edges, not sprinkled through core logic?
• Tests easy to write without elaborate scaffolding?
• One level of abstraction per function? If not, split.
• Names read like documentation? If not, rewrite.

Patterns I reach for instead of over-architecture

• Data-in, result-out functions for core logic
• Ports-and-adapters only where boundaries are real (DB, network, UI)
• Composition over inheritance
• Feature flags and strangler patterns for incremental change

Team habits that prevent AI-accelerated debt

• Short design reviews for AI-heavy PRs (10 minutes, 3 questions: responsibilities, coupling, testability)
• “Consolidation Fridays”—dedicated time to rename, simplify, and pay back tiny debts before they grow
• Metrics that reward clarity (diff readability, test friction reduced) not just throughput

Final thought

AI makes starting easy and finishing tempting. Craft lives in the middle—where we decide what stays, what goes, and what gets clearer. Move fast, but edit harder.

If this topic resonates, the O’Reilly piece is a solid read: Building AI-Resistant Technical Debt. And if you try the checklist above, I’d love to hear what changed in your code reviews.

— Roger

The Challenge of Measuring Scrum Team Success

Here’s the hard truth: You cannot control outcomes in complex, unpredictable environments. Even the most skilled Scrum Team cannot guarantee that stakeholders will respond positively to change, that customers will embrace new features, or that external market forces won’t disrupt carefully laid plans.

This reality creates a fundamental challenge in measuring Scrum Team success. Traditional metrics focused solely on outcomes—like sprint goal achievement, velocity, or customer satisfaction—tell only part of the story. They fail to capture the nuanced ways a Scrum Team develops capabilities, adapts to change, and builds sustainable practices that enable long-term success.

A Three-Lens Framework for Success

To develop a more comprehensive view of Scrum Team success, we need to examine performance through three distinct but interconnected lenses:

1. Outcomes Still Matter (But They’re Not Everything)

While we can’t control outcomes, they remain an important indicator of overall team effectiveness. A successful Scrum Team should consistently:

• Deliver value incrementally: Teams consistently deliver usable product increments every sprint
• Meet sprint goals regularly: High success rate in achieving sprint objectives
• Improve predictability: Better estimation accuracy and delivery consistency over time
• Increase customer satisfaction: Positive feedback and reduced support issues

Key Questions to Ask:

• Are we delivering working software that customers actually use?
• How often do we meet our sprint goals?
• Is our velocity becoming more predictable over time?
• What does customer feedback tell us about the value we’re creating?

2. Behaviors: The Leading Indicators

Behaviors are often the most reliable indicators of Scrum Team effectiveness because they represent the day-to-day actions that lead to better outcomes. Focus on these behavioral patterns:

Team Response to Challenges

• Early problem detection: Does the team identify impediments quickly?
• Collaborative problem-solving: How does the team work together when issues arise?
• Resilience and adaptability: How well does the team handle setbacks?

Learning and Adaptation

• Feedback loops: How quickly does the team learn from mistakes?
• Continuous improvement: Is there evidence of evolving practices and processes?
• Retrospective effectiveness: Are action items from retrospectives actually implemented?

Communication and Conflict Resolution

• Open dialogue: Are team members comfortable sharing concerns and ideas?
• Constructive conflict: Does the team engage in healthy debates about solutions?
• Psychological safety: Do team members feel safe to take risks and make mistakes?

Scrum Values in Action

Observe how well the team embodies the five Scrum values:

• Courage: Willingness to tackle difficult problems and have tough conversations
• Focus: Ability to concentrate on sprint goals and minimize distractions
• Commitment: Dedication to achieving goals and supporting each other
• Respect: Valuing diverse perspectives and treating everyone with dignity
• Openness: Transparency about work, challenges, and feelings

3. Growing Team Maturity: The Deeper Layer

This is perhaps the most important but least discussed aspect of Scrum Team success. It involves developing the collective capacity to:

Collective Emotional Intelligence

• Team emotional regulation: Managing collective stress and maintaining composure during challenges
• Mutual support: Team members actively supporting each other through difficult periods
• Shared resilience: Bouncing back from setbacks as a unified team

Collaborative Learning Culture

• Growth mindset: Approaching challenges as collective learning opportunities
• Knowledge sharing: Freely sharing expertise and insights across the team
• Experimentation: Willingness to try new approaches and learn from failures

Systems Thinking and Alignment

• Holistic perspective: Understanding how team actions affect the broader organization
• Pattern recognition: Collectively identifying recurring issues and root causes
• Strategic alignment: Connecting team work to organizational goals and customer value

Practical Measurement Strategies

1. Team Health Metrics

Implement regular team health assessments that measure:

• Team satisfaction scores: Regular anonymous surveys about job satisfaction and team dynamics
• Psychological safety index: Measure how safe team members feel to speak up and take risks
• Collaboration effectiveness: Assess how well team members work together
• Learning velocity: Track how quickly the team adopts new practices and improves

2. Behavioral Indicators Tracking

Create a simple tracking system for key behaviors:

• Retrospective action item completion rate: What percentage of improvement actions are actually implemented?
• Impediment resolution time: How quickly are blockers identified and resolved?
• Cross-functional collaboration: Frequency and quality of interactions with other teams
• Self-organization maturity: How independently can the team operate?

3. Team Maturity Assessment

Evaluate team maturity development through:

• 360-degree team feedback: Gather input from stakeholders, other teams, and leadership
• Team reflection sessions: Regular collective assessment of growth areas and team dynamics
• Peer development effectiveness: Measure how well team members develop each other
• Change adaptability: Assess the team’s ability to navigate transitions and challenges

Common Questions and Answers

Q: How do we measure success when our team’s outcomes are poor despite following Scrum practices?

A: This is exactly why the three-lens approach is crucial. Poor outcomes don’t necessarily indicate poor team performance. Look at:

• Are team behaviors improving even if outcomes aren’t yet?
• Is the team learning and adapting faster than before?
• Are external factors (market conditions, organizational constraints) impacting outcomes?
• Is team maturity and collective capability growing?

Focus on what the team can influence and measure progress in those areas.

Q: What if our organization only cares about delivery metrics?

A: Start by connecting behavioral improvements to delivery outcomes. For example:

• Show how improved retrospective practices led to faster impediment resolution
• Demonstrate how better team communication reduced rework
• Highlight how increased psychological safety improved innovation and problem-solving
• Present data showing correlation between team behaviors and delivery performance

Gradually educate stakeholders about leading vs. lagging indicators.

Q: How often should we measure these different aspects?

A: Use different cadences for different measurements:

• Outcomes: Monthly or quarterly reviews
• Behaviors: Weekly team observations and monthly assessments
• Team maturity: Quarterly deep dives with annual comprehensive reviews

Q: What if we’re not seeing improvement in any of these areas?

A: This signals a need for deeper investigation:

• Are there organizational impediments preventing the team’s progress?
• Does the team need additional coaching, training, or resources?
• Are there unaddressed team dynamics issues?
• Is the team ready for the level of change being attempted?
• Are expectations realistic given the team’s current context and constraints?

The Sustainability Factor

A truly successful Scrum Team creates sustainable practices and continuous improvement. Ask yourselves:

• Can the team function effectively when any individual member is absent?
• Are team members developing coaching and facilitation skills to support each other?
• Is the team’s improvement trajectory continuing even during challenging periods?
• Are other teams seeking to learn from this team’s practices and approaches?

Moving Beyond Traditional Metrics

Success isn’t about checking boxes or achieving perfect velocity. It’s about direction, discernment, and depth. It’s about creating a culture where the team can thrive, learn, and adapt to whatever challenges come their way.

Just as a surfer works with the ocean’s energy rather than trying to control it, a successful Scrum Team learns to work with the complex dynamics of their environment, creating conditions for success rather than trying to force specific outcomes.

Your Team Success Reflection Framework

To implement this approach, regularly ask yourselves these three key questions as a team:

1. What outcomes are we influencing and how?
   • Focus on the team’s sphere of influence rather than control
   • Look for patterns in team performance over time
   • Connect team actions to observable results
2. What behaviors are we improving—individually and collectively?
   • Observe daily interactions and team dynamics
   • Track improvements in communication and collaboration
   • Notice changes in how the team handles challenges
3. How are we expanding our collective capability and maturity?
   • Assess the team’s growth in skills and effectiveness
   • Measure how well team members are developing each other
   • Evaluate the sustainability of changes and improvements

Conclusion

Measuring Scrum Team success requires a sophisticated understanding of complex systems, human behavior, and organizational dynamics. By using the three-lens framework of outcomes, behaviors, and team maturity, teams can develop a more complete picture of their effectiveness and impact.

Remember: Your team’s worth is not defined by any single metric or measurement. A team’s value extends far beyond what can be captured in traditional performance indicators.

The goal isn’t perfection—it’s progress. Focus on creating conditions where the team can flourish, learn, and adapt. Measure success by the collective growth, resilience, and capability the team develops together. That’s how we measure success in complex and unpredictable environments. That’s how effective Scrum Teams thrive.

Key Takeaways

• Team success measurement should encompass outcomes, behaviors, and team maturity development
• Behaviors are often better leading indicators than outcomes alone
• Psychological safety and team health are crucial metrics for long-term success
• Sustainable change requires developing the collective capability of all team members
• Regular reflection and multi-dimensional assessment provide the most complete picture of team effectiveness

Have you implemented any of these measurement approaches in your Scrum Team? What challenges have you faced in defining and measuring team success? Share your experiences in the comments below.