Evolution of Agile

31 Aug, 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

31 Aug, 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?

31 Aug, 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

31 Aug, 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

31 Aug, 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"

06 Nov, 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

15 May, 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

11 Nov, 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

30 Nov, 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

26 May, 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.

Agile Release Planning Video

20 Dec, 2010

My recent Øredev presentation, "Agile Release Planning from Top to Bottom," was recorded and the video is now available online. This presentation was very well received and I think it's one of the best I've given recently.

Agile Release Planning from Top to Bottom - James Shore from Øredev Conference on Vimeo.

Video of Bloody Stupid Johnson Now Online

22 Oct, 2010

The Agile Alliance has put up their recording of my presentation with Arlo Belshee, Bloody Stupid Johnson Teaches Agile. This presentation was the highest rated session of the Agile 2010 conference. You'll need to be a member of the Agile Alliance to view it.

If you'd like to see this presentation live, Arlo and I will be reprising it on December 15th (2010) for Agile PDX. This is a free event hosted by the Portland Agile community. Watch the event page or my Twitter feed for the location.

Korean Translation of "The Decline and Fall of Agile"

16 Mar, 2009

Jooyung Han has translated my The Decline and Fall of Agile essay into Korean. Read it here.

"Is Fit Dead?" Conversation Summary

16 Mar, 2009

Eric Lefevre-Ardant has an excellent transcript of a discussion about Fit that I participated in on Twitter a few weeks ago. Here's an excerpt:

It was kicked off by an interview of Ward Cunningham and James Shore on Hanselminutes where Ward & James were asked whether Fit was dead.

Bob Martin first reacted on Twitter by pointing out that, at any rate, “FitNesse is thriving”, along with Slim, a new system that can be used by Fitnesse as an engine to run the test tables.

Michael Feathers replied that, in his view, Fit was more appropriate as a seed for other works: “Take it, grow it locally, and never commit back.” This seems confirmed by James Shore, a former leader of the Fit project (and a successor to Ward in that role): “Fit core was intentionally resistant to change [...] from an organizational perspective”

Interestingly, James believes that both Fit and Fitnesse have “similar flaws, which could be solved by another approach”:

  • Fit flaw #1: maintenance. HTML is hard to maintain and refactor.”
  • Fit flaw #2: Customers. Customers don’t generate the documents, and that was the whole idea.”
  • Fit flaw #3: Programmers. Fit loves domain models and Whole Value. Most programmers don’t. Impedance mismatch.”

If you're interested in Fit, FitNesse, or similar tools, it's well worth the read.

Read the whole transcript here.

"Maximizing Value with Agile Release Planning" Recording

16 Mar, 2009

"Maximizing Value with Agile Release Planning" is one of my favorite presentations to give. It's a thorough look at five ways to improve value on your agile projects:

  1. Work on One Project at a Time
  2. Release Early and Often
  3. Adapt Your Plans
  4. Keep Your Options Open
  5. Plan at the Last Responsible Moment

I delivered this presentation at the Portland IIBA meeting (International Institute of Business Analysts) last week, which reminded me that there's a recording of this presentation online at the Product Management View blog. I thought you might like to see it.

Watch it here.

Interview on Unbound Developers Show

25 Feb, 2009

The Unbound Developers Show just posted a podcast of an interview they did with me a few weeks ago.

The interview came out well. We discussed a wide range of topics, including Scrum, Lean, Kanban, how to adopt Agile, resistance to change, distributed teams, and more. It's worth a listen.

Hear it here.

"Absolutely No Machete Juggling" Review

19 Feb, 2009

Rod Hilton's Absolutely No Machete Juggling blog has a review of The Art of Agile Development. Here's an excerpt:

That said, this is an excellent book on XP. All of XP's practices are covered in just the right amount of detail - giving you enough information that you can adopt the practice, but requiring that you do additional research about the ones that interest or challenge you the most. This allows the book to be a pretty quick read in general, which is beneficial for a team wishing to adopt XP practices soon. This level of detail does have one disadvantage, though: by staying largely in the realm of hypotheticals and ideals, I often found myself thinking that the authors were being naive and idealistic about how easy some practices were to adopt. This made me somewhat more skeptical of the book than I would have been if more detail had been offered, but ultimately I felt the level of detail was right; I did my own research online about some of the things that challenged me.

Read the full review here.

Chinese Translation of "The Decline and Fall of Agile"

08 Feb, 2009

David Wang has translated my The Decline and Fall of Agile essay into Chinese. Read it here.

(This translation is no longer online.)

Chinese Translation of "Beyond Story Cards"

04 Feb, 2009

郑柯 has translated my Beyond Story Cards: Agile Requirements Collaboration essay into Chinese. I don't speak Chinese, but it looks like he did a beautiful job.

Download the PDF here.

Fit Essay in MundoJava

15 Sep, 2008

I have a short essay in the September issue of MundoJava, which was described to me as "Brazil's best software development magazine."

The editors at MundoJava translated my essay to Portuguese, but kindly gave me permission to post my original here:

What is Fit and why does it matter? It's part of your agile bug-prevention arsenal. Unlike the traditional approaches to quality, which focuses on finding and removing defects, agile approaches focus on preventing bugs from being created in the first place. This leads to some pretty amazing results. Experienced agile teams only produce a handful of new bugs per month.

The "agile engineering practices" introduced by Extreme Programming (XP) are part of the reason. These techniques--such as test-driven development, pair programming, collective code ownership, simple design, and energized work--prevent most programming errors. They ensure that the code does exactly what the programmers intended it to do.

Eliminating programming errors is a big step, but it doesn't prevent all bugs. Sometimes programmers misunderstand what is needed. Agile's idea of an involved product owner who sits with the team--an "on-site customer," in XP terms--goes a long way to preventing programmer misunderstandings. They can easily ask questions of the product owner, and she can see the team's progress and make corrections as they go.

These are great techniques, but some bugs still sneak by. Complex problem domains, such as finance or law, have a lot of nit-picky scenarios that have to programmed exactly right. In many cases, even the experts don't agree about the correct answers. In order for the programmers to create the software without bugs, they have to understand all of the possible cases and what the correct answers are. Surprisingly, even the experts haven't thought through all of the possibilities, and they often won't agree which answers are correct!

It's a recipe for bugs, and that's where Fit comes in. More than anything else, Fit is a tool for improving communication and collaboration around business requirements. Using Fit, teams discuss real-world examples of business rules in practice, and Fit automatically checks that the software does what the examples say. This conversation flushes out misunderstanding, errors, and disagreements. The automatic checks force the conversation to be rigorous, and provide documentation and ongoing confirmation.

This ability to enhance communication is Fit's most important attribute. Teams often think of Fit as a tool for testers. Nothing could be further from the truth! Fit's strength is its ability to get programmers and business experts talking to each other, disagreeing with each other, and reaching consensus together. Testers play a role in this process--often bringing up edge cases nobody had considered--but Fit is not a testing tool. It's a tool for collaboration... that happens to automatically check your results.

What is Fit and why does it matter? It's a tool for eliminating defects that arise from the confusion and miscommunication that often surround complex business requirements. It's an important part of your agile bug-prevention arsenal.

"Art of Agile Development" Interview with O'Reilly

20 Aug, 2008

O'Reilly conducted an interview with Shane and me at OSCON in June. It came out well, and this is one of the rare times that Shane and I have appeared together to discuss the book.

InfoQ Video Interview

20 May, 2008

InfoQ just posted a video interview with me. Deborah Hartmann interviewed me at Agile 2007 last year just before the book came out. It came out great, and InfoQ also included a transcript for those of you who prefer reading to watching.

This interview joins a few other good recent interviews: Bob Payne's Agile Toolkit interview, also conducted at Agile 2007, and Clarke Ching's Agile Thinkers interview.

Interview on Agile Thinkers

31 Jan, 2008

Clarke Ching has a new website called Agile Thinkers. It's devoted to interviews with people in the agile community and it looks like it will have some great stuff. (Clarke's already proven the model with TOC Thinkers, about the Theory of Constraints.)

Shane and I are the first ones up. Clarke is putting the interviews up one question at a time--you can either visit the front page and see everything as it comes, or you can jump straight my interview or Shane's interview.

To give you a taste, here's my response to Clarke's first question. There's more on the site.

Q1. Hi Jim, I'm really enjoying your book. I honestly think it is the best agile book I've read - and I've read a good few of them. Good job! Can you tell me a bit about yourself - both personally and professionally? What got you to the point where you could produce such a wonderful book?

Thank you! I should start by recognizing my coauthor, Shane Warden. Shane and I collaborated closely on the book, so that's part of the reason it turned out so well. Another reason would be the sheer amount of time and effort we put into it--I put nearly a year of full-time work into it myself, and that's not counting Shane's effort or the effort of all the people at O'Reilly. I think our open review process helped a lot, too. We put nearly every section of the book online and we got tons of feedback--over 1200 messages were posted to the reviewer list. Our best work started as drafts that got brutal beatings.

So: blood, sweat, and tears. You know, the usual.

As for how I personally got here... you know, it's hard to say. I've always liked reading and writing, even though I was born a hardcore geek. (I placed in my first programming contest at age ten or eleven. I think I would have come in first if my program had actually loaded off the tape drive.) I actually did better on the English portion of the SATs than the Math portion. I also wasted a huge amount of time on Fidonet and Usenet, talking about programming and (in retrospect) being a general pain in the ass. I could spend hours composing careful explanations of why OS/2's Worksplace Shell was better than the Windows desktop. I expended far more effort than the topics were worth, except for two things: I had fun, and I had a lot of practice writing and seeing how my writing was received.

So that's how I learned to write. On the software side, the really core experience was when I had an AppleSoft BASIC program dissolve on me. Applesoft BASIC was old-school: line numbers, two-letter variables, GOTO's, the works. When I was in high school, the complexity of one of the programs I was writing overwhelmed my capacity to keep track of it all. The program just fell apart in my brain. Ever since, I've been fascinated with the human side of programming: if programming is partly an exercise in making the unbelievably complex comprehensible, how do we do that? That led me to structured programming, then OOP, then software engineering texts, then Ward's Wiki, then XP and agile development, and now to questioning what makes software successful. Along the way, I did the same thing I did with writing: I spent hours every day just playing with the ideas, writing programs, writing about programming, and so on. (As well as my professional experience.)

So really, the answer is that, for most of my life, I've had a pretty single-minded dedication to writing, programming, and software development. (The word you're looking for: Nerd.) It's amazing I ever married, let alone reproduced.

"Art of Agile" Interview on Agile Toolkit Podcast

07 Nov, 2007

Bob Payne has a great interview with me up on his "Agile Toolkit" podcast. It's a nice, wide-ranging interview. We start out talking about the book, migrate to a discussion of learning styles, then Bob's Mano a Mano project at Agile 2007, before wrapping up with a discussion of agile tools and CardMeeting.

It's a fun interview. Check it out.