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.


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.

Similar topics

Broader topics

Narrower topics

Other stories you might like

  • VMware claims 'bare-metal' performance from virtualized Nvidia GPUs
    Is... is that why Broadcom wants to buy it?

    The future of high-performance computing will be virtualized, VMware's Uday Kurkure has told The Register.

    Kurkure, the lead engineer for VMware's performance engineering team, has spent the past five years working on ways to virtualize machine-learning workloads running on accelerators. Earlier this month his team reported "near or better than bare-metal performance" for Bidirectional Encoder Representations from Transformers (BERT) and Mask R-CNN — two popular machine-learning workloads — running on virtualized GPUs (vGPU) connected using Nvidia's NVLink interconnect.

    NVLink enables compute and memory resources to be shared across up to four GPUs over a high-bandwidth mesh fabric operating at 6.25GB/s per lane compared to PCIe 4.0's 2.5GB/s. The interconnect enabled Kurkure's team to pool 160GB of GPU memory from the Dell PowerEdge system's four 40GB Nvidia A100 SXM GPUs.

    Continue reading
  • Nvidia promises annual datacenter product updates across CPU, GPU, and DPU
    Arm one year, x86 the next, and always faster than a certain chip shop that still can't ship even one standalone GPU

    Computex Nvidia's push deeper into enterprise computing will see its practice of introducing a new GPU architecture every two years brought to its CPUs and data processing units (DPUs, aka SmartNICs).

    Speaking on the company's pre-recorded keynote released to coincide with the Computex exhibition in Taiwan this week, senior vice president for hardware engineering Brian Kelleher spoke of the company's "reputation for unmatched execution on silicon." That's language that needs to be considered in the context of Intel, an Nvidia rival, again delaying a planned entry to the discrete GPU market.

    "We will extend our execution excellence and give each of our chip architectures a two-year rhythm," Kelleher added.

    Continue reading
  • Now Amazon puts 'creepy' AI cameras in UK delivery vans
    Big Bezos is watching you

    Amazon is reportedly installing AI-powered cameras in delivery vans to keep tabs on its drivers in the UK.

    The technology was first deployed, with numerous errors that reportedly denied drivers' bonuses after malfunctions, in the US. Last year, the internet giant produced a corporate video detailing how the cameras monitor drivers' driving behavior for safety reasons. The same system is now apparently being rolled out to vehicles in the UK. 

    Multiple camera lenses are placed under the front mirror. One is directed at the person behind the wheel, one is facing the road, and two are located on either side to provide a wider view. The cameras are monitored by software built by Netradyne, a computer-vision startup focused on driver safety. This code uses machine-learning algorithms to figure out what's going on in and around the vehicle.

    Continue reading

Biting the hand that feeds IT © 1998–2022