So you're 'agile', huh? I do not think it means what you think it means

Doing stuff quickly is only scratching the surface

What if I were to tell you that we knew all the best practices for software development? That they've been proven by actual industry use over the past 25 years? But that, oddly, these practices are not widely done? Well, if you read these pages, you'd probably say: "Sound about right."

Agile is much spoken of, but not as broadly practiced as you may think. It's as if we all knew that the best way to cook a fine T-bone is to first let it come to room temperature – perhaps with a healthy handful of the de Camargue – but instead we just regularly yank it out of the fridge and throw it on a cold pan.

O rly? You've been doing agile since AS/400s?

When I talk with large organisations, all too often they legitimise themselves by telling me how many certified Scrum Masters they have. From the hundreds I hear about, they've setup some kind of factory that's just rolling them off the line. Now, there's nothing wrong with scrum or certification, but it is an odd thing to use as a marker for agility. What matters more, of course, is if the developer teams are actually doing it.

Commenting on his team's experience doing agile, Lt Col Enrique Oti explained the situation this way: "'Agile'. That word should not be used in the government. It's used everywhere. Everyone in the government now does agile training. Every organisation I go to [claims to do] agile development. I went to an organisation recently who'd been working on a project for six years doing agile. They had a Scrum Master! And I said: 'When does your user ever see your code?' and their answer was: 'Never.'"

Although he's talking about the US government and military, in my experience his statement applies many large organisations.

Surveys back this up as well, such as Gartner's annual agile survey. What's astonishing about this survey is how honest respondents apparently are: looking over the results you quickly get a picture that just about half of the organisations surveyed are agile. Summing it up this past June, Mike West points out that 41 per cent of respondents were doing agile with 41 per cent more doing waterfall, and the rest doing other methodologies.

Perhaps it's the $1,295 price tag on these 15 pages of astounding findings from our friends in Stamford, but a shockingly low amount managers seem to be sandbagging on finally moving to agile after a quarter of a century. (Of course, for the cheap, the DevOps Reports can get you a free version of these findings, plus a wonderful selection of Portland hipster visages.)

In general, then, it's wise to be sceptical of any claims about an organisation being agile.

Wagilefall

Even when development teams have nailed agile, pumping out builds weekly gleefully (or, monthly for the languid), as Oti points out above, they often are not able to actually deploy their code to production.

In cases like this, as venerable agile expert Israel Gat told me: "Organisations learned how to fake agile. Many of the agile implementations I witness are actually waterfall on top of agile, waterfall using agile terms." The teams are speedily working through things, seemingly moving fast, and that's what agile's all about, right? They're an agile dynamo trapped in a decadent waterfall process: wagilefall.

Mismatches like this are widespread and, to my mind, are a massive reason why DevOps is so attractive to those who dare enter that labyrinth of definitional confusion. It's been illustrative to think about this divide between fast-moving developers and never-wanting-to-deploy ops teams as a "wall": developers throw the build over this all to release management, walking away dusting off their hands as if everything is done.

Rather than bricks, this wall seems to be built out of help desk tickets. Filing away those requests to set up staging and production environments, let alone even the simplest resources like a licence for an IDE. And when it comes to actually deploying a build to production, file all the tickets you want, bub, you'd better schedule up some meetings if you want something that ground-shaking.

But think of all those 'nice gates'”!

Resistance to change is, of course, not a new occurrence when it comes to IT. That said, again, the memos have been circulating for a good 25 years. Despite this, it's wise to be empathetic to staff who see going agile as simply more busy work for them. Donna Fitzgerald quoted one of her clients as saying: "It meant throwing away everything I spent years building. All my nice gates and all my vast number of required documents. It meant changing out the tools we use. It also meant that we needed to change our mindset about what was important and what the organisation actually wanted us to do."

Yes, indeed, there's much work to be done after the old artefacts of comfort are thrown out. I recently had a conversation with a similarly beset person in a large organisation. There were so many agile methodologies in practices, along with the existing "waterfall" processes, that a team had been put together to map and rationalise this rat's nest of processes into a unified handbook of sorts. You can imagine how that project was turning out.

Blame management

As ever, one of my core theories about improving how software is done is that, more than likely, management is largely at fault for previously hollow victories. In addition to the numerous reasons for staff resistance, management is often unwilling to follow through on the changes needed to bust through a wagilefall.

Do the infrastructure Morlocks hide behind a wall of tickets? Well, the developers aren't going to be able to change that: they'll need management to come in and burn down that wall. Are you getting ensnared in compliance and enterprise architect dead-ends? Again: management.

There are plenty of enlightened managers, but you'd be wise to figure out if you're working for them whether you're on some sort of path to agile awesomeness. If you find them wanting in vim, perhaps they're kind enough to take suggestions – if you're lucky.

Sure, it'll get worse before it gets better

When I talk to people who have reached the other side of going agile, they tend to find that they're accomplishing the same goals of quality software, even with the same benefits of governance and discipline. They're just able to do those tasks more efficiently. Instead of doing audits after the fact, staying up late into the night and working through the holidays, compliance people can automate much of the raw information collection and leave work on time. With smaller chunks of code in each cycles, operations staff realises that diagnosing any errors in deploys is more straightforward. Project managers, previously beset with putting together complex status reports that no one seems to ever actually read, find much more meaning in their work.

Somewhere in there, you'd hope, there's also an improvement to the actual software and the end user's experience, which usually trundles along for the ride. The studies tend to bear this out. As West put it commenting on the agile survey: "Successful agile organisations show significantly higher use of unit testing, DevOps, continuous delivery, continuous integration, test-driven development and refactoring, when compared with unsuccessful organisations."

More importantly: please, let the T-bone rest for a while before cooking it. Otherwise, you could have just gotten by with a much cheaper flank steak. ®

We'll be covering DevOps at our Continuous Lifecycle London 2018 event. Full details right here.