A long twitter thread was started by Nicole Sullivan, with some notable ideas from Marlena Compton (and many others).

Now I can’t do justice to the ideas of these fine women, nor to the many others who chimed in. Read their words, engage with them to get their ideas. But here is a simplified list of what I got from the thread1:

  1. XP is good but needs some revision.
  2. The XP founders don’t even program any more.2
  3. Where are the cool new voices?3
  4. XP style, especially pairing, doesn’t fit everyone’s thinking style.

Well, aside from the quick replies found in the footnotes and the twitter stream, what I mostly wanted to think about was what I’d say if someone were to ask me to define a software development method. Presumably I’ve learned something in the 20 years since I got into XP. I wonder what it might be …

Some major concerns

A wish

I probably need a misconceptions tag to deal with all the things people say about XP and Scrum and “Agile” that are not at all what the founders taught. You’ll find a lot of those articles under the success tag, but you’ll find other things there as well.

We could have a fine discussion about what “Agile” means today. Does it mean what we meant when we wrote the Agile Manifesto, or is it some average of all the things that people think, no matter how much or how little they’ve actually read their homework? Well, “Agile” was such a good name that everyone wanted to have the t-shirt, and with all the companies built up around Agile ideas, and around Scrum, there’s no doubt that what the world at large understands of those ideas, and what the authors intended, diverge quite a lot.4

With XP, rather than “Agile”, it’s not so bad. While there are books about Agile or Scrum that contain really mistaken ideas (in my fairly well-informed opinion)5, there is very little published about XP that I’d object to, other than some books and web sites that are just all about “XP is bad”. Those are invariably ill-informed.

Nonetheless, people on the Twitter thread described here did get some things wrong. Have those people read Extreme Programming Explained or Extreme Programming Installed or any of the early XP books? It seems that they may not have done so. That’s troubling. When we set out to criticize something, we ought to know a lot about it.6

Anyway, I wish folks would study the material well before deciding that they know what is, or is not XP.7 A man has to have a dream.

We don’t need yet another method

Probably the first thing I’ve learned is not to define yet another method. When we wrote the Agile Manifesto, it was about values and principles. That was pretty fine. Shortly after that, everyone and his brother created a method. Scrum had already been defined. XP was either defined or close to it. DSDM had been around for a long time. Quickly thereafter we got a cubic bunload of new methods, and it has never stopped. Everyone wanted a method of their own.

In addition, as there got to be more interest – and more money – in XP/Scrum/Agile, more and more people told the stories their own way, and if they were consulting, named their company Advanced Agile Scrum Inc, and if they wrote a book, called it Quality-Oriented XP, trying to make their version seem more appealing while subtly implying that your brand, whatever it is, is not advanced or not quality oriented. In short, too many methods already. Let’s not create a new one.

We shouldn’t version XP

Kent Beck explicitly decided not to trademark XP. I’ve chosen to honor that thinking, although others have not. It seems to me that if there were to be a new version of XP, it would be up to Beck to do it, not for anyone else. So that’s not on.

There is one supposedly Agile method that does version itself. I think it’s up to 4.0 at this writing. I don’t know how much it has changed, but if it has changed a lot I have to wonder about about all those people who were sold version 1.0.

Anyway, I’m not going to produce XP 2.0. I will talk about XP at the age of 20.8

The “must, should, might, don’t” axis

Methods often mean “here’s some stuff you need to do”. Even when a method is explicitly meant just to be a starting point, it is often interpreted as meaning that you have to do these things forever. As a team learns, it becomes clear that some of those things were training wheels and that there are better things to do than the dictates of the method.

Methods often ask you to do things that are very difficult to do. For example, Scrum asks, nay demands, that you produce a running, tested, shippable increment of software, including all the functionality that has gone before, in every single Sprint. The team decides well that’s too hard and now they’re not doing the method at all and then they hate the results they get and blame the method they’re not doing.

Methods can’t mention every dumb idea that some team somewhere might have and say “don’t do that”. For example, in the Twitter thread mentioned here, Ms Sullivan referred to a “three month rotation”, where the company essentially replaced the team every 90 days. This is not an XP practice, and in fact it pretty much flies in the face of the Agile values and principles. However, as far as I know, no XP book ever said not to do that, and somehow Ms Sullivan, with the best of will, thought it was part of XP. I imagine that someone in the company actually said that it was. We often find teams doing things that are not part of the method they’re trying to do, and that are actually harmful. Somehow, they don’t realize it’s a problem.

This presents quite a quandary. Somehow we have to cater to at least these concerns:

  • There are things you really need to do pretty much forever;
  • There are things that are really hard and you’re tempted not to do them;
  • There are things you should start with and then move beyond;
  • There are things you should probably never do (and a lot of them);

It’s all about thinking

Too often – on a bad day I think it’s always – people adopt a new method, or have it imposed on them, and they more or less take it as given, and stick to it, except for the things they drop because they’re too hard or too boring, and they never think at all deeply about what they’re doing or how to truly do better.

Unfortunately, the only way we ever learn to do better is to try things, pay attention to what happens, and then figure out better things to try next time. No method will deliver excellent results to a team or organization that isn’t continually thinking and working to improve.

Surely we’ve learned something over all these years …

Enough about why we don’t need Yet Another Method, or about how hard it is to define a method that can be understood even if you don’t actually study it, and that works even when you don’t actually do it. We’ve learned some things over the last two decades. Maybe it’s time to write about them. This XP@20 category will point to some articles about what we’ve learned. I regret that these words come from an old voice, that’s part of my territory. On the other hand, why would you want someone who doesn’t know what XP was to tell you what XP is?

Anyway here are some short snippets on topics we’ll probably write about as this category grows:

Nature

Really, I wish you’d read The Nature of Software Development. It’s brief, thought-provoking, and full of pretty pictures. It summarizes my overall views about how software should be done, based not only on the past two decades of “Agile”, but on the whole half-century I’ve been doing software.

And please:

  1. Please buy the book directly from Pragmatic Programmers. I get a decent royalty when you buy direct. I get about 1/10 of that if you buy from Amazon. So, please.
  2. Get the paper copy. It has pictures, and a layout to make them work. It’s better looking, and if you run into me some day, I’ll autograph it. If you can’t stand paper, then I really hope you have a color e-reader, because the pictures are in color.

The Increment

If I were to be required to relive my life – and I really don’t want to, although a newly youthful me would be nice to have – one change I would make in my software development role would be to always, always have an increment.

“The Increment”, as defined in Scrum, is the result of each and every Sprint, including the first. It is the running, tested, ready-to-ship version of the software. It contains, running and tested, every feature, story, item that has been put into the product from the very beginning.

When a development team produces a running increment in every cycle, it changes the game more than any other single change. Rather than talk about when you might, when you will, are you ever going to, you have the software right there for everyone to see. You have tangible progress, all the time. With even the limited ability I have to negotiate and explain, I could do far better than I did in the past.

If I write another book, it might be called “The Increment”. There are articles here already.

Short Cycles

The Manifesto says:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

That’s so last-century! What we have learned over the years since those words were written is that if you’re going to work with iterations, one week is better than two, and a couple of months isn’t even on the table. Furthermore, it seems likely that the ideal end point eliminates iterations altogether.

That’s right. The top XP teams today are taking on one story at a time, finishing it in a couple of days, and releasing it right then. They don’t wait until a week from Friday or even until tomorrow. When it’s done, it goes.

Mind you, you may still want some cadences. You’ll want to plan on a regular basis, maybe still every week, to be sure you have enough new ideas in the queue. You’ll surely want to have regular retrospectives to improve your process. You’ll want regular meetings with stakeholders. And so on.

What you won’t need is a “Release Train” or a “Hardening Sprint” or a “Release Sprint”. When you’re done, it ships.

Dials to Eleven

Back when Kent Beck formulated XP, he sometimes referred to it as turning all the dials to eleven. If testing is good, test all the time. If working together is good, work together all the time. And so on.

Twenty years later, I still think this is a good notion. It does have to be applied with skill. Planning is good: that doesn’t mean we should plan 24/7. It does mean we should plan often, and quite possibly more often than we think.

We learn the most about a technique when we work it to the bone. Take TDD for example. I love TDD. I find that it (almost?) invariably makes me go faster and (absolutely) invariably gives me more confidence. Yet sometimes I do not do TDD. What’s up with that?

Well, it’s interesting to contemplate what would happen if my computer refused to let me code until I had a test for whatever I was trying to do, but if I had a feature like that, I’d turn it off. Sometimes, the only way I know to even express what I want is to code something. Sometimes, I just do not know how to test what I want. I have to move forward, so I code.

Nonetheless, I know how to do TDD down to the finest grain you can imagine. I still use the “fake it till you make it” pattern, where I write a test and “make it run” by returning the constant the test looks for:

testPerfect():
  rolls = [10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10]
  game = BowlingGame(rolls)
  assert_equals(300, game.score())

BowlingGame:score():
  return 300

We do that because we’re trying to get the shortest possible time between conceiving a test and having it work, and because we know we can – and will – improve the code to make it more capable, and better designed, as we go along.

For all the practices we learn, I think we should practice them all the way to “dials at eleven”, because only by over-doing will we ever learn how far we can go. Now if we were talking about jumping off high objects, I’d not be telling you to keep going until you’re injured or die, but nobody died from writing a test or two that they found didn’t help.

And many more …

So there are some hints about the things I’ve learned about XP (and Scrum and “Agile”) over the years. It might be worth working up a summary of what I think it is today. I’ve created the new category XP@20 to contain future articles on the subject. I’ll be watching the Twitter stream for hints what to write about.

Thanks for tuning in!

  1. The format of that page is a bit odd. Try to read past that and get the many good ideas and concerns.

  2. Kent Beck, Ward Cunningham, and I all replied that we are all still programming. So there, I guess.

  3. I recommend checking out the XP conferences, as there is a very active and vibrant XP community in the UK and Europe. It looks to me as if there’s a decent mix of new and not so new voices there.

  4. We could have a similar discussion around ideas like “democracy”, or “Christianity”, or “Islam”, or any of a number of other ideas. What people know of them can be pretty minimal, while meanwhile they spout about those ideas as if they actually had a clue.

  5. No, I won’t name them.

  6. When you catch me doing that, call me on it. I try to be clear about what I have heard, what course I’ve taken, what I’ve actually done, but if I’m not, do bring me to heel.

  7. That said, I don’t really believe there’s a bright line between what is, and is not, XP or Scrum or Agile.

  8. XP is 20: the C3 project started in February 1996. I am not 20. I started existing rather a long while before that.