A competitive arena, as opposed to an industry, is used as a primary lens through which to understand the world and therefore what the effects of a potential inflection point might be. Think of an arena as a definition of the setting where customer need connects with company solution to create value. An arena can be seen as super sized and strategic use cases that enable an organization to concentrate on what is really going on. It provides a tool with sufficient scope for meaningful change without falling into strategic paralysis. This is one idea that make the book worth the read.
We don’t absorb aphorisms as esoteric wisdom; we test them against our own experience. The empirical test of the aphorism takes the form first of laughter and then of longevity, and its confidential tone makes it candid, not cynical.
Source: The Art of Aphorism
If there’s one complaint that I hear consistently in my studies of IT in large organizations, it’s that government IT, as traditionally practiced, is fucked. Compared to the private sector, the amount of paperwork, the role of contractors, and the seeming separation between doing a good job and working software drives all sorts of angst and failure.
Mark Schwartz’s book on figuring out “business value” in IT is turning out to be pretty amazing and refreshing, especially on the topic of government IT. He’s put together one of the better “these aren’t the Droids you’re looking for” responses to ROI for IT.
You know that answer: you just want to figure out the business case, ROI, or whatever numbers driven thing, and all the DevOps-heads are like “doo, doo, doo-doo – driving through a tunnel, can’t hear you!” and then they pelt you with Goldratt and Deming books, blended in with some O’Reilly books and The Phoenix Project. “Also, you’re argument is invalid, because reasons.”
A Zen-like calm comes over them, they close their eyes and breath in, and then start repeating a mantra like some cowl-bedecked character in a Lovecraft story: “survival is not mandatory. Survival is not mandatory. Survival is not mandatory!”
Real helpful, that lot. I kid, I jest. The point of their maniacally confusing non-answers is, accurately, that your base assumptions about most everything are wrong, so before we can even approach something as precise as ROI, we need to really re-think what you’re doing. (And also, you do a lot of dumb shit, so let’s work on that.)
But you know, no one wants to hear they’re broken in the first therapy session. So you have to throw out some beguiling, mind-altering, Lemarchand’s boxes to change the state of things and make sure they come to the next appointment.
Works as Designed
Anyhow, back to Schwartz’s book. I’ll hopefully write a longer book review over at The New Stack when I’m done with it, but this one passage is an excellent representation of what motivates the book pelters and also a good unmasking of why things are the way we they are…because we asked for them to be so:
The US government is based on a system of “checks and balances”—in other words, a system of distrust. The great freedom enjoyed by the press, especially in reporting on the actions of the government, is another indication of the public’s lack of trust in the government. As a result, you find that the government places a high value on transparency. While companies can keep secrets, government is accountable to the public and must disclose its actions and decisions. There is a business need for continued demonstrations of trustworthiness, or we might as well say a business value assigned to demonstrating trustworthiness. You find that the government is always in the public eye—the press is always reporting on government actions, and the public is quick to outrage. Government agencies, therefore, place a business value on “optics”—how something appears to the observant public. In an oversight environment that is quick to assign blame, government is highly risk averse (i.e., it places high business value on things that mitigate risk).
And then summarized as:
…the compliance requirements are not an obstacle, but rather an expression of a deeper business need that the team must still address.
Which is to say: you wanted this, and so I am giving it to you.
The Agile Bureaucracy
The word “bureaucracy” is something like the word “legacy.” You only describe something as legacy software when you don’t like the software. Otherwise, you just call it your software. Similarly, as Schwartz outlines, agile (and all software processes) are insanely bureaucratic, full of rules, norms, and other “governance.” We just happen to like all those rules, so we don’t think of them as bureaucracy. As he writes:
While disavowing rules, the Agile community is actually full of them. This is understandable, because rules are a way of bringing what is considered best practices into everyday processes. What would happen if we made exceptions to our rules—for instance, if we entertained the request: “John wants to head out for a beer now, instead of fixing the problem that he just introduced into the build?” If we applied the rules capriciously or based on our feelings, they would lose some of their effectiveness, right? That is precisely what we mean by sine ira et studio in bureaucracy. Mike Cohn, for example, tells us that “improving technical practices is not optional.”15 The phrase not optional sounds like another way of saying that the rule is to be applied “without anger or bias.” Mary Poppendieck, coauthor of the canonical works on Lean software development, uses curiously similar language in her introduction to Greg Smith and Ahmed Sidky’s book on adopting Agile practices: “The technical practices that Agile brings to the table—short iterations, test-first development, continuous integration—are not optional.” I’ve already mentioned Schwaber and Sutherland’s dictum that “the Development Team isn’t allowed to act on what anyone else [other than the product owner] says.”17 Please don’t hate me for this, Mike, Mary, Ken, and Jeff, but that is the voice of the command-and-control bureaucrat. “Not optional,” “not allowed,” – I don’t know about you, but these phrases make me think of No Parking and Curb Your Dog signs.
These are the kind of thought-trains that only ever evoke “well, of course my intention wasn’t the awful!” from the other side. It’s like with the ITIL and the NRA, gun-nut people: their goal wasn’t to put in place a thought-technology that harmed people, far from it.
Gentled nestled in his wry tone and style (which you can image I love), you can feel some hidden hair pulling about the unintended consequences of Agile confidence and decrees. I mean, the dude is the CIO of a massive government agency, so he be throwing process optimism against brick walls daily and too late into the night.
The cure, as ever, is to not only to be smart and introspective, but to make evolution and change part of your bureaucracy:
Rules become set in stone and can’t change with circumstances. Rigidity discourages innovation. Rules themselves come to seem arbitrary and capricious. Their original purpose gets lost and the rules become goals rather than instruments. Bureaucracies can become demoralizing for their employees.
So, you know, make sure you allow for change. It’s probably good to have some rules and governance around that too.
Unsurprisingly, I liked both of them, esp. the second:
What I find so helpful, and even thrilling, about Gruver’s book, is that it’s exacting in its instructions and walks through several what-if scenarios for addressing common problems that come up when applying agile and DevOps at scale. Plus, it’s the perfect size for a book of this type: about 90 pages that’ll take you about 90 minutes to read.
The premise of this book, for most anyone, is painfully boring: planning out and project managing the installation of COTS software. This is mostly lumbering, on-premises ERP applications: those huge, multi-year installs of software that run the back office and systems of record for organizations. While this market is huge, touches almost every company, and has software that is directly or indirectly touched by almost everyone each day (anytime you buy something or interact with a company)…it’s no iPhone.
If you’re in the business of selling enterprise software and services, however, Beaubouef’s book is a rare look inside the buyer’s mind and their resulting work-streams when they’re dealing with big ol’ enterprise IT. As a software marketer, I read it for exactly that. I was hoping to find some ROI models (a scourge of my research). It doesn’t really cover that at all, which is fine.
There’s a core cycle of ideas and advice flitting in and bout of the book that I like:
- COTS software will do, you know, 80% of what you like. The rest is customizing it through configuration, your own code layered on-top, or getting the vendor to add in new features.
- The more you customize the software, the harder it will be to change. But, the less you customize it, the less it creates differentiation for your business processes.
- Most of the problems and challenges you’ll encounter, though, will be human based.
- Much of these human problems are about managing the requirements process to make sure the software is matching the needs of the business.
- Process-wise, to do this we like to take on a waterfall approach (try to specify everything up front, implement it all, then verify if it works). This results in a lot or risk of waiting for that final verification to see if it works and you were right about matching the COTS implementation to business needs.
- Instead, and iterative approach that focuses on learning and honing the COTS/business match-up seems like a good idea.
- Role-wise, getting someone(s) who have a tops-down view of the business process and enough technical understanding to map that to the COTS project is a really good idea, though hard to put in place.
While the book focuses on on-premises software, the overall thinking could easily apply to any implementation of a large IT-driven, vendor provided system: SaaS would work, and to an extent the kind of infrastructure software we sell at Pivotal. As the points above go over, the core thrust of the book is about managing how you make sure your IT is actually helping the business, not bogging down in its self.
If you’re pretty vague on what you should do in these large IT initiatives, you could do a lot worse than read this book.
…most of the time, prescribing an antidepressant is not about making somebody “better than well” but rather helping to relieve a patient’s acute suffering enough that she can resume a semblance of normal life.
What you get from Technological Revolutions and Financial Capital is an explanation of how new technologies and the resulting changes in society and business (esp. finance) create cyclical 40-60 year boom, bust, and the thriving cycle.
The valuable part isn’t pointing out that there’s a cycle, but rather collecting together the lengthy cause and effect chain of various cycles of time. The account of how financing (that is, how money “seeks” to fund innovation and then “make money from money,” or “rent-seeking” as the kids like to say) is especially interesting. There’s a distinction between “production capital” (money used by companies to create profit by creating/doing some business in goods or services) and “financial capital” (“banks” and investors who seek to “make money from money,” not by producing something) that’s an especially helpful framing to pound into your head. For example, in this later passage, you get a sense of when each type of money “wants” to invest in business:
In the economy, the interrelations between financial and production capital determine the rhythm and the direction of each technological revolution. Financial capital enables the succession of surges. When production capital at the end of a surge becomes conservative, due to having so much investment and experience tired to it, financial capital will break loose and end up either helping the initial big-bang of the next revolution or following it up by backing the new entrepreneurs in spreading it. When financial capital, during the person of installation of a new paradigm, take the economy on a frenzied ride up a paper-wealth bubble, the new modernized production capital will be ready to take over and lead a more orderly growth process, in the “golden age” that sees the full deployment of that revolution.
As with any pattern/model, I have a dangerous urge to fractal down the cycles from 40-60ish year cycles to 10 years or less as a way to model point innovations. It’s probably a bad idea if precision is desired, but as far as describing what otherwise could look like chaos, it might be handy.
All that said, this book is hard as shit to read. I had to start over ¼ through because I’d let too much time elapse between readings.
The last passage is from June 2002, and I’d be eager to see the author’s current WTF analysis on the world economy.
Rounding out the “Bigend Trilogy,” Zero History is up to the standards you’d expect from William Gibson’s “in the present” stories. Reading through it, you can feel the mastery of his own style of that Gibson has: soulless, unsentimental, and over saturated with a sort of frenetic calm. As with most science fiction, the plot is more of a fixture, and characters are almost equally part of the set. The more pleasurable part is the atmosphere created, here, from places like a “private hotel” with ornate-weird interior decoration, fashion-fetishizing, London motorcycle couriers, and even a brief stint in blown-out rural America.
As with the previous books in the series – Pattern Recognition and Spook Country – the plot itself is the mystery of the book: trying to figure out why all these characters are being compelled to hunt down the secret “Gabriel’s Hounds” clothing maker. There’s some frenetic, tacked on action at the end (as usual) that makes for the major look into characters – what will they do when forced to make a “difficult choice” – but all of that is just background imagery for the more comfortable string of scenes Gibson paints in the rapid chapters.
My rating: 3 of 5 stars
Short and new enough to make you interested in reading some “new” fiction, but tedious like a low-budget indie film.
This collection of short stories has its ups and downs, and to read all the blurbs on it, many professionals liked it. Most of the characters are socially inept and haven’t seemed to discover happiness or how to perpetuate it in their short lives. They’re the kind of characters whose last words in a dialog are always “Oh.” And, of course, there’s no quotes around any dialog which gives it that extra bleakness.
Here’s a good example:
By the time I ran into Ed Borger at Trader Joe’s, Lyon was living at my house only half the week. Which is something Ed and I talked about with loaves of bread in our hands. He thouht this was great progress. I said we owed it all to him. He said his bread always got moldy before he could finish the loaf. I said he should freeze the bread to prevent this problem. He said, Won’t that ruin the bread? I said, No if you’re making toast with it. He said, You can toast it frozen? And I said, Yep.
Still, it’s kind of fun and calming to read, if only to see what kind of whacky thing happens next: mostly normal people doing non-mainstream (what’s the PC word for “perverted” or “abnormal”?) sex here and there. Sort of like a muted, calm Maury Povich show but all the guests were over-reflective, under-employed liberal arts types from boring 80’s childhoods who aren’t even funny enough to be like the 40 year old virgin.
My rating: 3 of 5 stars
As with most pattern books, this is one you flip through in an hour and then save it to refer back to. The strength of software management and development pattern books is describing problems that commonly occur, not really telling you how to fix them. Thus, hey tend to be frustrating because you’re left thinking, “how am I going to get this to work in my organization?” There is a certain level of detail in some of these patterns that’s refreshing, but most are just brief outlines of a software management or team-work problem.Still, they’re extremely helpful things to keep in mind which you may be forgetting (“The Empty Chair”) or no longer think applies to you (“Young Pups Old Dogs”), helpful advice if you must do it (“Offshore Follies”), to some that can be reduced to a clever quip, as in “War Room” where DeMarco says, “I’m beginning to think that a project not worth a war room may be a project not worth doing.”There’s solid advice in here, but the 0th pattern is “Be humble: never assume you have this shit figured out.” After that, many of them are extremely good advice.
My rating: 2 of 5 stars
I gave up reading this one because it never seemed to get to a plot. And, you know, it was like a “bad things can happen” book that got a bit repetitive and (given how cynical we all are now-a-days, without even thinking about it) unoriginal. I feel like a schmuck for not reading a book written by a Nobel Prize winner, but those episodes of Mad Men aren’t going to watch themselves.