A curious phenomenon#

At the end of 2009 I left the world of agile delivery and consulting to join a small team in a trading firm. I was member number three. The team grew to five in the next few weeks. This team was the most insanely effective delivery machine I’ve ever been a part of. A handful of programmers sitting in amongst a handful of traders, producing state-of-the-art trading systems—with all the integration pain (back office, risk management, connecting to electronic exchanges) that involves—in weeks. Not months, weeks. This is, of course, impossible.

They were doing it without following any of the agile practices that enable teams to perform, or “hyper-perform” if you believe the, um, hype. They weren’t doing TDD religiously. Some, but not religiously. They didn’t use continuous integration (!). They pretty much worked in silos—each person was responsible for one part of the stack, although the team had stand-ups so they all knew what was going on. They didn’t have a backlog. They certainly didn’t estimate stories or do release or even iteration planning. In fact they didn’t use iterations. And yet they were still delivering very high quality software, and their crazy pace was sustainable! This is, of course, impossible.

Coupled with all this, they had a management team—right up to the director of development—who got it. Which meant none of my super-powers worked. My ability to scale huge political hurdles with a single coffee was useless. I would push on heavy-looking organizational doors and they would simply fly open. There was a culture of trust and integrity that I hadn’t seen before. They even had an explicitly-stated policy of “no assholes.” And this was in a company of over 400 people operating in several timezones. This is, of course, impossible.

Getting my bearings#

I went into what I can only describe as culture shock. I needed to either figure out what was going on here or just click my heels and head back to Kansas, where I at least understood the rules. So I decided to start observing and trying to articulate what was going on. That decision was three years ago. Since then I’ve been talking about this phenomenon using various names to describe it. Naming things is hard. To start with I called it Patterns of Effective Delivery, which required me to define the words delivery, effective and patterns. Surprisingly tricky, especially delivery.

Then I simplified it, calling it “Faster Software Delivery.” That didn’t last long, especially since I realized that one thing these guys weren’t delivering was software. They would solve complex business problems using tiny little apps and services—way smaller than the usual behemoths I was used to working with. No, software wasn’t the thing they were delivering—business capability was what they were delivering, using the smallest amount of software they could. “Faster Business Capability Delivery” doesn’t even sound right, so that wasn’t it.

Then I stepped back to look at what they were really doing. They were reducing the cycle time of delivering business capability from months to days. They were using agile values without being slaves to any of the big-A Agile practices. They really did value collaboration over contract negotiation. Their customers—the traders—were on the same side as them rather than across the table negotiating scope or delivery dates. They really did value working software over comprehensive documentation—although they would comprehensively document where it was necessary because they didn’t not value documentation. They really did value responding to change over following a plan. And they really did listen to one another and value each other’s opinions over any process or tool. Maybe this was what the Agile Manifesto was on about all along.

Sharing the love#

So now I’m calling it Software Faster. When I first started talking about Patterns of Effective Delivery in 2010, I had observed 11 patterns I wanted to share—by which I mean repeatable strategies that work in a given context and that resolve various forces while introducing others. Not a recipe or a guaranteed outcome—just a pattern. I now have nearly thirty, so it’s time to write a book.

In the meantime—and here’s the selly bit—I’ve gone independent and I’m running training courses in a number of places over the next few weeks and months. There are one, two and three day versions, going increasingly deeper into the material. More details are available on my site. I’m also going to be speaking at numerous conferences around the place.

The main reason I’m doing this is to learn. If you see me at a conference and any of the Accelerated Agile material resonates with you (“but we’ve been doing that for ages!”) then I’d love to hear from you. Where did it work? Where didn’t it work? I want the disasters as well as the success stories, otherwise it isn’t a pattern, it’s a sales gimmick.

I’m very excited about this—I really think it’s significant. The more I talk to people, the more it seems there’s a sea change occurring in the agile world. We’ve hit a local maximum with all the methodologies that came out of the 1990s. The context has changed, and many of us no longer have the huge, heavy organizational constraints of that decade. It’s time for a different kind of agile. It’s time to go faster.