Exploration Through Example

[This is a combination of what I intended to say at XP Day Toronto last weekend and what I did say. Note: After the talk, a couple of people told me that Kent Beck has some videos that make some of the same points. I haven’t looked at them yet.]

[UPDATE: INFOQ has an overview and better link to the Beck videos.]
(more…)

I’m reading a draft of Jim Shore and Shane Warden’s Art of Agile Development. So far, it’s fantastic, packed full of juicy tricks of the trade. I’ll be giving a copy to every team I work with, I’m sure.

I find myself advising new Agile teams to go slower than they could. Here’s the thing: at the beginning, they’re probably working on a bad code base, and they have yet to learn important rules and habits. They will find it easy to go faster than is compatible with making the code more malleable.

They are nevertheless likely to delight the business, because it’s getting actual observable features at a steady pace. They’ve also established a velocity. As they learn more, they will find their velocity needs to decrease. From the inside, a decreasing velocity is part of a necessary improvement. From the outside, it looks like things are going wrong. Pressure arrives, even if only pressure generated internally by the team. They may therefore not slow down enough, which is buying trouble for the long term. That looks like this:

My preference is to go slower at first, but always fast enough to keep the business happy. That’s often pretty easy, as they have such low expectations. With a tolerant business and an appropriate velocity, you have nowhere to go but up. You can improve your skills, your code, and your velocity all at once. Like this:

Now, a bird in the hand is worth two in the bush, a euro today is worth more than a euro tomorrow, and a rational actor might be justified in preferring the first curve to the second. However, the novice teams I coach are in places that have already paid the price for going too fast, so that argument probably does not apply.

Because people are not rational actors and are acting in a world of radically imperfect information, we have to be careful. Because the business will structurally err on the side of wanting the team to go too fast, the team must err on the side of going too slow. In order for slowness to be tolerated, they must have an even more relentless focus on the business value and product-director-pleasingness of the velocity points being delivered. It may also require some mule-like intransigence. (Someone—Schwaber, maybe—once told me that one of the advantages of Scrum is that it has rules. When, for example, a executive wants to take aside a programmer for a special project, the Scrum Master can depersonalize the conflict by saying that The Rules say that means blowing the sprint, and does he really want to do that? It’s a shame the code internals have no such protection.)

We don’t need post-agile. We need pre-agile. More later.

I’ll be giving the keynote at this year’s XP Day Toronto.

Six Years Later: What the Agile Manifesto Left Out. The Agile Manifesto has worked rather well at changing the way software is built, but the Agile movement is now suffering from some backsliding and some backlash. I believe that’s partly because the Manifesto is almost entirely focused outward: it talks, to the business, about how the development team will interact with it. What it does not talk about is how the team must interact with itself and with the code. In the early days, that didn’t matter so much; the right interactions tended to happen anyway. But now it matters. In this speech, I want to talk in some detail about what got left out.

I’m also co-responsible for the Open Space: What XP Projects Forget:

A successful Agile team is a complicated web of… things: people, practices, tools, and so forth. Some of them are well-documented, some not. Even for those that are documented, Andrew Tannenbaum’s motto applies: “People need more often to be reminded than informed.” As more and more Agile teams form, the need for both reminding and informing is increasing.

That title seems like a good motto in general. Here’s a specific instance.

I was on a short consulting trip recently. We talked about Fit. I said the two things that I’ve said to clients at least ten times:

“I recommend using Fit when the product director wants to read the tests or when the data is naturally tabular. If the product director doesn’t care or if the test is a do-this-do-that-check-this type test, I’d rather you used xUnit.”

…

“There are no decent HTML editors. The most tolerable I’ve found is OpenOffice, but they’re all a pain when you want to modify tables.”

There’s a contradiction here. If the product director doesn’t care, why would you write a tabular test in HTML? Because using xUnit means you have to keep columns aligned, and that’s a pain. So use HTML and have the browser line up the columns. But I just said that editing HTML is also a pain. And I never gave much thought to which is the greater pain.

(more…)

This is a retitled version of my SPA 2007 talk, “Monasticism for the Married”. It’s an encouragement to think of things as bundles of actions, framed by some alarm about the state of Agile.

Clearly reason was the goal here, and with Mark and Grace calmly looking on, it struck me just how good men are at agreeing exactly what “reason” is, how it should be pursued, and at what cost achieved.

—Thomas H. Cook, The Cloud of Unknowing

I’m intensely aware that at this time tomorrow, you’ll be hearing from Sir Tony Hoare, one of my heroes when I first got into this field. When I noticed him on the programme, I reread his 1980 Turing Award lecture, which contains this famous quote:

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

When I was young I wanted nothing more than to pursue that first way, but looking back I see that I haven’t. In such a case, the only honorable thing to do is to blame someone else:

(more…)