I’m writing this the day after Thanksgiving. Yesterday, I was thankful when Da Bears implausibly beat the Packers. This led to a spiritual reflection on the limitations of the so-called golden rule, namely, that it only applies to like-minded individuals.

I reached this conclusion because of my wife’s family, which hails from within hailing distance of Lambeau Field and didn’t appreciate my enthusiastic response to the game’s outcome. Nor, to be fair, have I always appreciated theirs when faced with the more common result of Bear/Packer encounters.

What’s this have to do with DevOps, the subject we’ve been exploring in this space the last couple of weeks?

Not much. Except that applying DevOps to internal IT has golden-rule-like flaws (okay, it’s a stretch): As has been mentioned in this space from time to time, the similarities between developing commercial software or customer-facing websites and what IT needs to do are quite limited.

The big difference, as if you don’t already know what’s coming: Both waterfall and any of the popular Agile variants — Kanban, Scrum, xTreme, Test-Driven Development, and the strangely acronymed Lean Software Development — are designed to develop software.

And DevOps, in case you aren’t already aware of this, is built on top of one of these Agile variants, most often Scrum.

DevOps is a fine way to create software products, as Microsoft reportedly does. For that matter it’s a fine way for advanced retailers to constantly test new selling approaches on their websites. But … while the number of deploys per day is a frequently touted benefit in articles extolling the virtues of DevOps in retail, what these deploys are for is usually left to the imagination.

Which gets us to the questions raised last week about DevOps inside the enterprise, and an Agile methodology mentioned in this space several times but … and I apologize for this … never fully explained: Conference Room Pilot (CRP).

The question: Can DevOps be based on CRP instead of Scrum, and if so what would the result look like.

But first: What is CRP and why does it matter?

Answer: CRP is the only Agile variant designed from the ground up to implement commercial off-the-shelf software (COTS) and, by extension, Software as a Service (SaaS) solutions as well.

Here’s how it works.

First, IT installs the new COTS package to create the development environment. If the COTS system is supposed to replace one or more existing legacy systems, as is often the case, IT also converts the legacy data — a logically waterfall effort that shouldn’t be made Agile because what would be the point?

Next, whoever is in the best position to do so collects a few hundred or thousand test transactions, in the form of actual business conducted using the legacy systems over the past few weeks or months. These are staged as paper or electronic forms, whichever makes the most sense for use in exercising the new system.

One more preparatory step: IT trains a few developers in the new application — the ones it plans to turn into its gurus, because IT shouldn’t ever implement any COTS package without developing gurus for it — along with a training professional.

Now it’s time to lock the team, composed of business managers and users plus the newly anointed COTS gurus, in a conference room, to pilot the new system (hence the name).

Locked? Metaphorically — bathroom breaks are allowed, and pizza and beverages (caffeinated) are provided on demand.

The business users enter randomly chosen transactions into the new system. They’ll experience one of two outcomes: The new system will either:

  • Handle the transaction cleanly. Result — add it to the system’s automated test suite, for use later on to make sure changes don’t break what’s fixed.
  • Handle the transaction clumsily or not at all. Result — discuss it with one of the gurus, designing enhancements that don’t violate the integrity of the COTS system and do handle the transaction smoothly and efficiently. When the enhancements are finished and satisfactory, the transaction is added to the automated test suite.

Note that neither of the outcomes is “handles the transaction the way it’s currently handled.” There’s no intrinsic value to that, and that this is the case is a critical point, with which all team members are familiarized before being locked in the conference room.

By the time the team has plowed through the complete stack of prepared transaction and the resulting system passes the accumulated automated test suite, it’s ready for deployment.

Now it’s time for the magic question: What would the marriage of CRP and DevOps look like?

* * *

Sadly, we’re out of space, which means you’ll have to wait until next week for the magic answer.

Not that I’m skeptical or nuthin’ …

The number being bandied about, and cited here last week, is that Amazon releases new software to production every 11.6 seconds.

It appears Amazon employs roughly 3,000 web developers, which means it’s arithmetic time. Let’s see: 86,400 seconds per day, 11.6 seconds per release, and that gets us to … carry the one … about 2.5 releases per day per web developer.

Does someone in earshot know enough about the situation to clarify exactly what each programmer is releasing 2.5 of to the wild every day at Amazon? Because never mind DevOps, and for that matter never mind some awfully fast coding. With developers this fast, who comes up with enough ideas to keep them busy, and how?

While the exact number seems suspicious enough to warrant skepticism, let’s give everyone in the DevOps public relations supply chain enough benefit of the doubt to accept that whether the actual number is 7,500, 750, or 75, Amazon releases a lot of new code to production every day.

When the new releases are going to a website or mobile app, as they are with Amazon, nobody has to worry about training or organizational change management. Amazon’s shoppers expect to figure out what they’re supposed to do next based on what they see on their computer or smartphone screens. They’re shopping, not engaged in mission-critical activities.

And what you see on Amazon, while it’s quite a bit more complicated than Google’s legendarily spare user interface, is still quite simple compared to what business users see when looking at a screen from one of the company’s enterprise applications.

Also: While there is, as has been pointed out in this space ad infinitum, not to mention ad nauseum, no such thing as an IT project (they’re all about business change or what’s the point? In case you haven’t been paying attention) when it comes to enhancing the company’s website, or mobile app, or, for that matter, software products like operating systems and office suites, for all intents and purposes the business change is done when the software hits the production servers.

That’s in contrast to any change you’d be likely to make to the company’s ERP, CRM, supply chain systems, or what-have-you. The whole point of changing or enhancing the company’s internal systems is to support a change in how we conduct business around here.

DevOps for internal applications is, that is, qualitatively different from DevOps for customer-facing applications.

Which brings up another thought: When it comes to customer-facing systems, faster is very often better. Even if it isn’t truly “time to market” in the sense of being able to sell “new and improved” before your competitors can, when interacting with Real Paying Customers, novelty has intrinsic value.

But when it comes to employee-facing applications, slip-streaming application changes mostly means confusing employees, disrupting an established business process with no clearly defined process change in view.

Internal releases aren’t just software changes except for those that do nothing but fix bugs or modify algorithms hidden from the view of the employees who see their results.

Internal releases are business change releases. Otherwise they’re just releasable builds — dots to be connected when the actual release is ready for deployment.

Releases that are business changes call for communication, retraining, sometimes changes in the metrics the company uses to gauge its effectiveness, and occasionally something even more extreme, like changes in reporting relationships.

There are situations when changes to business processes can be just as iterative and incremental as Agile makes software changes and enhancements.

But just as often, and especially when regulatory and compliance issues are involved, bundling business changes into controlled releases really is the better choice.

Business change like this isn’t necessarily better for being faster.

DevOps still might have a place here, but its place is more likely to be releasing a continuous stream of small changes to a sandbox environment than true continuous integration and delivery.

There’s little value in IT dramatically outpacing the natural pace of change in one or another part of the business. Unless, that is, the natural pace of business change is slower than it ought to be because everyone expects IT to be the bottleneck, and adjusts their velocity expectations accordingly.

Blowing up those expectations? It can do wonders for a business culture steeped in the perverse pleasures of slow.