Accelerating Agile

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 Accelerated Agile. 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 occuring 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 accelerate.


  1. Dan, I think all you really discovered is that a team with talent, and great attitude yet no methodology beats other teams that a simply following whatever is currently considered best practice.

    1. That was my initial conclusion as well, but then I started wondering if there were strategies or behaviours they were using that might be useful elsewhere, or that I could share with other people. As I started capturing and talking about these various behaviours at conferences, people started approaching me and saying “We do that too!” which made me optimistic that others might find them useful too.

  2. On a related topic, I visited an island in the west of Scotland where they have palm trees. I’ve concluded, based on that one data point, that Scotland has a tropical climate ;)

    1. Hi Jason, I’m not sure what you are trying to say here. If it’s that I’m drawing an inaccurate conclusion based on one data point, then you seem to be dismissing the three years I’ve spent since I started working with this team talking to people about what I learned and trying to figure out if there was something more to articulate than “smart people doing good stuff.”

      In that time I’ve been learning how teams in all sorts of different environments are having similar successes using similar patterns and methods. In particular patterns like Ginger Cake, Spike And Stabilize and Short Software Half-Life are resonating with people and generating a lot of interest and positive feedback. Likewise some of the strategies beyond programming, to deployment, testing and monitoring, are getting some interesting traction.

  3. With the amount trading software developers earn you’d expect them to be effective.

  4. There is a saying that goes like “The Tao you talk about is not the Tao”. I don’t think any kind of training will bring one into the position you were in. This was probably a very personal experience, and I am happy for you that it pumped you up with energy and that you are ready to share the word, but don’t be disappointed if the same lame, dragging sh*t comes out of that in a couple of years.

    1. I’m not trying to convey anything spiritual or Zen here, just to share some strategies that I’ve found useful and that others have found useful, in the hope that other people might find them useful as well. None if this is “right” or “wrong” – but some of it might be useful in some circumstances.

      I agree that if people start adopting these patterns as context-free rules, or worse yet Best Practices, then the wheels will come off just like with anything else. The one thing patterns require is context, and the one thing context requires is experience, so inexperienced developers are likely to come unstuck.

  5. KInda agree with Simon. I’d be surprised if this could be taught and/or more importantly, learned and understood.

    It sounds more like something that has to be grown and evolved with the right mixture of people.

    1. I’ve run the Accelerated Agile class a number of times now, with different sized groups and in different formats (one, two and three day versions, for instance). I make it clear that the target audience is experienced delivery folks, and that it isn’t “Dan on transmit” but more a sharing of ideas and experiences. There are lots of small group discussion exercises, for instance.

      The feedback has been universally positive, which is encouraging, and I’m already hearing from course alumni who are applying these ideas and patterns and seeing a positive impact.

  6. Hi, I’m wondering what your take is on Disciplined Agile Delivery (DAD). To me it seems that DAD is trying to improve organisations by adding more “framework”, while Accelerated Agile is trying to do the opposite (values over practices).

    1. I haven’t had any dealings with Disciplined Agile Delivery, but on the surface it seems like yet another huge consulting firm trying to ride the wave by adding swathes of framework, process and methodology to it and selling it to their big-E Enterprise client base.

      One thing that is consistent across all the teams I’ve worked with is discipline. The fastest-moving teams I’ve seen have a level of self-discipline and rigour that I can only aspire to. So I think calling something “Disciplined Agile Delivery” is both insulting to those teams and a pointless tautology. Successful agile delivery is disciplined by definition.

  7. This reminds me of Uncle Bob’s “Programmers Anarchy” – it works, and works perfectly, IF a team has high level of professionalism + high level of team spirit.

    Offtopic: have you made a jackstone yet? :)

    1. “Programmer Anarchy” derives from Fred George and not Bob Martin.

      1. Right, mea culpa.

    2. Fred George and I have been talking a lot about this. There is definitely a convergence in thinking and experiences, and we’ve found our (independently-derived) conference talks are very complementary in terms of their content and message. I’ve even started adopting Fred’s “micro-service architecture” phrase when I’m descibing the Short Software Half-Life pattern. As they say, there’s nothing new under the sun!

  8. Kevin Mulholland · ·

    From the sounds of things you were lucky to get into a skilled, motivated and empowered team who also work well together.
    Making disparate people do this is nigh on impossible, however agile you try to be.

    The key points in order are
    1. Empowered: if your team members cannot make design and coding decisions on their own, you will not get much work done; do not micro manage this.
    2. Work well together: if the team members do not get on, then you will need to have clear lines of responsiblity, project plans, contracts and all of those ‘agile’ things that can stop people being agile. You cannot train people to be friends/friendly, some people just don’t get on.
    3. Motivated: the team needs to want to solve the problems, this makes them work faster, think more. If no one is motivated then things will drag and you cannot be agile then!
    4. Skilled: strangely last on the list, people gain experience and skills, if one or more of the team are skilled, then the others pick knowledge up by osmosis!

    I have been lucky enough to be in teams like this, sometimes there may only be 2 team members, not quite pair programming, but almost finishing each others methods. Sometimes more people and as you say, almost skilled silos of responsibility, ask someone for the code and it is provided asap.

  9. Joe Wroblewski · ·

    Excellent story that really needs telling. The rigid approach to agile is an oxymoron. Agile in NOT a process — it’s a philosophy.

  10. Sabina Kamber Salamanca · ·

    Hi Dan,

    Thanks for telling this story. I would like to share with you a story of the software delivery team within BBC Future Media that I currently work with who undertook transition to agile. Even though we started off introducing an agile process, what actually made us succeed was our ability to create a culture that was based on agile values and started seeing agile manifesto enfold within the team. In my opinion, that is what made us succeed and deliver for the Olympics 2012. Here is our story:

    Would love to hear from you what you think of our story.

    Sabina Kamber Salamanca @sabina_agile

    1. Hi Sabina,

      Thanks for the link. I watched your talk and I think it’s a great story! Thanks for sharing it.

  11. Agile, like the term liberal has been sullied. Even though Agile was originally conceived by programmers, now its most vociferous proponents are those that are not involved in the act-of-coding. I would drop the term “Agile” and replace it with “Anarchy” or “Liberty”.

  12. Dan, first-time here, so pardon the assumptions: you made the article very tantalizing, but provided no hint of any of these patterns – i’m primarily curious if any of the patterns deal with changing existing organizational culture to allow (the whole-hearted adoption first and then) acceleration of agile. i have no doubt that in a place where the money’s flowing, metrics aren’t necessarily being monitored, and management hasn’t ossified into 20th century values, any kind of renegade/agile development would flourish, at least for the short-term (1-3 years)…

    1. Hi Nilesh. Funny enough the work I’ve been involved in over the last couple of years was looking at exactly that: figuring out the organisational and cultural constructs that would allow this kind of delivery to thrive.

      Ironically, the core organisational shift over that time was to introduce more monitoring, metrics and transparency, but of the right kind. Instead of measuring effort and activity (how many tickets get closed, for instance) we focused on results-based metrics like time to resolution.

      That’s why I’ve split the material I’ve been developing into Accelerated Agile, being the delivery-focused technical and behavioural patterns and strategies, and Faster Organisations, which looks at the organisational and operational changes that support that style of delivery.

  13. I saw Dan talk at SDC 2013 and besides his keynote resonating with me deeply, I came away with a simple, oxymoronic phrase: extreme pragmatism. It’s probably not quite right, but it works as a reminder for me.

    All of the XP practices were based on observations of what had worked before. The X was then “turn it up to 11”. I’ve been saying and thinking for years that while I prefer TDD, as soon as I find something better I’ll do that instead. It’s be silly to think that TDD is the end of a journey. Actually, it’d be a rather sad state of affairs if we “figured it out.” Perfection is a journey, not a destination.

    I really like the idea that all software is a liability. It seems to lead to many (all?) of the patterns that Dan talks about under this moniker.

    If I’m being honest, I don’t always practice TDD. You can tell this because I make (in my mind at least) a clear distinction between TDD and test-first, the former being what Bob Martin defines in his 3 laws (emergent design), the latter being writing tests before code that I’ve sort of already figured out via experimenting (or pattern matching requirements to work I’ve done before and reusing a design idea from the past). I typically do this with a new API, library, whatever. I copy something that works, try to get to “ginger cake” with it then I take a step back and either re-do it test first, or I’ll even do it test after paying close attention to test smells. If I take this one step further, I’d only do this if I think the value of the code compared to its “half life” warrants the investment.

    Dan gives an example of testing something that is always used. If, for example, every time I start up a system, something that is ill configured will fail, then is there a need to test it? What if it changes infrequently? What it its structure makes it well neigh impossible to screw up? If I really believe that what I do as a developer is reduce the risk of releasing defects into the wild rather than “prove correctness” (I do), then logically, some of the tests I habitually write are of questionable value. They better at least pay it forward if you will to the next person who has to deal with whatever mess I’ve created (today’s great code is tomorrow’s WTF).

    In any case, based on my read of the comments, I think Dan’s hit on something heretical, in the best possible sense. I’m excited to see where this goes as it seems to have a lot of promise.

    To make my post fair and balanced, I will say that I wonder how this applies to teams that are looking for help. Dan noticed a team that on the surface that did not practice Agile, but at their heart maybe embraced the Manifesto for Agile Development without knowing about it and better than most. Regardless of whether that is true or not, the team was producing business value, reliably, fast enough that Dan noticed his expectations being blown away. Who cares if you know about or practice agile stuff if you’re doing that. Agile is NOT a goal, it’s a mechanism. It, and all process is a liability. Since I’m a consultant brought in to help places that are struggling, my personal filter suggests that these behavioral patterns will be hard to practice since I’m often trying to convince someone that merging your work with everybody else more than once every few months might be a good idea. (To be clear, this is not an example from my current engagement, but it is something I’ve seen in multiple places.)

%d bloggers like this: