Proving that agile works is a waste
Schwartz's new book is, of course, good: War and Peace and IT. He's the rare tech book author who has style, let alone business book writer.
An excerpt on one of my favorite points about software management:
But here is a catch. When organizations that are used to the old way of working begin to adopt Agile techniques, they tend to spend a lot of time preparing their tentative list of features. They over-specify each one, rather than letting users work with the technology team to refine them. Rarely do they step back to reevaluate what they need and then freely change the requirements. In other words, they reintroduce inflexibility into a process that is meant to maximize flexibility. To transform, you accept the gift of flexibility and thank the Snowbird gurus.
Those who desire certainty in software suck out the advantages of it being agile. They destroy the high value attribute of software: you can make it do anything you want, and change it quickly. You can't do that with factory lines, government policy, and much else.
Proof is near impossible to find
This book, as with most all agile and digital transformation books, is amazing in its lack of proof points. Mostly, it lists all the best practices and makes intuitive arguments, like the above, that you should do them.
The advice in the book should just be done, because, like, it's good and make sense.
Don't get me wrong, dear reader, I agree with the advice in the book because I'm, you know, an "agile native." But this approach is open to people who ask questions like "when is it better to do waterfall?" a question I've been asked many times over the years. There's not really a chart to answer that with - maybe some artful cuts of Standish data.
Much of the agile literature is like this: little real world proof that these practices are good for most applications. The wonderful Escaping the Build Trap is like this too: she even has to make up a fictional company as the ongoing, illustrative case study!
Finding good case studies is hard. Most people don't want to spend the time to tell you their stories, let alone make them public. Case studies are scarce commodities, and the situation they live in is often unique or fluid enough that you can't generalize too much. (This is why most case studies leave you with that feeling after a $290 "tasting menu": "so...want to go get burger now?")
In many agile management books, the author is the source. Schwartz was a CIO at several companies, Melissa Perri has consulted on many real world projects, and the same for the authors of the agile manifesto and Lean Software. That's something, at least, and good enough for government work, as they say.
To use another perspective to remove the holy shadow of agile from it: go read ITIL and waterfally literature. It tends to rely on the same footnoteless declarations of good practices. And, when you read the actual waterfall canon, it intuitively makes sense as laid out.
No one sits down and thinks: let's write a software development methodology that sucks goat-ass. Even committees.
How do we know any software methodology and IT world view is "true"? How do we know other systems (waterfall, SAFe, and agile's uncountable bête noires) aren't just as good or more cost effective?
Proof is waste
What we know is that all that time spent tracking and study the data needed to answer those questions is waste in Lean, all that project reporting that's not focused on delivering actual software:
In the Lean sense, waste is any activity that doesn’t add value to the finished product, or, as some experts phrase it, activities that a customer wouldn’t be willing to pay for. I like to refine this definition a bit—to me, waste is any activity that doesn’t add enough value to justify its cost in dollars or additional lead time.
There's a paradox of agile IT improvement: measuring the value of your processes is time consuming and likely not profitable, usually "waste." Therefore, by its own rules, we can't know if an agile process is "good." The only judgement we can make is that we're shipping software and that it's working.
Mik Kersten's company TaskTop seeks to solve that problem by automating all that reporting, most importantly the integration, converting, and ETL'ing of project related data across tools and silos. Their stuff seeks to automate project governmance so you can focus on product work. (I haven't checked in with them for years, though, so my understanding is out of date.)
Schwartz, as everyone, references Accelerate as the proof point for DevOps:
In their research, they found that the companies making the most use of DevOps practices were 1.53 times as likely to meet or exceed their organization’s goals—including, for example, profitability, market share, productivity, units sold, and operating efficiency.
Their employees were also 2.2 times more likely to recommend the organization as a great place to work, which in other studies has been correlated with better business outcomes. For those companies that are publicly traded, high performers in these IT practices had 50% higher growth in market capitalization than low performers.
At the moment, that's sort of all we have. Each year I'm curious to see more details on how "high performers" relate to creating "business value," in the for-profit world, increasing revenue and (if an older company) profit. I'm not sure I've ever seen charts on that. I don't doubt that the charts would show us what we want to see.
I'm guilty of all of this in my writing and nonsense as well. This paradox is inescapable, and doesn't really devalue the helpful, ongoing work. It's just annoying, intellectually.
And, to rephrase how Andrew once answer the when to use waterfall question: when you're 100% sure you know what you want ahead of time, and don't want to change it.
Relative to your interests
I could do with three more hours. Jia Tolentino's essay essay "Ecstasy" is flawless and delightful: perfect. I don't know what head-place this is, but I could spend a lot of time there. Apple is a slow follower, and a deadly one of you’re the one being followed. You’ll never need more than 64k of RAM, or whatever. Media has always been key to culture change, even -especially! - woodcuts of demons pooping. Smells like “balls deep in appropriation.” "I said to the rabbit, 'are you gonna make it?' and the rabbit said, 'Well. I got to'."