Culture, schmulture. DevOps, agile need to be software-first again

Decades of preaching about meatware complicated dev life

Converting cowboys to suburbanites

Nonetheless, as failures continued to rack up with this "big upfront" approach, people kept returning to those tales of success from deep in the Wild West of agile. With a few revs and splattering on some enterprise seasoning, the precepts of agile slowly became what everyone was doing. At least, what people claimed they were doing, ongoing surveys on agile practices actually in use continue to show slow adoption over 20 years later. Everyone's agile in spirit!

Early on, in 2001, the agile manifesto codified a mantle of principles, all wonderful sounding and terribly humane. For my money, the crowning achievement was the idea to value "responding to change over following a plan". In other words, as that hard-working, humble golden retriever put it: "I have no idea what I'm doing."

Among many competing agile thought-technologies, Scrum won out. There are many possible reasons why scrum was so widely and commercially successful: perhaps because of its highly structured nature, perhaps its training and certification system, and maybe because it actually worked! Many organisations still eagerly tell me how many certified scrum masters they have as a metric of how improved they are.

Customers are people too

There's an oft-forgotten milepost at this point, a strange little book called The Cluetrain Manifesto from 1999. The cadre of authors posited that the web was rapidly breaking down any geographic barriers and asymmetric strategies that enterprises used to retain and cajole customers. Things like reviews in Amazon and using eBay to find anything you wanted across the world broke down long-cherished strategic controls companies relied on to maintain market share. It was a sort of pulling back of the wool and empowering customers to be smarter than the octopus global-nationals, as we called them back them.

Cluetrain concepts were much toyed with throughout the 2000s, with companies investing much blood and treasure in capturing market share, ahead of monetising.

Paying attention to what people were doing with your software and improving the software to keep hold of their eyeballs longer was a popular business, and it still is. There's an ever-growing pool of revenue in never-ending conversation markets. Last quarter alone, Facebook earned $9.3bn in revenue with in $3.9bn profit.

In the land of eyeballs, the profitless win

Getting to those kind of eye-popping profits required new thinking when it came to both builders and users. As companies like Google, Netflix, Facebook, Amazon, and numerous others who lost to the buzzsaw of product/market fit built out their businesses, often their only success metrics were user growth and retention. They had to create exceptional software.

To do this, these companies competed on features, on the exceptionalism of their software. They had to start releasing software every week, if not every day to compete. As one of the Agile Manifesto principles put it: "Deliver working software frequently."

Of course, having the software actually work most of the time was important, as Twitter early on showed, somehow surviving, perhaps as the world's first example of the "move fast and break things" boast. Faced with the need to release software on demand, often daily, the enterprise approach of doing monolithic, gut-wrenching releases wasn't cutting it. The developers had to start thinking about and how their software was managing in production.