Why Agile is like flossing and regular sex

The difference between doing it and saying you're doing it


After roughly 20 years, agile software development has wheedled its way into most every developer's mind as The Way Good Software Is Done. Like flossing, while we can all agree agile is a good idea, we're not quite up to snuff on keeping all our teeth in our heads, so to speak.

A recent Gartner survey [registration required] had 37 per cent of respondents saying they were doing agile, while 45 per cent preferred to float along with the traditional "waterfall" approach (the remaining said they were doing "lean," "iterative," or the always delightful "other"). While this isn't world domination, a 2015 report put waterfall at 56 per cent.

Survey data like this can be dicey, and it's best to treat them more like a wet finger in the wind than as rigorous science. That said, the wind seems to be blowing in agile's direction.

"I think from a tactics perspective, Agile is increasingly a 'solved problem'," said Forrester's Jeffrey Hammond when asked about agile adoption in the industry.

"We know many practices that work, and that have been well proven in the field," he added.

Proven as those techniques may be, once again, loose meatware is catching in the gears of progress. As Jeffrey adds, "from an adoption standpoint, Agile is a 'work in progress' mainly because Agile is as much about cultural transformation as it is tactics." Cultural transformation: it'll get you every time.

Indeed, looking back at that 2016 survey, you see that while easier practices like unit testing are widely practiced, onerous practices like continuous delivery and pair programming are mostly ignored by the buffet agilists. Agile is taking its time along the innovation curve, but one gets the feeling that the down-slope folks are methodically being routed, if only through the slow-but-steady siege tactic of retirement.

Beyond The War of the Story Cards

Early on in agile, there were some vicious battles around defining The One True Agile, especially as Scrum rose in popularity. For the most part, these battles were case studies of the narcissism of small differences, though mentioning "agile in the large" practices like SAFe can still be relied on to pop a true believing agilista's neck veins.

Several schools have descended from agile, primarily in the form of "lean" and "DevOps." In practice, these schools should be thought of as types of agile – at most, extensions – rather than so philosophically different as to be called distinct. They're nothing to start a holy war over.

"Lean," as its name would imply, comes from Lean Manufacturing, the continuous learning and "waste" removal process invented and perfected by Toyota. When you put lean Software Development practices in front of Lean Manufacturing people, they react similarly to how I imagine the French would react when presented a baguette à la Piggly Wiggly. The same idea is there, but it's been transmogrified by a new set of hands. In practice, lean software development focuses on putting a small batch approach in place, releasing software as frequently as possible to limit work in progress, and using an end-to-end mindset to discover and eliminate waste.

The idea of "waste" is perhaps the most intriguing and novel part of lean software development: unless an activity adds value for the customer, it's eliminated (más o menos). Once you start asking: "Will this help the customer?" many of the tasks in the so-called LSDC melt away like chicken fat under high heat. A notable variant of lean is the Lean Startup method, which seeks to discover the market/product fit for any given piece of software. This is the school of "pivots" where you continually evolve your software, observing how it's used until you figure out something that people will pay for, or at least use.

Enter the two pizza team

El Reg commenters' favorite, "DevOps," is the last descendant of agile, building from lean along with a dollop of its own special sauce. A canon DevOps isn't a fully "solved problem" yet, but we're getting close. Originally, what became known as DevOps was solving for two things: enabling frequent deployment of software (many times a day) and maximum uptime. For most people, the idea of deploying software daily is the gut-proven opposite of "maximum uptime." However, the disciplined, small batch mentality practices of DevOps have been showing that the two can be done in tandem.

One of the key components DevOps adds to agile is the idea of a small, cross-functional team rather than "silo'ed" teams. Agile-minded developers land-grabbed QA early on, but mostly stopped there. In contrast, DevOps looks to gobble all the roles, from developers, to operations, to designers, product managers, and whatever other role is needed to make sure you can ship useful features frequently and keep the stuff up and running.

Though there are numerous roles, the teams are small. As Ben Terrett, former head of the UK Government Digital Service, put it: "[T]he best way to do this stuff is to get a multi-disciplinary team of people in house – designer, user researcher, developer, content person – you're talking a team of about twelve people." In Amazon terms: no team should be so large that it needs more than two pizzas for dinner.

Admit it: you have no idea what's going on

Recently, I've been asked several times to address when waterfall is a good choice. The answer to that question is good insight into agile's trick. Waterfall is fantastic if you know exactly what you want to build, up front. What a wonderful project that'd be to work on!

As most of the people who develop software find, however, very few people know exactly what needs to be built ahead of time, least of all the actual users and customers.

Agile, instead, builds its thinking and processes around the assumption that we can't know what the software should be until we start deploying it to actual users. Doing so isn't easy, and while adoption has been slower than you'd expect, as was said long ago: if you are made to wait, it is to serve you better, and to please you. ®

Similar topics

Broader topics

Narrower topics


Other stories you might like

  • Millions of people's info stolen from MGM Resorts dumped on Telegram for free
    Meanwhile, Twitter coughs up $150m after using account security contact details for advertising

    Miscreants have dumped on Telegram more than 142 million customer records stolen from MGM Resorts, exposing names, postal and email addresses, phone numbers, and dates of birth for any would-be identity thief.

    The vpnMentor research team stumbled upon the files, which totaled 8.7 GB of data, on the messaging platform earlier this week, and noted that they "assume at least 30 million people had some of their data leaked." MGM Resorts, a hotel and casino chain, did not respond to The Register's request for comment.

    The researchers reckon this information is linked to the theft of millions of guest records, which included the details of Twitter's Jack Dorsey and pop star Justin Bieber, from MGM Resorts in 2019 that was subsequently distributed via underground forums.

    Continue reading
  • DuckDuckGo tries to explain why its browsers won't block some Microsoft web trackers
    Meanwhile, Tails 5.0 users told to stop what they're doing over Firefox flaw

    DuckDuckGo promises privacy to users of its Android, iOS browsers, and macOS browsers – yet it allows certain data to flow from third-party websites to Microsoft-owned services.

    Security researcher Zach Edwards recently conducted an audit of DuckDuckGo's mobile browsers and found that, contrary to expectations, they do not block Meta's Workplace domain, for example, from sending information to Microsoft's Bing and LinkedIn domains.

    Specifically, DuckDuckGo's software didn't stop Microsoft's trackers on the Workplace page from blabbing information about the user to Bing and LinkedIn for tailored advertising purposes. Other trackers, such as Google's, are blocked.

    Continue reading
  • Despite 'key' partnership with AWS, Meta taps up Microsoft Azure for AI work
    Someone got Zuck'd

    Meta’s AI business unit set up shop in Microsoft Azure this week and announced a strategic partnership it says will advance PyTorch development on the public cloud.

    The deal [PDF] will see Mark Zuckerberg’s umbrella company deploy machine-learning workloads on thousands of Nvidia GPUs running in Azure. While a win for Microsoft, the partnership calls in to question just how strong Meta’s commitment to Amazon Web Services (AWS) really is.

    Back in those long-gone days of December, Meta named AWS as its “key long-term strategic cloud provider." As part of that, Meta promised that if it bought any companies that used AWS, it would continue to support their use of Amazon's cloud, rather than force them off into its own private datacenters. The pact also included a vow to expand Meta’s consumption of Amazon’s cloud-based compute, storage, database, and security services.

    Continue reading

Biting the hand that feeds IT © 1998–2022