Modern software development welcomes changing requirements, even late in the process, but how can we write our software so that those changes don’t create a mess? Evolutionary design is the key. It’s a technique that emerges from Extreme Programming, the method that brought us test-driven development, merciless refactoring, and continuous integration.
I first encountered Extreme Programming and evolutionary design nearly 20 years ago. Although I was initially skeptical, I’ve explored its boundaries ever since. In this invited talk for the December 2019 YOW! conference series in Australia, I share what I learned through in-depth animations of real software projects. You’ll see how designs evolve over time and you’ll learn how and when to use evolutionary design for your own projects.
In the early days of Agile, methods such as Extreme Programming advocated for shipping without a QA phase. In fact, they often didn’t have dedicated testers—or even bug-tracking systems. And yet there are stories of these teams producing an order of magnitude fewer defects than normal. What did these teams do, and why did it work? And what role does that leave for QA? In an age where Agile is interpreted to mean “sprints” and “story points,” the technical side of Agile is often forgotten. In this invited talk for the October 2019 Pacific Northwest Software Conference, I spoke about the technical underpinnings of Agile and how they lead to true business agility.
Assert(js) is a conference about testing. Specifically, automated testing. But why bother? Why have automated testing? In my short and sweet keynote session, I looked at what you get and what comes next.
The Agile Fluency™ Project has put out a new video overview of the Agile Fluency Model. Diana Larsen provided the words and I did the animation. It's on YouTube, so it's easy to share with others and use in your presentations.
I'm particularly proud of how this one came out. Here's the direct link.
Diana Larsen and I were interviewed on the Scrum Master Toolbox Podcast earlier this year. We shared our latest thoughts on the Agile Fluency™ Model, including why it's different from a maturity model (and where the idea of "maturity" might fit into the model), our "bus zone" metaphor, and how to use it in your work.
I guest-starred on the Ruby Rogues podcast in August 2016. We had a wide-ranging talk discussing how Agile has changed over time, evolutionary design, large-scale Agile, and more. It's one of my favorite podcast appearances to date. Well worth the listen.
I've been doing a lot of work with multi-team development projects recently, and this has resulted in two good talks on large-scale Agile.
Scaling Beyond the Enterprise
My first talk was a keynote for Agile India in March 2016. It provides a good overview of the issues that come up, some of the solutions, and discusses my approach is different from existing approaches to scaling.
Scaling Beyond the Enterprise
The brilliance of early Agile methods was their non-conformity. They rejected conventional wisdom about how software should be created and substituted a new reality: one where collaboration, adaptation, and continuous improvement were more important than rigid processes and plans. At first, many people rejected these innovations, but Agile stood the test of time. Now it's won the day.
When people talk about scaling Agile, they forget those insurrectionary roots. They focus on what's palatable to the "enterprise:" how to make Agile safe, non-threatening, and acceptable--how to make it more conventional and conformist. In doing so, they risk losing the innovations that make Agile work so well.
What if we stopped worrying about what's safe and acceptable? What if we went back to those innovative roots? What would Agile look like if we scaled beyond the enterprise?
Come find out.
At the I T.A.K.E. conference in Romania, in May 2016, I keynoted on this topic again. This was an audience of developers, so I took a deeper look at the architectural and team structure considerations. There's a bit of overlap, but it goes into more detail with more examples. I'm particularly pleased with how this talk came out: it's covers a very solid list of things to think about as your company grows.
That feeling of a successful startup. A handful of people in a room, getting shi...ny things done. Everybody working together, all cylinders firing. It's intoxicating.
That feeling of a great XP team. A cross-functional team, all in a room, getting shi...pping done. Everybody working together, sharing responsibility, creating great code. It's impossible to forget.
But what do you do when the startup IPOs, and the 12-person company is now a 1000-person behemoth? What do you do when the XP team grows, and you have 100 people working on a product, not ten? How do you keep those great small-team dynamics in a big organization?
When people talk about scaling Agile, they focus on what's palatable to the "enterprise:" how to make Agile safe, non-threatening, and acceptable. But what if we aren't in that kind of company? What if we know what it's like to be great, but we're too big to do it the way we used to?
Let's set aside the brand names, consulting companies, and enterprise certifications. Let's look at the possibilities of large-scale Agile at its best.
The Agile community has been arguing about whether estimates are a good idea or not for a while now. In this talk at Øredev in November 2015, I think I did a pretty good job of threading the needle. I talk about how and when to estimate, and why you might not want to.
Estimates or No Estimates?
There's a debate raging in the Agile world: should we estimate, or not? Lost in the noise are more important questions: When should we estimate, and why? When should we not estimate, and why not?
As with so many Agile questions, the answer to "should we estimate?" isn't a clear-cut "yes" or "no." Instead, the answer depends on what your team is capable of, what your organization needs, and how to best balance the two.
We'll take a deep look at how estimates work, why they work, and when and why to discard them. Along the way, we'll encounter surprising insights about the nature of Agile development and the teams that use it.
Agile Engineering for the Web
I keynoted at Agile Australia in June 2015 and InfoQ recorded it. If you know somebody who's doing "Agile in name only," they should watch this video. Here's the blurb:
For an approach that emphasizes simplicity, success with Agile is surprisingly difficult. Some teams see amazing results. They're able to respond to changing needs, deliver new releases every day, and do so with nearly zero defects. Other teams complain that Agile makes things worse, not better. They get less done and spend more time in pointless meetings.
What is about Agile that creates such different experiences? Let's take a step back and look at what makes Agile work. What's the point of these Sprints, stories, Scrums, and other practices? What leads to success and what leads to struggle? It's time for a frank discussion about what it takes to succeed with Agile.
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.
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.
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.
At this year's Norwegian Development Conference, I gave a new presentation on evolutionary design, and NDC was good enough to record it and put the video online. It's a highly visual look at how evolutionary design has worked in practice on three projects I've been involved in. It's good to watch if you've ever wondered how evolutionary design plays out in practice. Here's the blurb:
In an agile environment, programmers must deliver working software in the first iteration. Requirements may change at any time, so there's no way to design the software in advance. Instead, you must design your software based on its current needs, and evolve the software design as the requirements change. This process is called evolutionary design. (It's also called continuous design, or iterative and incremental design.)
But how does it work? How can evolutionary design result in high-quality code? In this visual and example-filled session, James Shore will demonstrate how evolutionary design works in practice, using real-world examples culled from his decade of Agile development experience. You'll see how designs evolved in response to external forces, and how responding to those forces yielded in designs that were clean, flexible, and maintainable.
On Tuesday, Alistair Cockburn and I debated the merits and limitations of certification in a webcast hosted by the PMI. We had an interesting and cordial discussion and the PMI has graciously put up their recording for anyone to hear.