Crossing the DevOps Cultural Divide

Someday, I would like to be a world traveler – to visit other countries, experience other cultures, sample other foods and see other sights.  And while the thought of that journey is very exciting, it is also a little intimidating.   In many places, I won’t speak the language, fully understand the customs or know what to do and when.  

There are similarities between travelling the globe and travelling the road between Dev and Ops.  The potential outcome of the DevOps journey is exciting, but also a little intimidating.  In some cases, we won’t understand the vocabulary, customs or know what to do and when.  Both trips will require us to be open to new learning and new experiences.

Before I embark on a world journey, I must build an appreciation for the unique aspects of each national culture and it’s contributions to the global community.  The DevOps journey is no different - it begins with the recognition of and mutual respect for the unique skills and practices at each stop on the itinerary. It is vital that Dev and Ops are viewed as peers with each function adding its own special value to the provision of IT services. Neither is subordinate or superior to each other.    

To prepare for my world trip, I will need to learn a little about the places I will visit.  To prepare for a DevOps journey, we must also learn a little about the function areas that we will work with.   Each team should strive to understand just enough about each other so as to “talk the talk”, but not necessarily “walk the walk”.  Fluency is not required to navigate the basics.

Understanding is great, but experience is better.    I may read about different countries but until I actually walk the streets, the experience will not be complete.  The same is true for DevOps. It is important for Dev teams and Ops teams to actually cross each other’s border and witness the daily workings of the develop-deploy-release-operate production line.  Engagement can range from passive “shadowing” to active participation.  Consider putting an Ops person on a Scrum Team for a sprint,  ask a developer to work in tandem with an operator for a shift or have developers and operators take calls or observe the service desk in action.     Whether in travel or in DevOps, immersion is the best way to learn to function in a different environment.

Your packing list wouldn’t be complete without some useful technologies.  Automation can be a great travel companion as both an expediter and a universal translator.  In DevOps, automated configuration, testing and deployment can make the transport of software  from Dev to Ops consistent and faster. Similarly, monitoring tools, metrics, reports and dashboards can translate and interpret data that provides a common basis for discussing what’s happening in the environment and why. 

While my world journey will eventually end, the DevOps journey will not.    By crossing the borders into each other’s territories, we will be better equipped to engineer realistic DevOps systems that are lean, with common vocabularies, integrated processes, greater efficiencies and greater success. 

A  DevOps without borders.

Cultural Debt

There has been a lot of talk lately about IT’s accumulation of “technical debt’.  Technical debt describes necessary work from a prior deployment that was deferred in favor of other tasks.   As technical debt grows, the ability to make future changes is hindered because of backlog was not addressed.

I have recently come to recognize that IT suffers from another type of debt – cultural debt.  IT is a young industry that grew rapidly  while facing constant pressure to bring technical innovation to the market. Cultural considerations were deferred  in favor of building and deploying products and services.  IT’s silo culture grew organically out of the need for diversifed sets of specialized experience and expertise.

While cultural debt was accumulating,  IT’s complexities were increasing.  The single platform mainframe vanished in favor of multi-platform servers.   Production applications grew exponentially. The IT supply chain went from a single location department  to a network that spans multiple geographies and organizations. Although IT’s silos were also acknowledged to be  IT’s constraints, converging different processes, frameworks,  vocabularies and customs was not going to be easy.  And so the cultural debt grew.

Like all debts, payment is eventually due.  For IT, the due date is  today. Cultural debt is having a tangible impact on the bottom line by hindering IT’s ability to meet the pace of deployment that the business now requires. Every bottleneck in the workflow between Dev and Ops affects the entire system of supply and demand.  The business has zero tolerance for missed deadlines, poor quality code or fragile applications.   A paradigm shift is required in order to improve IT’s consistency and speed.

The good news is that an increasing number of individuals and organizations are looking to pay down cultural debt by embracing a DevOps approach. Case studies are emerging that demonstrate proof of concept - silos are breaking down and people are talking to each other. Tools are enabling automated tasks and deployments are happening faster with fewer defects.  Dev and Ops are starting to embrace a common set of practices and accountabilities.  Best of all, DevOps is stemming the rate of future technical and cultural debt  - and that’s a win for everyone.

Don't Drink the Kool-Aid!

Have you ever heard someone talk about “drinking the Kool-Aid”?   If you "drink the Kool-Aid", you buy into a new concept, initiative or way of doing things.    In our space, it is often used to describe an individual’s acceptance of new or improved service management processes by drinking the “ITIL Kool-Aid”.

I am not sure how the concept entered into our common vocabulary, but it has terrible origins.   In 1978 in Jonestown, Guyana, over 900 members of a cult drank cyanide-laced Kool-Aid as part of a mass suicide.   Approximately two hundred of the dead were children who were fed the Kool-Aid by their parents.

Still want to drink it?   It’s poison.

If we treat ITIL like an IT cult or religion, we are potentially poisoning the perception of some of our most important and influential stakeholders.  Many application developers already consider ITIL a four-letter-word.  Why?  We need to work towards stakeholder alignment, not alienation. 

ITIL was never intended to be perfect, complete, prescriptive or auditable.   It was intended to provide broad-based guidance that is scalable to any organization or vertical market.   To ensure sustainability, you have to foster an environment that allows individuals to buy-in on their own timeline – some will be early adopters, others will require proof of concept.  Both are OK. 

While your program is maturing, encourage confidence, creativity, dialogue, metrics, analysis and even healthy conflict.  Not blind acceptance and certainly no Kool-Aid.

               

Reflections on Fusion 2011

While the itSMF/HDI Fusion 2011 conference has come and gone, I thought I would share my perceptions on the state of service management in North America.  

There were lots of questions about the updates in ITIL 2011, although I did not find it to be the predominant theme of the week.   Leadership, organizational change management, service catalogs/ portfolios, business relationship management and metrics seemed to generate the most interest and buzz.

For the past seven years, presentations about operational processes such Incident, Change, Problem and Config were center stage.  And while those processes are still critical and addressed, it is gratifying to see a bit of a paradigm shift;to more emphasis on leadership, people and relationships.  Everything else is just theory.

Here are  some of the underpinning messages from Fusion 2011

• Leadership is vital to service management success
• Everyone can be a leader and change agent
• People execute process – not tools or flowcharts
• We work with Human Beings, not Human Doings (Deborah Monroe)
• Attitude, Behavior and Culture (ABC) is the number one success or failure factor (Paul Wilkinson)
• Don’t hinder creativity. If you want to grow your business, grow your people (Erik Wahl)
• Be an opportunity manager, not a crisis manager (Daniel Burrus)
• Good governance is better than good technology (Glenn Leclair)

Ironically, these same messages are at the core of the ITIL 2011 update.  The “new” processes are very people and relationship focused: strategy management, design coordination, transition planning and business relationship management.   The Service Catalog takes on a more prominent role as the “glue”  that holds the service lifecycle and business relationship together.  Metrics are being gathered and analyzed for continual service improvement.   Is this being driven by the challenges of managing services in the Cloud?  I’m not sure, but I like the way the winds are blowing.

Are we there yet?  No.  But as a whole we are definitely moving up the maturity ladder.  Can’t wait to see what happens in 2012.

The Importance of Leadership Skills

I recently led the first launch of our newest workshop, ITSM Leadership Skills.  This course was developed in collaboration with PeopleTek, a well respected and recognized executive coaching provider.

The ITSM Leadership Skills workshop addresses the softer skills that are critical success factors for continual service improvement.  Unfortunately, until now these skills were mostly overlooked in the service management classroom.

Topics covered in this workshop include

• Identifying and leveraging strengths
• Vision, Mission, Goals and Measures
• Planning projects
• Managing change
• Enhancing communication
• Managing conflict

Several of the attendees in our first session commented that they had prior experience with many of these topics.  They were grateful for the opportunity to be reminded of their importance while gaining new perspectives and appraoches for being a great leader.   It's so easy to get lost in the mechanics of designing new processes and services; it's just as easy to overlook the human factor.

PeopleTek promotes the belief that everyone is a leader. I agree.  Their definition of a leader supports that view:  To take people where they have not been and would not go on their own.  

Ask yourself:  Who are you leading today and where are you taking them?