Design Agile bridges to the future

In 1960, Geoffrey Anthony Jellicoe unveiled his plans for Motopia: a city of the future in which cars drove on the tops of buildings, and pedestrians were transported by moving walkways at street level. Freed from the need to dedicate land to roads, Motopia would be a city of parks and trees. Unsurprisingly, Motopia was never built, and it’s possible that it was never intended to be built.

Technology architects in large enterprises sometimes look like Jellicoe presenting his grand ideas, and often feel like Jellicoe when those grand ideas are never realised. We paint pictures of the future based on exciting new technology, while others wonder whether that future is possible, and whether it is somewhere they would actually want to live (or whether cars would fall on their heads).

In an earlier blog post I said that if people don’t understand architects, then it is our fault, not theirs. This is just as true of strategic visions as it is of day to day design decisions: no-one is obliged to understand us or back us if we can’t explain ourselves, and if we can’t make it clear how we get from here to there.

Defining strategic visions is hard, but figuring out how to achieve them is even harder. How do we solve this most difficult of architectural problems? How do we bridge the gap from strategy to execution, and get the future built?

There are very familiar ways that we can try to bridge this gap. We can define elaborate future state architectures, we can define multiple transition states, we can define complicated portfolios of programmes and map the dependencies between them. We’ve all tried this: I know that I have.

There is only one problem with this approach: it almost never works. There is a reason that documents labelled ‘future state architecture’ are still labelled ‘future state architecture’ years after they were written: because they describe a state which is still in the future.

I think that a better answer may lie in the ways of working we call DevOps and Agile.

This may sound counter-intuitive to some architects. Surely DevOps and Agile are all about the short term, about delivering value today and tomorrow, not about delivering strategic outcomes over several years. (And don’t many architects suspect that all these Devops and Agile enthusiasts are cowboys who will compromise their architecture at the first opportunity?)

The reason that I believe that DevOps and Agile can help us realise our strategic dreams is that they have a very different relationship to their software products from traditional waterfall projects.

For traditional waterfall projects, the software product is a final outcome. It is a thing we strive towards over months or years, deliver, and then move onto something else. We only have one shot to get this right, so all design decisions are highly charged. This means that, as architects, we steadily see our vision eroded under a succession of tactical choices required to meet the deadline. We might get a chance to put it right in phase two, but we all know that that’s never happening. Once the thing is done, it is done. Any major changes belong to another project in another investment cycle.

For Agile projects, delivered by DevOps teams, the software product is never finished. It is always a provisional thing, which delivers value right now, and is always capable of being improved. And improving it is what we’re going to do next. And next. And next.

In a waterfall project, a tactical choice is often a major, regretted compromise. In an Agile project, it is simply the thing we are going to do now: the stigma we attach to ’tactical’ choices starts to fade.

Of course, there is still a role for a strategy. There is still a reason we are making all these changes, and there is still a goal we are heading towards. And it is still hard to stick to our strategy with faith and energy: we still need the Zang Jing Ge qualities of technical excellence, communication mastery and leadership power to keep us headed in the right direction. But, when we proceed in small steps, with room for adjustment, we have room to take the occasional sideways step without compromising the whole journey: there is always a chance to put it right, and that chance may come as soon as tomorrow.

It’s been clear for a long while that architects needs to master Agile and DevOps as means to deliver immediate change; it also seems that they need to master Agile and DevOps to deliver strategic outcomes.