I was working through this week’s blog this morning, and it was laser-focused on a narrow topic. I had examples of why too much of a good thing is bad, how absolutism about methodology is hurting the majority of organizations out there, and how to get past this issue to keep improving what IT does for the organization.
And I was nearly done when I decided that there are far too many areas of IT that suffer from absolutism, so I’d offer general symptoms and steps that work to get out of any of them.
What do I mean by ‘absolutism’? Well, it used to be—and, in a couple of areas, still is—true that people would say, “We are an X shop.” And mean it. If you were a Cisco shop in the 1990s or 2000s, that is all you bought. Competitors were not allowed; nor was consideration of competitors. This applies to methodologies as well as product categories. In fact, today it applies to various methodologies more than products.
And it’s bad for the organization, no matter where it comes from. While with vendors, it streamlines purchasing and offers the (in)famous “single throat to choke”, it also causes inefficiencies in costs (from your perspective, they are a monopoly, and some large vendors gained infamy by trying to take advantage of that fact), and causes people to do things in the least efficient way because that’s what the chosen methodology/solution requires.
Sometimes, we manage to do the dance and avoid “One True Way”—take the move to cloud and continuation to multi-cloud, for example. While cloud vendors do not offer customers much leeway in pricing or priority (we customers are all cattle, not kittens), multi-cloud still offers us the opportunity to use the cheapest or best-suited cloud vendor without much drama.
Many times, we are not so effective at avoiding the idea of a silver bullet. Take Agile. If there was a One True Ring of this decade in IT, I’d want it to be containers, but it would actually be Agile. Most IT departments zealously guard that Agile is the One True Way. Early-stage new product development is astoundingly well suited to Agile, and we needed it—if just for that part. Late-stage product maintenance, where changes are not feature-laden monuments to systems complexity, are also really well-suited to Agile and we should be happy to have it. In between? Large updates that can span data centers—or even continents—with a geographically dispersed workforce and hundreds (or more) of hours of development to get one sub-feature completed? Not really a great fit for Agile, and while many of us have said that for years, here is hoping things are changing. As I’ve said before, as maligned as waterfall was, it did the job for decades and handles large complex projects well. Maybe we need a replacement more in line with the times; one that incorporates what we’ve learned from Agile. I’d love that, actually. But what we don’t need is “We’re an Agile shop.” It is less useful than when it was said about products (at least if you only chose a single product, you got single sourcing and streamlined purchasing. With methodologies, you don’t even get that).
Note: Agile is an example, not the point of the post. Avoid “One True Way” across your organization. Root it out and examine it. Sometimes, a single solution with a single specialized skillset is the perfect answer—at least for now. Far too often, “We are an X shop” is someone’s preference codified into corporate policy.
To get past One True Way, you have to be there showing its weaknesses to management. There is some skill overlap when allowing multiple approaches or products, but if management starts prattling about that, simply point out the number of development and/or CI/CD environments the org is currently supporting. To show the overhead, track hours spent. Staff shortages have been endemic to IT for years. Make certain you know how much time is spent in overhead for the product or process, and try to map that to what could have been achieved with that time. It’s not perfect, but it will be illustrative. And don’t stop. Do your work, but point out every time that One True Way makes the job harder or more expensive.
You are nailing it. Don’t let things like Agile keep you from churning out great apps for the company. I’ve been on teams where the time spent in process overhead was dragging down the ability to deliver quality. Fight that. Keep kicking it, and use the best tools/processes for the job.
