Evolutionary Design Animated

Feb 20, 2020

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.

Agile Without Dedicated QA

Nov 3, 2019

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.

Thinking In Tests

Nov 3, 2019

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.

Agile Fluency Model Overview Video

May 9, 2017

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.

ScrumMaster Toolbox Podcast on Agile Fluency Model

May 9, 2017

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.

Listen to it here.

Evolution of Agile

Aug 30, 2016

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.

Listen to it here.

Two Talks on Scaling Agile

Aug 30, 2016

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.

Rethinking Scaling

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.

Rethinking Scaling

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.

Estimates or No Estimates?

Aug 30, 2016

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.

ESTIMATES OR NO ESTIMATES? from Øredev Conference on Vimeo.

Agile Engineering for the Web

Aug 30, 2016

I spoke on Agile engineering at Øredev in November 2015. I'm particularly proud of how well this talk came out--it's livecoding, which can be hard to do well, and it does a great job of showing how to test JavaScript and CSS. It's basically a summary of what I've learned from my Let's Code JavaScript screencast.

Agile Engineering for the Web

Test-driven development, refactoring, evolutionary design… these Agile engineering techniques have long been established for back-end code. But what about the front-end? For too many teams, it's dismissed with a "JavaScript sucks!" and unreliable, brittle code.

In this session, we look at what it takes to bring the best of Agile development to front-end code. Test-drive your JavaScript and refactor your CSS.

AGILE ENGINEERING FOR THE WEB from Øredev Conference on Vimeo.

2015 Sydney Keynote

Aug 30, 2016

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:

The Reward

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.

See the presentation and transcript here.

Reddit "Ask Me Anything"

Nov 5, 2014

The Agile subreddit on Reddit invited me to do an "Ask Me Anything" (AMA) earlier this year. We had a great turnout and discussed many interesting topics.

Read it here.

2013's Conference Videos

May 14, 2014

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.

The NDC 2013 video is here.

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.

Professional JavaScript at NDC 2013

Today's applications run on the web, and they're only getting more complicated. The old "toss a few lines of JavaScript on a page and pray it doesn't break" approach just doesn't cut it any more. To be successful developing today's rich web applications, we need rigorous, professional software development techniques. From test-driven development, to continuous integration, to automated cross-browser testing, this session covers what it takes to build JavaScript that lasts.

I gave several talks at NDC 2013. This one is about taking a rigorous approach to JavaScript and minimizing the cost of maintenance. It's a broad overview of the same material that you'll find in the this screencast, but condensed down and focused on technique. It covers build automation, linting, continuous integration, cross-browser testing, and front-end TDD.

The NDC 2013 video is here.

I keynoted on this topic at ScotlandJS as well. Again, as a keynote, it's more about why than how.

The ScotlandJS video is here.

Test-Driven JavaScript Master Class at NDC 2013

You know JavaScript, but do you know how to test-drive it? In this session, we cover the hard problems. DOM testing, mouse events, touch events, SVG, and more--all test-driven, all against multiple real browsers, and all without mocks or other test doubles. Come dive deep.

Note: This session assumes familiarity with JavaScript. We'll introduce the basics of test-driven development briefly, but prior exposure to TDD is also helpful.

My third session at NDC 2013 picked up where the previous session left off. It's a deep dive into the hard problems of test-driven JavaScript development. If you're a subscriber, it covers the same ground as LL9: Front-End Unit Testing in a Nutshell, but it's more conversational. I think it came out well.

The video is here.

Agile Fluency Podcast

Nov 10, 2012

At Agile 2012 this year, Bob Payne interviewed Diana Larsen and me for his long-running Agile Toolkit Podcast. In this thirty-minute session, we talk about our Agile Fluency model.

It's a great interview. Listen to it here.

"Evolutionary Design Illustrated" Video

Nov 29, 2011

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.

James Shore -- Evolutionary Design Illustrated from Matteo Vaccari on Vimeo.

Certification Debate with Alistair Cockburn

May 25, 2011

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.

Listen to the debate here.