Posted on April 14, 2011 by admin


By Dominica DeGrandis

The first time I heard the “DevOps” term was during a conversation with my boss who told me that “DevOps” was the new name for what our Configuration Management team used to do at Corbis.  Initially, I took this literally - that DevOps was about source code control systems, building & deploying code.  But our team did more than that.  We built out and maintained Dev and Test environments.  We did Production DB restores.  We managed third party dependencies, tools and security access. Searching to learn more about DevOps, I discovered a whole community of IT practitioners engaged in the DevOps movement loosely defined as “bringing Development and Operations together”.

The DevOpsDays conference in Boston was exciting – listening to IT professionals talk about culture as much as they talked about tools!  Finally - a movement asking us to think holistically about IT systems development, deployment and operations.  I could relate to this movement.  Our team did a lot of different things, but we did them by working together with other teams. We worked with Sysadmins to solve environment configuration and domain issues.  We worked with DBAs to improve DB backups.  We worked with Developers to get their local environment up and running (in a crazy complicated system).  We worked with Architects to implement Continuous Integration.  We worked with QA to improve lead times.  Over time, the nature of our work grew broad in scope and so did our kanban board.

What we really did was build trusting working relationships across the whole IT organization.  It was these relationships that helped us resolve many of our previous issues.  The Operations teams began attending our monthly Kanban Ops Review where we presented our good, our bad and our sometimes embarrassing results.  The transparency brought trust.  The vulnerability brought empathy.  Sitting in the same room with all eyes on the results helped put us on the same side.  The unwanted results became the problem to solve rather than blaming each other.

The DevOps movement appears to be striving towards the patterns in Systems Thinking expressed by W. Edwards Deming.  It’s about understanding the system as a whole instead of only looking at the bits and pieces.  It’s about work flowing across functions instead of stagnating in silos.  It’s about respect and trust amongst individuals doing the work instead of management-driven command and control. The DevOps movement seems to be courageously moving toward an IT service version of Systems Thinking – a truly admirable goal.

Good leadership drives out fear by focusing on the system and can contribute to the success of the DevOps movement.  Good leadership combined with a Kanban pull system and trust enables people to do their job with precision and quality resulting in remarkable improvements.