The tyranny of agile

“The tyranny of agile.” Never thought you’d hear me say that, did you? We’re the folks who got all up in the State of California’s business about running the new Child Welfare System as an agile project. (And the State embraced it!) Code for America preaches the user-centered, iterative, data-driven gospel. (Not exactly the same as agile, but related.) I’m one of the authors of the White House’s Digital Services Playbook, play 4 of which is “build the service using agile and iterative practices.” We’re kind of into agile, really.

But when Simon Wardley invokes the “the tyranny of agile”?—?or lean, or six sigma?—?I know what he means. And on behalf of the government tech in the US, it’s time to start talking about how one size does not fit all. Simon is a former CEO of a pioneering cloud computing company and a researcher for the Leading Edge Forum. He’s become widely known for a technique called Wardley Mapping that helps business and government leaders understand their technology landscape as it stands today and as it evolves. Simon has been offering this technique for 10 years now, and his following is rather enthusiastic. Leaders who take his workshop swear by the technique. (And the only workshop he’s running in the US this year is at the Code for America Summit, this November in Oakland.)

Why do we experience any of these doctrines (agile, lean, six sigma, in house, outsourced) as tyranny? Well, in the current moment, in government largely, it’s been the tyranny of waterfall, not agile. Most government IT projects have been relentlessly shoehorned into waterfall project management nightmares for the past few decades. Agile has been the knight in shining armor who rode in and broke waterfall’s grip on procurement, the key to power. But can we solve all of government’s technology needs through agile development? When you consider that much of what ails government today is the use of custom development at high cost when a commodity product is readily and cheaply available, we must acknowledge that agile is one useful doctrine, not THE doctrine. We need a roundtable of knights, not one Sir Lancelot. (I don’t love this metaphor, but let’s just roll with it, okay?) The problem is that we don’t always know what fits where, and instead try to adopt methodologies across the board based on what’s worked for us most recently.

This?—?and a few other problems –- are what Wardley Mapping is designed to solve. Like all maps, they are visual representations of the landscape of your business, and they become most useful when they also represent changing conditions over time. The Y axis represents value, with user needs at the top. The provider of a service cares about everything?—?from users needs to what compute we used and even what electricity provider we employed. But the users just care about the value they get out of using the service, in this case storing and manipulating pictures online. The X axis runs from genesis to custom built to product (+rental) to commodity. Here, for example, is a map of a business Simon ran back in 2005.

I mention 2005 because these maps capture a moment in time, and each of these components are likely to move on each axis over time. As we all know,what’s novel and unique today becomes commonly available and then ultimately a commodity over time, and keeping up means taking advantage of that constant movement at the right speed.

I remember one of the stories my husband Tim O’Reilly told me when he was learning about government in 2008 and working to articulate the principles of “government as a platform.” At a dinner with a US senator and several Silicon Valley business leaders, Reid Hoffman mentioned Moore’s Law. The senator asked what it is. Reid’s answer went something like this: “You know how every year you expect to pay more and get less from the things you buy? In Silicon Valley, it’s the opposite.” When government gets stuck in one mode of procuring software, or gets stuck with one system over many years with high maintenance costs, it fails to take advantage of the falling costs of commodity technology. It’s one reason government tends pays so much for technology that seldom works well.

Mapping also allows you to find duplication of commodity services, and, according to Simon, to find some solace in the fact that the private sector is possibly worse about duplication than the public. “In a pharmaceutical company, I once found 340 teams all doing the same thing and I thought that was a record. But then I found an energy company who had 740 of the same thing, and the bank with over 1000 duplicative systems.” To be fair, the US government may hold the record here; the Pentagon was once said to have 2,258 legacy accounting systems, though it’s not clear these were all software-based. This form of mapping may well have helped make it clear that these were commodities that could reasonably be consolidated for cost savings. It might have also helped reduce the cost of that replacement, which in 2012 had already spiraled to $2.66B and yet still resulted in “an inability to generate auditable financial reports, and the need for manual workarounds.” That doesn’t sound good.

So it’s not agile we are rebelling against, it’s the tyranny of misapplied doctrine. As Simon points out some principles are context specific e.g. flanking an opponent only works when the opponent is at the point you’re flanking. Others are more universal such as focus on user needs. If you don’t understand the landscape then it’s impossible to distinguish between them and easy to copy and then apply a successful context specific approach to the wrong context or to misapply methods such as efforts to go “all agile”. Surge pricing might be all the rage and a popular meme in some sectors but as Simon puts it, “try applying surge pricing to funeral parlours”. Another trend that he points to is that of “bimodal IT” which he argues fails to cope with evolution effectively despite being the meme of the moment. In the world of Wardley maps, you understand the landscape first and then apply methods as appropriate.

I’m confident that agile would have been a better choice for building healthcare.gov, and I’m pretty confident that agile, custom development is the wrong choice if what you want is, say, Slack. This is also probably a good time to remind you that if you think you need a whole lot of bells and whistles that make your project drift forever towards the left on the map, you should consider that it’s likely to cost you not 10% more, but more like 10x or 100x more. Re-read Mike Byrne’s delightful “fixie federal IT paradigm” for an entertaining refresher on the subject.

Think Wardley Mapping could help your IT department understand the landscape, plan and strategize? Want to learn it from Wardley himself? If you’re one of the city CIOs I’ve talked to this year charged with supporting over 2000 legacy applications, this might be worth your time and a bit of your professional development budget. You can read more about how Simon came up with Value Mapping here, here, and here. And you can come to Oakland November 1st and register for the Code for America Summit. I’ll be there!