Videos of Talks

Most of what you’ll find on this site is writing, but I know that many people enjoy a video experience. I haven’t got into video production, it’s difficult work and not something I find worthwhile. But I do give talks, and often these talks are now captured on video. So I’ve put together this page to pull together all the talks and other video material I’ve been involved in.
I do repeat talks, so several talks have multiple video versions to choose from. I’ve also put useful links on this page to help you explore further than the talk itself.
“How many people in this room have been on a software project where there’s been significant changes in requirements during the course of the project?”
The essential elements of agile software development and how you gain fluency as you learn
It's been over a decade since we wrote the Manifesto for Agile Software Development, and the agile meme has been more successful than we ever could have hoped for. But like any success, there is the regular danger of Semantic Diffusion. I try to combat this disease by describing the essence of agile software development: preferring adaptive planning to predictive planning and favoring people over process.
I then describe the Agile Fluency model, which I find an effective way to think about how agile teams become proficient, and the steps you typically go through as you become a more skillful user of agile techniques.
youtube - 25 minutes
youtube - 25 minutes (✂)
youtube - 24 minutes (✂)
Why is it that agile approaches work so effectively?
Neal Ford and I gave a talk at USI in Paris (2010) on some aspects of why agile works (as opposed to how). This probes at some of the core forces that makes agile effective, rather than looking at techniques. In particular we look at role of communication and feedback and how they interplay in agile environments.
Sadly the video appears to be truncated and cuts off in the middle of the talk. I haven't been able to figure out how to get the full video posted.
youtube - 43 minutes
I gave this talk ten years after we wrote the agile manifesto. I set out the historical context in which we wrote the manifesto, explain why the semantic diffusion we've experienced since is an inevitable consequence of its success, argue that those who say they don't care about agile are usually wrong, and highlight two areas where we see some interesting new activity in agile thinking.
youtube - 27 minutes (✂)
Should we kill agile software development?
with Dave Thomas, Jez Humble, Katherine Kirk, & Tatiana Badiceanu
In 2014 Dave "Pragmatic" Thomas got irritated with the state of the agile software world saying Agile is Dead. The organizers of the goto conference in Aarhus, who have long been active explorers of agile styles felt that was a good opportunity to bring together him and myself, as two of the authors of the manifesto, together with some people who have been on the receiving end - using and extending agile approaches in the field.
youtube - 105 minutes
The most important factor in software development is the communication between users and developers
with Daniel Terhorst-North
A keynote for QCon 2007 that I did with my colleague Daniel Terhorst-North. We both see the gap between developers and their customers/users as the biggest problem in software development. (We'd call it a chasm, but that word is so overused.) Here we talk about this gap, why it's important, and what we need to do to cross it. In particular we argue that the traditional role of an intermediary Business Analyst acts as a ferry, while what we really need is a bridge that enables directly contact between developers and their customers (and analysts can build and maintain that bridge). This is one of my favorite joint keynotes, both because I think the topic is so important, and because Dan is such stimulating co-speaker.
Daniel Terhorst-North helped me explain why bridges are better than ferrymen
Presenting with Birgitta Böckeler at Craft Conf
Architecture is the important stuff, whatever that happens to be.
Since the begining of agile methods, there's always been a deep debate on what role (if any) software architecture should play on agile projects. Much of this depends on what you consider architecture should be.
What architecture is and why it matters
I was asked to do a fourteen minute minute keynote at OSCON to explain why architecture was important. I decided the best thing was to begin by exploring the meaning of that awkward term, guided by my favorite mailing list post from Ralph Johnson. Once I'd done that I moved onto why it matters by focusing on the economic argument of the Design Stamina Hypothesis.
youtube - 14 minutes
What role does architecture play in a world of autonomous teams, and how do we make it happen?
with Birgitta Böckeler
Increasingly we are seeing organizations move to a world of autonomous teams focused on business capabilities. This helps software development be responsive, and focused on business outcomes. But what role does this leave for architecture, both within a team and across the wider organization?
We argue that architecture is still important, but must be based on guidance rather than command and control. Cultivating this thinking inside and between teams requires work in several areas:
youtube - 48 minutes
The point of spending effort on design is to improve productivity - delivering features quickly
Often people justify effort on software design by pointing to the need for greater craftsmanship and quality. My view is that such moralizing arguments are wrong, that instead we should focus on the economics. Most software efforts slow over time, as the weight of bad design decisions slow down our teams. Attention to design can reduce or even reverse this.
I've found that the metaphor of Technical Debt is a good way to think about the consequences of bad design - do we pay interest or pay off the principal. Some argue that technical debt isn't the result of sloppy design, but I poi