Five Summit Recordings, Three Weeks Late

The Global Agile Summit ended on May 6. I watched these five recordings a couple of weeks later, after Oikosofy released them to the video library. A mob-programming workshop from Woody Zuill, four live Q&A follow-ups with Jason Little, Marcus Bullock, Clinton Keith, and Joshua Thaler, roughly five hours of material compressed into a week of evenings.

The delay was unintentional but turned out to be productive. Watching sessions that happened days apart, back to back, in a quiet week, surfaced a thread I would not have caught live: every one of these speakers, from different angles and different tracks, kept arriving at the same operational question — how do you keep the human directive when the tools are fast enough to make the human optional?

Zuill answered with a game. Little built a folder structure. Bullock discovered it when four weeks of automation passed without anyone talking to a customer, and Keith when a parking-lot headcount measured the wrong thing. Thaler brought a sword.

Woody Zuill — Mob Gaming with Woody Zuill

This was a workshop, not a talk (the only one in this batch). Zuill’s group played Baba Is You, a puzzle game where the rules of the world are physical text blocks you can rearrange, using mob-programming technique. One person drives the keyboard, one person navigates by giving intent, everyone else watches and waits their turn.

I watched the recording weeks after the summit. What struck me was that the workshop process was the content. The puzzles are a vehicle; what you see is how people learn to communicate high-level intent without giving step-by-step instructions.

Zuill’s opening line: “I’m not here to tell you what to do. I’m just here to share with you what I’ve done.” He calls his guidelines the pirate code, more like guidelines than rules. The core principle comes from Llewellyn Falco: for an idea to go from someone’s head into the computer, it must go through someone else’s hands. In practice, the navigator says “disconnect the flag-is-stop statement so we can move freely” — not “press left three times, then down.” Zuill frames three levels of instruction: intent, instructions, location. The navigator aims for the highest level the driver can work with.

The moment I wrote down: the navigator gets stuck on a puzzle. Zuill opens the floor: does anyone have an idea? A participant raises a hand and offers an insight: multiple rocks can be pushed at once, which could break one of the game’s logic statements. But the offer goes to the navigator, not to the driver. The navigator decides whether to try it. Zuill makes the social contract explicit: helpers offer, the navigator chooses, nobody takes over.

This maps to how I work with AI agents. When I set Claude Code on a task, I stay at the intent level (“fix the flip-flop detection in the translation pipeline”) and let the agent figure out the approach. When it drifts, I correct. When I am stuck on direction, I ask for alternatives and pick. The driver-navigator protocol Zuill teaches for a group of humans is close to identical to the interaction pattern I already run with a group of agents.

During the reflection, one participant said: “I kind of overthink. I think five steps ahead, and I don’t try sometimes.” Another noticed “there’s a desire to get the right answer first.” Zuill’s response: whenever you think something will not work, that is a good time to experiment. Failure is undoable — the Z key resets everything, same as version control.

That is where mob programming diverges from how most teams work. In a mob, trying the wrong thing is cheap because everyone sees the failure and learns from it together. Working solo, the failure stays invisible and the learning locks in one head. I have mentored juniors through exactly this transition — from afraid to try to comfortable failing, because the team absorbs the result. Mob programming would have accelerated that.

Zuill closed with a line I keep turning over: “Teamwork does not replace solo work, and solo work does not replace teamwork. We can have both.” Then he added that when some task feels like it must be solo because it is simple grunt work, that might be the time to automate it. For someone building agent orchestration to handle the repetitive fraction of support work, that landed.

I wrote a shorter take on this workshop as a LinkedIn post. The longer format here let me sit with the process itself — the gameplay as teaching vehicle, the strict-then-open facilitation arc, the driver-navigator parallel to AI direction that Zuill never mentions but that was visible to me throughout.

Jason Little — Onboarding your AI Employees (LIVE Q&A)

Little’s prepared keynote (covered in the Day 2 consolidated piece) introduced the framework: treat AI agents like employees, with onboarding, training data, and team working agreements. This Q&A went into the operational reality of running that setup day to day.

The anchor was his 95% rule. When AI does something unexpected, 95% or more of the time the issue is your prompt, your instructions, or your context — not the model. Little frames this as understanding that LLMs are pattern-matching engines with no intent. “There’s no thinking. There’s no intelligence behind it.” Once you internalise that, your prompting changes.

What the Q&A reinforced: I structure my own orchestration the same way Little structures his Claude ecosystem — a single entry point branched into specialised skills, each scoped to one responsibility. The architecture is the same: a folder of instructions, narrowly scoped training data, a feedback loop that periodically audits the agent’s output against what I actually wanted.

The part that pushed me further was anti-sycophancy. Little described a devil’s advocate skill designed to call bullshit on his strategy decisions. “AI is agreeable… you have to trigger it.” One audience member pushed back: just asking for disagreement produces artificial disagreement. Little agreed. Grounding the criticism in external reference, not just “be harsh,” makes it valid rather than performative. I already use multi-option prompting in my ticket-investigation work precisely because a single answer from an agreeable model is unreliable. But I have not built a dedicated adversarial agent for my own strategic thinking. That is the concrete thing from this Q&A I plan to try.

The sharpest exchange was between Little and an audience member who argued that AI-driven silo inefficiency in large enterprises is fundamentally different from the old agile-transformation struggle — “the speed of creating inefficiency and noise, it’s 1,000 times faster.” Little held his position: the change pattern is the same regardless of speed. The cultural problem underneath — thinkers design the process, doers absorb the mandate — has not changed in fifty years. I found myself agreeing with both. The pattern is the same. The speed makes it worse.

Marcus Bullock — Resilience, Trust & Second Chances (LIVE Q&A)

Bullock’s Q&A stood further from his prepared keynote than the others did. Where the keynote (covered in the Day 1 recap) was about building human-centred tech, the Q&A went into his own trajectory: prison at 15, founding Flikshop, building the Flikshop School of Business inside prisons, and the operational tension between scaling with AI and maintaining human contact.

The moment that stayed with me: Bullock described building automated dashboards for partners using Claude Code. The workflow was clean — from first customer interaction through personalised reporting, fully automated. Then he realised four weeks had passed without a single human conversation with a customer. “The way we grew the company was by doing the things that don’t scale… and then figuring out how to build the systems around the things that don’t scale that allow us to be able to scale in the background.”

That sentence is the most operationally honest thing I heard across all five sessions. You do not start with the scalable version. You do the manual work, learn what matters, then automate around it — keeping the human parts that made the thing work in the first place.

When someone asked about leadership risk, Bullock was immediate: the leader absorbs the downside. Not as a poster line — as an operating principle. “The question really is not is there risk, but the question is who absorbs the downside of those risks?”

I have taken people from minimal experience and grown them over years into mid-level contributors. Bullock’s second-chances conviction — that brilliance sits in places most organisations have already decided to ignore — resonates with that work. The mechanism differs. The operating belief is the same: environment shapes outcome more than raw ability, and most organisations under-invest in the environment.

The exchange about AI access versus outcomes was the sharpest turn. One participant framed it as the drug-dealer model — free samples now, dependency-pricing later. Bullock pushed toward something more specific: “Access gets marketed as equal, but outcomes are quickly shaped by who is truly included, who’s really supported, and who’s really actually even invested in.” Access without support is not access. That framing applies beyond AI tools.

Clinton Keith — Game Development, as we know it, is ending (LIVE Q&A)

Keith wrote Agile Game Development with Scrum and has been the central voice on agile in games for two decades. As someone who follows game-dev process from the consumer side, this was the Q&A I wanted to hear most.

The crunch metrics story stayed with me longest. Keith described himself as “the master of enforcement crunch,” the manager who mandated weekend work and considered himself a good leader because he was there alongside the team. Then he adopted scrum and started measuring actual feature delivery rate per sprint instead of counting hours in the building.

The data: 50% more time in the studio produced 20–30% more features for the first few weeks. After three weeks, output nosedived. After a month, teams delivered fewer features per sprint than before the crunch started. He already knew this intuitively. But the metric — transparent, visible — changed his behaviour because he could no longer look away. “Getting that transparency into the impact of what crunch is, is one of the things that Agile can provide. What you do with that, unfortunately, isn’t always making the right decision.”

Building trust with teams to self-commit takes months. Destroying that trust by reverting to mandate-crunch takes overnight. Keith described teams that began self-crunching once they owned their commitments — and how his role changed from “come in this weekend” to “stay away,” not out of kindness but because the metrics showed more hours would produce less output.

The final question hit Keith visibly: “Do you ever worry that agile was actually used as a coping mechanism rather than a cure?” He talked about going into a large studio, training hundreds of developers in scrum, then getting fifteen minutes with the C-suite — who were all on their phones. “There has to be this fundamental layer of good leadership that has to exist. And there’s been organizations I go into where it doesn’t exist.”

Some of those efforts did not change the organisation. But developers carried what they learned to their next studio. The impact compounds across career moves, not inside the organisation that paid for the training. That observation is one I recognise from a different function — the long-term return on mentoring shows up in a person’s next role more clearly than in their current one.

Joshua Thaler — Building teams that AI can’t replace (LIVE Q&A)

Thaler’s was the shortest session — about twenty-seven minutes — and the most tightly scoped to a single thesis: humans remain necessary where expertise is deep, context-dependent, and regulation-heavy.

The sword-fighting detail from his talk surfaced first. Thaler leads in the Society for Creative Anachronism, a volunteer medieval-reenactment organisation, and described it as his leadership training ground. The core skill he named: “influence without authority.” You cannot mandate compliance from volunteers. You present direction clearly enough that following it becomes the natural choice.

That phrasing is the one I associate most with the kind of leadership I prefer. Running a support team in a startup, I spend more time enabling people to solve problems than solving problems for them. When I need something from a different team, I present the case and wait. Thaler arrived at this through sword fighting. I arrived through years of tech support. The path differs; the operating principle does not.

On AI tool integration, Thaler offered one architectural principle: loose coupling through an API layer. Every AI tool will change substantially within two to three years. Build the middleware; swap the tool underneath. This matches what I did on my news pipeline this year — replaced the search source entirely, and the rest of the system never noticed.

The GDPR discussion raised an industry-wide point: AI wants access to everything; data-protection regulation restricts what can be processed and how. Thaler’s position: “Trust but verify. I think there’s a little less trust.” Expecting any AI tool to handle compliance without human audit is, as he put it, setting yourself up for the kind of failure that puts companies out of business.

Watching these five sessions in a single week, what stood out was not the AI discussion — every conference track in 2026 touches AI. What stood out was how consistently each speaker arrived at the same operational question from a different starting point.

Zuill’s answer is a social protocol — navigator gives intent, driver executes, nobody takes over. Little’s is a folder structure — single-purpose agents, one task per thread, feedback loops. Bullock found it by accident: four weeks of clean automation without one customer conversation showed him the human touchpoint was the product, not the dashboard. Keith’s answer is a metric — the parking-lot headcount said crunch was working; the sprint data said it was not. Thaler built a middleware layer and expected everything underneath to be replaced.

The question underneath all five: when the executor moves faster than the director can think, what keeps the director’s judgment from getting optimised away?

Zuill’s workshop gave the most concrete version. The navigator does not need to solve the puzzle faster. The navigator needs to communicate what matters clearly enough that the driver can execute it. That division does not disappear when the driver is an AI model. If anything, it matters more, because the model will execute anything described clearly enough, including the wrong thing.

I want to try the Baba Is You mob format with my team at some point. Not as regular mob programming (my team is too small and too distributed for that) but as a facilitation exercise for the skill that matters most when the step-by-step executor has no judgment of its own: giving intent, and resisting the urge to give location.