The Agile and DevOps Band-Aids

I just read a great InfoWorld blog post by Neil Mcallister, “DevOps – IT’s latest paper tiger” http://t.co/l3VMXEfU. Neil contends, “no half-baked movement can solve the broad, complex challenge of bridging the gap divide between application development and operations” groups. I liked his post so much that I thought I would refresh a DevOps-based article I wrote when I was at CA Technologies and post it an updated version here on my Romero Consulting blog.

The subject of “divides between groups” is near-and-dear to me. Though my book, “Eliminating ‘Us and Them’ – Making IT and the Business One,”  is primarily focused on the divide between IT and the business, it also focuses on the divide between “siloed” function-centric workgroups. As I contend in my book, the 'us and them' relationships exist at multiple levels in an enterprise and each of those manifestations must be addressed to make IT and the business ‘one.’ That is why so much of my book is devoted to process and process management – the key to breaking down the walls between workgroup silos.

So what does all of this have to do with DevOps? First, let’s take a look at Agile development methodology. I am sure I don’t have to describe Agile software development to you. Almost every enterprise is applying Agile development methodology to a growing number of their software development efforts. There is no arguing that the appropriate application of the Agile development approach greatly enhances enterprise ability to foster change and innovation.

I have always had mixed emotions about the application of Agile development methodology to software development. I was delighted to see customers and developers working as one, but I lamented the treating of the symptoms vs. solving the problem that instigated the need to apply Agile development methodology in the first place. Now we have the onset of DevOps, yet another Band-Aid on the disease of “us and them.”

I don’t expect everyone will be familiar with DevOps. It is moving beyond its infancy into its toddler stage. It is a growing movement that bridges the gap between software development groups and IT operations groups much in the same manner Agile software development can sometimes bridge the gap between customers and software developers. In summary, DevOps is an emerging set of principles, methods and practices for communication, collaboration and integration between software development groups and IT operations groups. It is a response to the acknowledgement of the interdependence and criticality of both the software development and IT operations disciplines in meeting the increasing need for enterprises to drive rapid innovation. In a nutshell, DevOps gets software development and IT operations to work together so they don’t bring the introduction of new software to a crawl - thus losing the momentum of the Agile software development work. Damon Edwards wrote an post that provides a great description of DevOps http://t.co/ScIknZN. 

As with the application of Agile development methodology to software development, DevOps addresses the enterprise culture-based problem of function-centric work. For those of you unfamiliar with the idea of function-centric vs. process-centric work, let me make reference to the late great Dr. Michael Hammer. I had the privilege to meet, learn from, and work with Dr. Hammer when I was the IT Governance and Process Officer at a previous company. I viewed Dr. Hammer as the godfather of process and process management. I believe Dr. Hammer as much as anyone understood the crucial need for enterprises to master this critical discipline.  The following is his comparison of function-centric vs. process-centric organizations:

“Function-centric organizations are staffed by task workers with narrow perspectives and virtually total ignorance of the larger context in which they are working; in parochial organizational identification and affiliation, through which allegiance is given not to customer or company but to function and unit; and in incongruent measurement and reward systems that reinforce limited concerns and perspectives.”

“The focus in a process is not on individual units of work, which by themselves accomplish nothing for a customer, but rather on an entire group of activities that, when effectively brought together, create a result that customer’s value.”

The pervasiveness of function-centric constructs is the chief reason enterprises need to apply Agile development methodology to software development and DevOps to the introduction of that software to the production environment. Few enterprises are process-centric which means few organizations understand and manage work end-to-end. They cobble together disparate groups who toil on their chunk of the work and toss it over the fence to the next group. Agile development methodology and now DevOps addresses this problem by placing Band-Aids on the symptoms. The Agile Band-Aid is intended to fix the problem between customers and developers and now the DevOps Band-Aid is intended to fix the problem between developers and operations.

If you have not placed these Band-Aids on your function-centric enterprise wounds yet, you can expect to very soon. The onset of cloud computing and the screams for IT to drive rapid business innovation will likely make Agile software development and DevOps essential to your success. In the meantime, I will continue to evangelize the IT governance and process discipline necessary to solve the overarching enterprise problem of disparate disconnected function-centric groups. I am okay with the Band-Aids, as long as they are viewed as interim steps to curing the disease of 'us and them.'

~ Steve ~

Comments

[Daniel Bobke]

Great post Steve. One point I disagree with is calling Agile a band-aid for an "us and them" issue. I think Agile came about as a methodology and process for the software development world - not because of a larger issue of the chasm between IT and the business. Much of the thinking within the Agile world come from the same principles in lean manufacturing - minimizing waste, doing things in smaller chunks (iteration), etc. While there are some parallels between the problems in the software development world and the greater relationship between IT and the rest of the business, I don't think Agile is a band-aid. It really addresses the greater issue of customers not truly knowing how to explain and capture what they really want the end product to be and understanding that the end result often changes and shifts along the way.

I do agree that the thinking within Agile and DevOps can be adapted to help address the larger issue of "us and them".

[collaboration solutions]

The blog was absolutely fantastic! Lots of great information