On Tuesday, September 22, about twenty developers and coaches made their way to the Cronos headquarters in Kontich for another Agile Kitchen session. The topic was one that many younger practitioners have barely heard of, yet it shaped nearly everything we call Agile today: eXtreme Programming.
Our speaker for the evening, Jan Van Ryswyck, attended an earlier Agile Kitchen as a participant, and afterwards told us there was something he wanted to share with this community. He has been a professional software developer since 2000, works as a technical coach specialized in XP practices, and wrote Writing Maintainable Unit Tests.
He took us back to the origins of XP. Not as a nostalgic trip down memory lane, but as a challenge: have we forgotten knowledge that today’s software teams desperately need again?
A method born from a simple observation
One of the first insights of the evening was a reminder that software development is fundamentally a knowledge creation process.
Traditional approaches assume we can discover and document most requirements upfront, before implementation begins. Reality has always proven otherwise. As development progresses, we learn. Requirements evolve. New insights emerge. Assumptions turn out to be wrong.
As Jan pointed out, even Winston Royce’s famous 1970 paper, so often cited as the foundation of waterfall development, warned against assuming a sequential process would work without feedback and iteration.
Software development is not manufacturing. We do not just transform raw materials into a predefined product. We create knowledge while building the product itself.
XP emerged as a response to that reality.
Collaboration beats collaboration tools
One theme returned throughout the evening: real collaboration versus asynchronous coordination.
Many modern development processes lean heavily on feature branches, pull requests, handoffs, and waiting queues. These approaches have genuine advantages, and it would be hard to imagine open source being managed any other way. But they also introduce delays, context switching, and rework.
XP proposes something different through co-creation patterns such as pair programming, pair design, pair testing, mob programming, and Three Amigos conversations.
This is not merely about quality. It is about knowledge sharing, faster decision making, fewer bottlenecks, higher trust, and greater resilience when people leave or change roles.
An important prerequisite came up here: collective ownership. The code belongs to the team, not to individuals.
Continuous integration really means continuous
Another thought-provoking discussion concerned continuous integration. Most of us in the room use feature branches and pull requests. Jan challenged us with a provocative statement:
If you are developing on feature branches and integrating later, you are not really doing continuous integration.
The original XP interpretation was simple. Commit to the main branch frequently. Integrate multiple times per day. Keep the system working at all times.
That requires capabilities many teams struggle with today: good architecture, small vertical slices, automated testing, feature toggles, and genuinely incremental development.
Whether or not you fully agree with this interpretation, it certainly sparked discussion about how much “continuous” is left in our current integration practices.
Let’s learn from geese
Throughout the session, Jan kept showing pictures of geese. At first, many of us wondered what geese had to do with software development.
Geese work together remarkably well. They fly in a V-formation to reduce air resistance, which lets them travel much further than any of them could alone. When the lead goose gets tired, another takes its place, exactly as cyclists do during a race.
They never leave one behind. When a goose becomes injured or exhausted, two others stay with it until it recovers or can continue. They support the weaker member of the group instead of simply moving on.
And they encourage one another. That familiar honking is not random noise. Geese communicate continuously to keep each other moving forward.
Teams that collaborate, support one another, share leadership when needed, and actively encourage each other consistently outperform groups of talented individuals working in isolation.
Be more like geese. Pair more. Share more. Support more.
Why this matters in the age of AI
The session ended with perhaps its most relevant message.
Large Language Models are changing software development rapidly. Yet the data increasingly suggests that AI amplifies existing team behavior. High-performing teams benefit significantly. Dysfunctional teams often experience the opposite: more code, more complexity, and amplified bottlenecks.
The implication is profound. AI does not eliminate the need for strong engineering practices. It increases it.
The teams that gain the most from AI tend to have strong foundations already. Fast feedback loops. Small increments. Automated testing. Continuous integration. Collective ownership. Regular refactoring.
In other words, many of the practices XP advocated more than two decades ago.
Join the next Agile Kitchen
If you missed this edition, do not worry. The next Agile Kitchen session is already in the making. Follow us on LinkedIn or subscribe to our newsletter to make sure you secure your spot.