M Mooney works in a fairly standard internal application development environment. His group writes code, packages it up, and sends it off the Infrastructure Group for deployment to the QA servers. Like many organizations, M's group has virtually no access to these servers. If they're lucky, they can use the application as an end-user would. If they're really lucky, they can directly access the server log files.

But all this is fairly standard practice. Today's world, terrorists, Sarbanes-Oxley, corporate espionage, malicious employees, super villains, etc -- you know the spiel. What sets M's story apart is the difficulty his group has with the Infrastructure folks. In M's organization, the Infrastructure Group is a part of the Network Operations Division, which in turn is part of the Technology Assets Unit, which in turn is part of the Internal Assets Department. Basically, what that means is that M has a much easier time exercising his "six degrees" to get in touch with Kevin Bacon than he does using the "official chain of communication" to work with the Infrastructure Group.

In addition to the communication gap with the Infrastructure Group, there's also a bit of a skill-set gap. Because that group is comprised only of network engineers, they'll often have a difficult time doing "developmenty" stuff, such as, "add CorporateAccounting to the COM+ Role Store on all MTS Servers." That will often lead to a failed deployment and require M's group to go through several days of begging for temporary access and "blind debugging." So, in an effort to avoid all this, M's group started putting together incredibly detailed, click-by-click instructions. Unfortunately, it didn't help.

After several more failed deployments, M's group came to the conclusion that the Infrastructure Group was simply not reading the instructions. A "stern" email to "follow the instructions in full" was sent up the chain, across the departments, and down the chain. A "stern" reply of "that's what we've been doing" was sent back up the chain, back across the departments, and back down again. Obviously, the "official chain of communication" wasn't going to get them anywhere.

Many failed deployment later, the Director of the Technology Assets Unit sent a "very stern" email to the Director of Application Development, demanding a meeting between their groups to discuss this problem. One of the Network Operations managers was furious and this latest failed deployment was "the final straw"

In their meeting, in front of the Directors and Vice President, the Network Operations manager blasted the Development group, saying how completely unprofessional it was to send a document with nothing but "Wingdings gibberish" instead of installation instructions. He professed that, despite what Development says, the Infrastructure Group always reads and follows every single word of the installation guide, and that the failed deployments were a result of Development's utter incompetence in making useful instructions.

Timidly, one of the Development managers admitted to making the change. The Network Operations manager fired back, demanding to know how he could possibly think that insulting his team like this, amidst all the deployment problems, would be a funny practical joke. "Well," the Development manager replied, "it's funny because we've been releasing our guides like that for the past twelve deployments."

 

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!