The Catch-Up Pile From Global Agile Summit 2026

I watched these seven the day after Global Agile Summit 2026 ended. Day 1’s live Q&As needed an advance ticket I missed until the slots had closed; Ethan Chazin’s and Adam Hoots’s talks I couldn’t find on YouTube — they look like Oikosofy Library exclusives. Five missed Q&As and two library latecomers, watched back-to-back. The two threads from earlier in the week — where execution gets cheaper, judgment moves; direct observation of users still beats indirect signal — came up here too, with the speakers getting specific this time about how those threads show up in a working week.

Jeff Patton — Why We Build the Wrong Things (Q&A)

Patton’s prepared talk argued that AI amplifies the wrong-thing problem rather than solving it. The Q&A went somewhere else. The strongest line came when someone asked him how to push back on a stakeholder who insists on a feature the data says won’t help. Patton’s answer: be more like a doctor than a waiter. The waiter takes the order. The doctor probes for the underlying problem, surfaces adoption risks, asks how success will be measured, and offers to test cheaply before committing. Same political pressure, different shape — the stakeholder gets a proposal that’s actually about reducing their risk, not about you saying no.

The customer-development-partner thread in the Q&A is the operational form. Patton’s argument: stop scheduling user research as a quarterly event. Build standing relationships with the early adopters in your customer base, the ones who push back, ask awkward questions, and notice things before the general population does. Talk to them weekly. He cited a Barclays trader floor where developers sat next to customers and talked to them every working minute. The depth of signal from a weekly conversation with a small group is structurally different from the breadth of signal from a quarterly survey of many.

The other piece I want to keep is the line on rapid testing as risk mitigation. He told a Nordstrom story: a week of team time on a sunglasses prototype, killed before it rolled out to every Nordstrom store. “The difference between failure and learning is how much money you spend to do it.” A few days and a few thousand dollars on something that doesn’t work is learning. A few months and a few million on the same thing is failure.

The doctor-not-waiter move maps cleanly onto the inbound side of bug prioritisation. When customer-experience surfaces a “we should add X” the underlying request is almost always a problem the requester has decided how to solve. The doctor question is what they’re trying to do; the waiter answer is the X.

His bombshell — that the original Agile Manifesto authors mostly sold consulting hours rather than shipping product, and so optimised for collaboration with whoever paid them rather than for end-user value — is the kind of historical claim I’ll keep turning over for a while. The Manifesto is still useful. The incentive structure that produced it is worth being honest about.

Shawn Wallack — The Fastest Engineer in History Just Joined Your Company

Wallack’s prepared talk had landed for me already — execution compresses, judgment becomes the bottleneck, AI is the chainsaw and the lumberjack still picks the tree. Most of the live session ran the same argument under a different title. What was new were the operational pieces.

The line that fits how I work with my agents was Wallack’s own: “This thing is the fastest typist I’ve ever seen in my life.” That matches what my orchestration actually does — fast on the keyboard, no judgment of its own. Wallack made the harder claim explicit too: AI never has and never will have agency, and the agency-plus-accountability pair is the unit that actually makes someone responsible for what shipped. Both stay with the human reviewer who pushes the button.

The air-traffic-control metaphor was the new piece. Speed of the plane is no longer the constraint. Control of the airspace is. My big cats news pipeline can move more items per day through its review loops than I could by hand. The bottleneck isn’t how many planes can fly. It’s which ones I clear for landing, in what order, and against what criteria. Same shape on the custom social-media orchestrator I wrote alongside it. Same shape on the agent stacks I build for the day job — code review, ticket investigation, test-plan generation. The decision throat moves; the execution capacity becomes background.

Wallack’s other useful frame was on bottleneck migration. Bottlenecks never disappear; they move. As orchestration absorbs more execution, the bottleneck moves from review to deciding which problem to point the next agent at in the first place. The cap on what the system can do is set by how fast I can decide what to point it at, not by how fast the agents can run.

Maks Piechota — The Autonomous Software Factory

This was a 25-minute Q&A follow-up rather than a solo thesis talk, and the actual content under the “factory” title was narrower than I expected. Maks’s argument is that the right way to steer AI agents is not soft skills and prose guardrails but BDD-style behaviour specs and fitness functions: deterministic green/red tests the agent iterates against until it crosses the threshold.

The map onto my work is direct. My translation-quality loop today exits on an implicit threshold: a quality-inspector agent decides “this looks done” and the loop stops. Piechota’s reframe is to make the threshold explicit: a fitness function the inspector evaluates, with a numeric or boolean cut. The mechanism stays the same. Once it has a name, the threshold becomes a knob I can tune.

His other line worth keeping: “measure the pipeline, check where the bottlenecks are. Then once measured, you know where to automate.” It’s an obvious thing to say. It’s also the order automation often gets applied in inverted — interesting first, bottleneck second.

The “factory” framing in the title doesn’t quite land. The panel didn’t develop it, and the team-throughput connotation doesn’t fit the kind of solo orchestration I do. The fitness-function piece travels regardless.

Dave Westgarth — Vibe UX (Q&A)

The prepared talk had been one of the Day-1 pieces I wrote up early in the run. The Q&A added the part I most wanted to see: Westgarth and the audience working through what stops the speed gains from rotting into technical debt.

Markdown-as-interface is what I want to keep. Westgarth’s framing: design systems evaporate, but markdown files agents can read are durable. Codify the patterns you want enforced as agent-readable specs — naming conventions, layout rules, accessibility checks, copy register — and feed them into the agent’s working context the way you’d hand a human contractor a style guide. Most of my own scaffolding is already markdown-shaped, framed as documentation for humans. Westgarth’s reframe inverts the audience — same files, different reader. Small reframe, real practical implication for how I structure the agent contracts I write for myself.

The other tactic worth trying is the halting rule. “Draw a line under, I need you to do this part. I take that out, and then I get on with the job again.” The agent does a scoped piece; the human picks it up and continues. I do this informally under pressure already; turning it into part of the agent contract would stop the failure mode where the agent over-runs into work that should have been mine.

The participant Q&A also surfaced the daily-credit-limit pattern: small, repeatable AI-prototyping sessions on a fixed token budget rather than unlimited burn. A budget cap enforces discipline that’s hard to self-enforce.

Ethan Chazin — The Business Case for Employee Empowerment

The talk that wasn’t on YouTube. Chazin spent a decade studying around 7,000 organisations in, by his count, 250 countries, and his finding is the one most agile-and-leadership writers gesture at without naming: the variable that consistently predicts financial outperformance is empowerment-oriented culture, not country, not industry, not the leadership team’s pedigree.

The numbers he cites are blunt. Roughly 80% of the workforce is disengaged. The average employee is productive about 60% of the workday, and at optimal performance maybe three hours a day. The Pareto split shows up consistently: 20% of the workforce produces 80% of the results, and 10% produces half. Daniel Pink’s empowerment levers — when, where, with whom, and how — predict whether the people in the long tail get pulled toward the 20% or push themselves further into the 80%. Chazin’s argument is operational: invest in those four levers, measure the engagement uplift, then measure the financial follow-through.

What landed for me was the middle-manager point. Managers are responsible for around 70% of employee engagement based on day-to-day interaction. Top-down change is fashionable, but the leverage is at the middle — and that’s where the work I do happens. “You now go from manager to leader.” The phrasing maps almost exactly onto how I describe my own preference: I prefer to lead and step in only when the work needs me. Chazin gave me the business-case shape underneath the preference.

The other piece he mentions in passing — Project Aristotle, Google’s finding that psychological safety is the single most important determinant of team performance — has been quoted enough that the words stop carrying weight. Chazin’s contribution is the operational layer: psychological safety isn’t a slogan, it’s the absence of a specific kind of penalty for raising risks early. The Six Boxes framework he uses (manage expectations and feedback; provide tools and resources; set consequences and incentives) puts the employer’s side of that bargain into observable obligations.

Umar Ijaz — Indy Games: The Natural Home for Agile (Q&A)

Ijaz’s prepared talk in Day 1 made the framework argument: indie studios are the natural home for agile because survival forces the disciplines, not because anyone installed them. The Q&A was the part where the audience asked him how, specifically, the disciplines work day to day.

Feedback-loops-don’t-scale is the through-line. Ijaz built his initial play-test group from eight people sourced at game festivals, universities, and other community channels. And he ran it on a Discord he had to build himself because the existing communities didn’t fit. The playtest is observational and structured: the tester engages with the game in real time and the developer watches, asks open follow-ups, doesn’t narrate. He explicitly contrasted this with the broadcast direction: a LinkedIn post that 300 people saw out of 8,000 followers. One reply.

Map this onto the news automation I run for big cats — a one-developer studio. The audience reach numbers are similar in shape: a wide soft signal from publishing, a narrow hard signal from a small group of regular readers. The lesson is to invest in the narrow signal.

His line on solo work was the one I expect to be quoting back to myself: “You need to find your own routine and your ritual to make it happen for you.” Solo doesn’t scale by importing team agile. It scales by building a personal rhythm that survives without external pressure: a release cadence the project itself enforces, an accountability partner who asks what shipped, a community that pulls the work forward when motivation drops.

I’m a long-time consumer of the industry, not an indie developer. Schreier’s books are part of how I think about how products get made, and Ijaz’s indie disciplines map onto solo work like mine because of the scale, not because of the medium.

Adam Hoots — Daily Agile on the Jobsite: Metrics That Matter

Construction track, library-only, fifty-two minutes of jobsite metrics. I almost skipped this one. The framework transferred more cleanly than I’d expected.

Hoots’s central argument: field teams ignore traditional metrics because traditional metrics measure what already happened, and the people doing the work need to know whether they’re winning right now. Lagging indicators describe the past, after the fact. Leading indicators — say-do ratio, do-say ratio, percent-plan-incomplete with the why-not attached — describe the next move. “By the time you’ve measured it, it’s overdone and past due.”

The trust framework underneath was the part I want to keep. ABI: ability, integrity, benevolence. Can the person do the work, do they follow through on what they say, and do they care about the outcome and the people around them. The Likert-scaled Circle of Trust — same questions every week, simple enough to answer in seconds, anchored to observable behaviours — produces a leading indicator of team health that the team can read and act on without needing a project manager to interpret it.

The transfer to my support team is direct. Most ticket-throughput metrics are lagging. Hoots’s PPI inversion is the leading-indicator addition: track bugs not closed and ticket investigations not finished, with the why-not attached. Blocked on upstream, awaiting design, reassessed as low-impact. Not blame data. Diagnostic data — what’s blocking what next. I plan to try this on the next pass through the bug backlog.

The other line that fits is “tell me how you measure me, and I’ll show you how I perform.” The corollary is the failure mode — measure ticket throughput and the team will optimise for ticket throughput at the cost of the harder, slower work that actually moves the system. The reason the weekly Clarity-style session-recording reviews work is that they don’t have a number on them. Replace the practice with a metric and the metric is what the team will produce.

His three jobsite health checks — porta-john status, building cleanliness, material overload — don’t transfer directly. I can’t check a porta-john from a remote support desk. The structural move underneath them does transfer: pick three observable things that take thirty seconds to read and that signal team trust and workload pressure together. If I built three small visible signals for this team, they might be backlog age at the median, new-user friction incidents per Clarity review, and whether there was time for proactive bug patrol this week.

What the catch-up cut showed

Two pieces I’ll carry forward. Hoots’s PPI inversion goes on the next backlog pass — track bugs not closed and investigations not finished, with the why-not attached. Westgarth’s markdown-as-interface reframe is a smaller change to the agent scaffolding I already write for myself. Both come from talks I almost didn’t watch.