Thirteen Recorded Talks at Global Agile Summit 2026, Day Two

A separate piece covers the four live Q&As I caught on Day Two. This is the recorded sessions — thirteen of them across four parallel tracks plus the two bookending keynotes. The Q&As surface what speakers say off-script; the recorded talks are what they prepared.

Going through Day Two in air-time order, the convergence was different from Day One’s. Day One kept arguing at the level of ideas — where judgment should live, why watching beats theorizing, how clarity feeds back into burnout. Day Two was operator-voice. People kept showing the tactics they actually run.

Brian Melcher — Building a Self-Managing Organization: Lessons from Field Verified

Construction-track keynote. Brian runs Field Verified, a building-enclosure consulting and testing firm in Arizona. Pre-Scrum: twelve employees, fifteen percent margin, growth flat in 2021. Post-Scrum: thirty employees, thirty-five to forty percent margin, six-hundred-percent profit growth across three years. He met Felipe Engineer-Manriquez (Day One, construction track) at the pivot itself — a few days on an island outside Stockholm at a lean author’s house, where Felipe’s Scrum framing gave him a name for what he was already half-doing.

What stuck most was the lean-in-the-bathroom failure. Field Verified read the standard book that says start your lean rollout with the bathroom chore wheel. They tried it; it fell flat. Brian re-read the book in front of the whole company and threw it over his shoulder. Immediately people opened up about what was actually wrong. The public abandonment of a failed initiative was the move that mattered. After that, every change he tried got real feedback because people now believed he’d cut what didn’t work.

Then there was the toolbox poster. They put production-quality posters on the wall showing what goes in each kit. Kits kept going out wrong. Eventually somebody admitted, looking down at the kit then up at the poster was just slightly too much friction. They shrunk the poster, glued it inside the toolbox lid, and the problem went away. The original lean idea didn’t work; the actual fix was simpler than the idea.

Also: Brian’s daily huddle became a recruiting filter. Candidates show up, see the board, and either light up or check out. He stopped having to convert anyone. The board does the conversion before he says a word.

For me, this maps to the bug-fix backlog the Product Support team works through — smaller in scale but the same posture. It also raises the question of what to do with capacity once you’ve freed it up. Brian chose to add roles that improve quality of life — videographer, graphic designer, director of internal operations, monthly career-progression check-ins for everyone. He didn’t choose to multiply throughput. That’s a deliberate trade-off and I want to keep noticing it as a trade-off rather than a default.

Jason Little — Onboarding Your AI Employees

Keynote, AI track. Jason Little wrote Lean Change Management. He uses Claude for ninety-five percent of his work and has built a small team of single-responsibility agents around himself: a project manager that runs his Kanban board, a sentiment-analysis agent, a brand-guidelines agent that knows his style guide and logos, an evaluator that decides which course evaluations are good enough to post as public testimonials.

The line that stayed with me was Rachel Janneway’s, which Jason quoted: human in the lead, not in the loop. The chasm between those two phrasings is where most AI implementations live or die. Maks Piechota later in the day said the same thing in different vocabulary. So did Per Beining.

What Jason does that I do too: keep agents on a single responsibility, build a project-folder pattern with custom instructions plus uploaded training data, and run a feedback loop where the agent reports what it would need to do its job better next time. He calls it taking the agent out for lunch and giving it a performance review. I have not given mine a name as cheerful as that. The agent stack I run on every code review is more than a dozen specialised agents, and the improvement pass on its rubrics works the same way.

Jason’s burnout warning is the part most demos skip. If I could finish five things in a week, I can now finish five thousand. I’ll be just as exhausted. When the bottleneck shifts from typing to thinking, the productivity ceiling moves up but the human stays the same shape. No clean answer to this yet — neither from him, nor from anyone else I have read on it.

He also closed with a song he co-wrote with Claude — a custom songwriting skill trained on his lyrics, chord progressions, and feel, with separate skills for mixing and hardware patches.

Per Beining — From Confused to Confident: Reflections from Running a Claude Code Bootcamp

AI track. Per started using Claude Code in January 2026 and has run three cohorts of about thirty-five people through a beginner bootcamp. The premise: most people are stuck somewhere on a continuum between I want to embrace AI and I’m scared of it, and the way out of the continuum is to ship something small every day.

What people built in twenty minutes during the bootcamp tells the story better than the framing does. A retire-early calculator with personal stock holdings. A nutrition planner integrated with two or three Danish supermarket APIs by the next day. A cheap-airline-tickets dashboard. A personal website. An inbox automation that summarises overnight email against an active project list.

Per closed by playing the David Bowie BBC Newsnight interview from 1999 — the Internet is not just a tool, it’s an alien life form. The interviewer, Jeremy Paxman, can’t quite hear what Bowie is saying, and Bowie won’t bend the framing to make it land easier. Per’s read on it — that we’re now in the equivalent slot, and most rooms are full of Paxmans rather than Bowies — is fair enough. I had the same reaction when I rebuilt the search layer on my big cats news project earlier this year by directing AI to do work I would have struggled to do myself in any reasonable time.

Per’s heuristic for what to automate is clean: if the task gives you ten times more learning when you do it ten times yourself, do it yourself. If it doesn’t, automate it.

Better filter than “save time.” It surfaces the actual question.

Anita Kalmane-Boot — Neurodiversity in Software Development Teams

People track. The Q&A version of this is in the live-Q&A piece. The recorded talk had material the Q&A didn’t cover, and what stuck was the recruitment angle.

Anita’s tip from training: hire for culture add, not culture fit. Hiring for fit feels safe and produces homogeneous teams that miss the cognitive range a problem domain actually requires. Hiring for add asks the harder question — what is missing here that this person could supply. The corollary on job vacancies is concrete. Competitive salary means nothing; give a range. Hybrid means nothing; say how many days. Photos of the office matter, especially if it is open-plan, because for a meaningful share of candidates open-plan is a deal-breaker that nobody puts in a posting.

Her education-system observation also lands hard. School trains people to sit still, follow topics that don’t interest them, and behave the way the rest are behaving. Then we hire them and ask them to be self-steering. That is a real contradiction, and one most agile-transformation work flatters past rather than addresses.

The general type-trait observation she made — that software development happens to be one of the few domains where neurodivergent cognition fits the work natively — is widely-known. Hyperfocus, written communication, individual deep work, creative-yet-precise patterns. It is also one of the few places where being different has, in her words, a different connotation than in finance or sales.

Markus Hjort — From Prompt to Play: Building AI-Native Games with Agility

Gaming track. Markus is co-founder and CTO of Bitmagic, a web platform where you describe a game in prompts and get a 3D game back. He has been writing code since the Commodore 64, with two years between his coding stints spent as an Agile coach across Finnish companies — small startups to Nokia. The coaching pattern stays useful, he said, even when you can’t fix anything yourself.

The strongest argument in the talk is one that contradicts the way most of us were taught to read code. Markus’s point: AI isn’t always cleaner at the line level than a careful human, but the measure of a healthy codebase has changed. The old test was can a human read this like a book. The new test is can the patterns and abstractions in this codebase be applied consistently by an agent across the next change. He gave the example of a five-thousand-line refactor that AI completes inside an hour — the kind of work that, by hand, used to leave you with two style-eras layered into the same project because nobody had time to migrate. With AI, the migration is cheap, so the layered legacy is gone.

I want to flag where I disagree, because the honest answer for me is somewhere between his and the older view. On the same big cats search-layer rebuild, I deliberately asked the AI to preserve working older patterns even where they were less elegant than the new ones. For a one-person system that has to keep running while being iterated, the cost of a full migration is too high; preserving the working pattern beats architectural consistency. Markus’s framing assumes a healthy team and a continuous migration cadence. Mine doesn’t. Both are right in their own context.

His closing was Embrace Change, the subtitle of Extreme Programming Explained. The book was the first agile book I read, too. Twenty-five years later, the subtitle still does the work of a thesis statement.

Ebele Okochar & Jim Damato — IDD: Industrialization Driven Development

Construction track, co-presented. Industrialization Driven Development is what Jim, Ebele, and their colleague Pete built when they realised hardware teams adopting Agile were getting bad results because Agile-as-default doesn’t account for the slow build cycle of physical products. Their reframe: work backwards from sale to factory to certification to procurement to engineering. The roadmap that comes out is what you take into PI planning, not the other way around.

Two phrases worth lifting from this. First, Jim’s: software is just hardware in slow motion. It puts the difference between the two domains in one sentence. Second, theirs together: learn early, lock late. You delay locking decisions until the calendar forces you to, and you spend the time before the lock learning everything that would invalidate it.

The pattern they identified that I want to apply more deliberately: when something is blocked, work to unblock it. Don’t drift to a lower-priority task to stay busy. Most of the time on a queue of complicated tickets, the unhealthy default is the second move — looks productive, does nothing for the actual constraint. Naming the failure mode helps; the IDD discipline is to push on the block until it moves.

Gojko Adzic — Using AI in Product Development: Why Outcomes Still Beat Outputs

AI track. The densest single talk of the day. Gojko walked through his workflow on a small product he is building solo, and almost every example was a small-team-without-a-budget translation of a practice that used to be reserved for big companies with dedicated design and infrastructure teams.

The design-system example is what I’m taking from this. He had Claude scan his existing website, document its visual language, and produce a design system as a set of static HTML pages in version control. From that point onward, every new feature gets prototyped against the design system. The static pages are versioned alongside the production CSS so they stay in sync. Spec by example, but on visuals. He doesn’t have a designer; the design system replaces the bottleneck a designer would have created.

The other move I’d copy is the diagnostic endpoint trick. He built a chain of tracer endpoints — ping, then who-am-I, then the business endpoints — purely so an agent could narrow down where a deployment failure was happening. Then he realised the same chain made an excellent user-facing connectivity page. When users in Israel started complaining the application wouldn’t load, he sent them the diagnostic page and got back exact information about what their ISP was blocking. Tooling built for the agent doubled as tooling for the user.

His framing of disruption is sharper than the way it’s usually written. Disruptive innovation isn’t the ten-times-better thing that replaces the existing solution. It’s the thing that brings a previously-rich-only solution to people who couldn’t access it. By that definition, the AI work most of us are doing right now is disruptive in the strict sense.

The same lens applies to a smaller system I have been running for myself — Telegram input fanning out to X, Bluesky, and Friendica, with thread-splitting, reply-tracking across platforms, and quote-handling that makes the content read naturally per platform. I built it because manual cross-posting was untenable. The cross-platform orchestration it does has, until now, required either paid SaaS or in-house engineering. I have been considering whether to monetise it. Gojko’s framing is the cleanest version of the argument for moving the question forward.

Tara Scott — Breaking the Permission Loop: Agency as a Superpower

People track. The live Q&A version is in the other piece, but the recorded talk had something the Q&A didn’t get to: the trinity itself. Tara names three components that make up agency — confidence, humility, self-trust. Confidence is iterative and tied to passion. Self-trust is what you have when you have validated or invalidated the inherited beliefs about yourself. Humility is the seesaw stabiliser; without it, the other two skew.

The dynamics-mapping practice she described is worth trying on myself. List your strengths and weaknesses, then for each weakness ask whether the assessment is true or whether it was inherited from someone whose framing you accepted. Permission versus agreement is the practical reframe. Permission is asking up the chain. Agreement is the team having already aligned on how decisions get made, so the permission question doesn’t have to be asked.

Joshua Thaler — Building Teams That AI Can’t Replace

Gaming track. Thirty-plus years across Riot and Zwift. Live-ops focus.

The short version of his argument is Daniel Pink’s list of six things AI cannot do: ask better questions, recognise good taste, iterate relentlessly on small adjustments, compose disparate ideas into something meaningful, allocate the right people to the right problems, act with integrity. Joshua’s elaboration is that AI can replace some chunks of work and probably some junior-level execution roles, but it cannot pick the right thing to make at the right time with the right people. That decision still belongs to humans.

His tools-versus-people observation is sharp. Every tool rollout he has watched at any studio he has worked at, where leadership picked the tool first and announced it, failed. Every rollout that started from a defined problem and worked back to a tool succeeded. AI is currently being rolled out in the executive-picks-first pattern almost everywhere. He expects a five-year correction.

Among his hiring criteria: stop starting and start finishing, attributed to Lance Stites at Riot. I have watched the same pattern in technical-support work for years; people start things continuously and finish them only when forced. Naming the inversion helps.

The live-ops piece is what I expected to be most useful and was. Every problem solvable before release is five-to-ten times cheaper than the same problem in production. The communication loops that close the gap between development teams and operational teams are usually the live-ops team’s job to build.

Same about the support-to-development relationship in any product company. We don’t ship the bug; we file it back upstream. The loop has to exist at all.

Maks Piechota — Engineering Trust: Let AI Ship Your Code

AI track. The most legacy-respecting talk on the day. Maks’s argument: every concern people have with AI-generated code — hallucinations, hidden bugs, untrustworthy outputs — is the same concern organisations had about human-generated code for the past forty years, and the engineering legacy already solved most of it. Pair programming, trunk-based development, TDD, feature flags, observability, metrics, behaviour-driven test suites. The solution stack exists. AI just makes the volume of code generated big enough that companies which had been ignoring those practices can no longer get away with ignoring them.

His framing of vibe coding had a punchline worth lifting. Vibe coding is nothing new. Managers vibe-coded with engineers for decades. That sentence, said out loud, deflates a lot of the discourse around AI tooling. The role he uses to describe the current developer is manufacturing supervisor rather than craftsman — you build the harness around the line and you check the output, but you don’t read every line.

His three quality gates for AI-driven work are concrete. A markdown spec per feature. A C4 architecture diagram generated from a domain-specific language so the agent can write the definition while you read the picture. A behaviour-driven test suite that hides implementation details and lets the agent run against behaviour. He showed an example of code Claude produced from these three gates that he merged to production without changing a line. That’s the maturity level the harness can deliver if you build it.

The burnout question he raised is the same one Jason Little raised. He’s watching himself to see whether his brain adapts to context-switching across multiple agent-driven work streams or burns out. I’m running the same experiment on myself.

His closing: Respect the foundations. The AI tooling churns daily; the foundations don’t. He’s standardised on Claude Code via CLI and refuses to chase newer tools that don’t change the fundamentals. That’s the right discipline.

Diana Larsen — Leading in Turbulent Times

People track. Diana wrote Lead Without Blame with Tricia Broderick. Thirty-plus years of agile coaching. The talk’s frame is that the pace of change has not just sped up; it has stopped pausing between changes, which is a different problem from speed alone.

Diana’s change-bucket model: every person has a different inherent capacity for absorbing change, and once that bucket overflows, no amount of communication or training compensates. Change agents tend to have large buckets, which is why we routinely set expectations our colleagues can’t meet. Knowing both the size of your bucket and the level it is at right now is part of leading honestly. The team-level version is asking the fourth standup question, attributed to Mitch Lacey — how confident are we we’ll meet our goal — and pulling on the answers that disagree with the consensus.

Her reframe of software work as learning work rather than knowledge work is the part I keep thinking about. Knowledge work assumes you have the relevant skills and you apply them. Learning work assumes the problem is partly new every time and the team’s intelligence has to grow into it. By that framing, almost everything I do at the day job and on personal projects is learning work; the knowledge-work parts are vanishing as AI absorbs them.

Dan Hollinger — Don’t Just Expect Things to Go Wrong, Plan For It

Gaming track. Dan spent two decades in game development and led infrastructure work at Facebook’s Horizon Worlds team during the global outage that locked even the building’s key cards. His subject was the SEV process — Site Event, the structured incident-response pattern Facebook uses internally. The Technical Support work I lead at the day job runs on a similar shape, mostly under different vocabulary, so most of the talk was directly applicable.

Two patterns I want to reinforce on my own team. First: positive confirmation on handoffs. Assigning a ticket isn’t a handoff; the handoff completes when the receiving owner confirms they have it as their P0. Without that, urgent tickets sit unread in someone’s queue for two days. Anyone who has worked an escalation queue has watched this happen. Second: the SEV owner drives toward resolution but isn’t necessarily the person who fixes. Their job is to find the right person on the chain and shield them from interrupts while the fix lands. The shielding is the part most ticket-tracking systems don’t model.

The blameless-postmortem framing is more careful than the slogans usually let on. Dan’s specific guidance: when describing what went wrong, name the system, not the person. A bug was introduced into the save system that caused this corruption, rather than I introduced a bug. But when describing the fix, give direct attribution. The asymmetry is intentional — it makes the postmortem a place where people who fix things become visible without making the place where things break a public-blame venue.

The example he closed on was the maximal-subsequence algorithm published in a 1970s paper that had an integer-overflow bug nobody noticed for thirty-five years. Even academic, well-examined, simple code carries bugs that nobody finds for decades. The implication for AI-generated code is direct: we are not setting a higher standard than humans were ever held to.

Mike Chiles — Getting Buy In: Increase Respect, Increase Results You Want

Construction track. Mike runs project management at a four-hundred-and-seventy-million-dollar ammunition plant build. He uses Scrum on the submittal process — the heavy paperwork cycle that has to happen before any product can be ordered or installed — and he has cut a planned year of submittal work into roughly three months by visualising the backlog, prioritising it with the Eisenhower matrix on top of standard Scrum, and letting any project-management team member pull a submittal off the queue.

The role-play exercise the host walked him through is worth quoting in full. You’re a skeptical superintendent, you’re old and crusty, you’ve got five minutes, sell me Scrum. Mike’s answer: I’m not going to even try to convert you to Scrum. I’m going to ask what bothers you. People love to brag about scars, but they don’t like to talk about wounds. When you get close to a wound, they get grumpy. I’m going to figure out where your wounds are and try to fix one of them. The reframe — that resistance is grief about something specific, not a position about your idea — is the one I want to carry into every change conversation. Kat Antonowicz on Day One had the same observation from a social-work background. Mike has it from twenty years on construction sites.

The other line: if they tell you it’s going to take thirteen days, it’s probably going to take thirteen days. I have worked with subcontractors and developers and support engineers who fall into the trap of arguing the calendar instead of trusting the estimate.

The calendar argument never wins. The estimate is usually correct.

Pulling threads

Two threads pulled across the day.

One is the human-in-the-lead phrasing. Jason Little, Maks Piechota, Per Beining, and implicitly Joshua Thaler all said the same thing in different words. The chasm between human-in-the-loop and human-in-the-lead is the difference between AI-as-replacement and AI-as-amplifier. Useful work comes out of the second framing. The first framing produces LinkedIn posts about twelve-person change teams that are now one person, and not much else.

The other is the wound under the resistance. Mike Chiles named it most directly, but Anita Kalmane-Boot’s observation about late stand-up attendance, Diana Larsen’s change buckets, Tara Scott’s permission-paralysis, Brian Melcher’s team only opening up after he publicly killed a failed initiative — they’re all variants of the same observation. The resistance is signal about something real underneath. Push the change without addressing what the signal points to, and you get what most agile transformations actually produce: theatre on top of the same underlying frustration.

Concrete framings I want to test. Maks’s three gates on the next agent-orchestrated investigation. Mike’s wound-under-the-resistance read on the next friction-rich change conversation, and Per’s ten-times-learning filter on the bug backlog.

The recorded form is what I will rewatch when I want a specific tactic. The live Q&As are where the speakers’ assumptions actually showed.