I spoke at several conferences in 2013 and I've finally taken the time to track down all the conference videos. Here you go:
Agile Fluency™ Model at NDC 2013
The promise of Agile is simple and compelling: a team that effortlessly surfs the wave of business possibility, changing direction to meet the needs of a changing market. So why do so few teams achieve that ideal? Lack of fluency. Agile may be simple, but it's far from easy, and it takes years of practice to do well. We'll look at four phases of Agile fluency, what you can expect from each phase, and how to increase your team's fluency so you can achieve what Agile promises.
The Agile Fluency Model is a tool Diana Larsen and I created to help teams understand what's possible with Agile and how to increase their fluent proficiency. A lot of people have praised it for its accurate representation of how teams grow, and for its usefulness in discussing Agile with managers and executives.
If you like the model, Diana and I are launching the Agile Fluency Project next week. If you're interested in improving the state of Agile in your company, you owe it to yourself to sign up to learn more.
I also gave a keynote on this topic at XP 2013. As a keynote, it spends more time on understanding the "why" than the "how," and I work harder to be entertaining. I'll let you decide how successful I was.
The XP 2013 video is here. (Scroll to the bottom of the page and use a browser that supports .mp4.)
Leading Agile Engineering at Agile 2013
You're leading a team as it becomes agile. You've got the planning process under control. You're realizing the benefits of improved transparency and your teams are communicating better with the customer. But you know that many of the key advantages--faster release cadence, improved quality, reduced cost of change--come from changing the core development activity.
Some of these changes, such as basic TDD, are obvious. But even they can be difficult to measure. Beyond the basics, the technical practices become difficult even to describe. Your teams give you transparency into what they do. How can you get similar transparency into how they do it? What should you realistically expect a team to do, and how can you tell whether it is doing that?
This talk targets managers and executives for agile teams. We discuss helping people see what is possible, creating feedback systems so that everyone knows where they are at, and ways to choose practices that align with your business needs.
Arlo Belshee and I make a great team, and we've done some crazy stuff together. This talk is on the serious side, but it's still really good stuff. We talk about how to create a great engineering team and introduce Arlo's "subway map" of Agile engineering practices (influenced in part by the Agile Fluency Model).
This is really Arlo's stuff, much of it inspired by his work at Microsoft, and good stuff it is. I'm honored to have been part of it.
The video is here. (Note: requires a free login.) The sound's a bit low, but headphones help.
I keynoted on this topic at ScotlandJS as well. Again, as a keynote, it's more about why than how.