The DevOps Culture Cocktail

(also posted on www.devops.com)

As I have written in previous posts, I believe that IT has accumulated decades of cultural debt that is now due.  We are a young  industry that grew up in silo neighborhoods, each with it’s proprietary practices, language and population of like-skilled specialists.  Left unchecked, the resulting “framework culture” contributed to IT’s cultural debt and is partially the motivation behind DevOps.

The goal of DevOps is not to undervalue or replace the frameworks that are in place.  On it’s own, DevOps is not a framework – in fact,  successful DevOps relies on combined effect of best practices such as Agile, Lean and ITSM.   By recognizing and adapting the best of each, IT can formulate a potent recipe for enhancing performance and increasing customer satisfaction.

So let’s belly up to the bar and mix ourselves a DevOps Culture Cocktail by taking the best guidance from the top shelf of each of the frameworks and practices.  

Ingredient 1:  'Git R Done' Scrum

Scrum is the most prominent of the Agile frameworks and with good reason:  it focuses on getting work “done” in manageable increments while reducing work in progress. 

Pair it with a Kanban Board

While deceptively simple, Kanban is a powerful method for visualizing workflow, identifying constraints and keeping a team focused.

Ingredient 2: Automation

There is a lot of debate around the balance of automation use in DevOps, but there is no dispute that automation and metrics play a key role in successful DevOps. 

Ingredient 3: IT Service Management

ITSM is the deployment's "ever after".  Agile and repeatable service management processes lead the way to stable continuous delivery and increased flow.

 Ingredient 4: Lean

Let’s make it a skinny by creating more value for customers with fewer resources and less waste.

Ingredient 5: People

The most important ingredient.   DevOps relies on the way people think, behave, interact and trust their colleagues.   According to Lloyd Taylor,  "You can’t directly change culture. But you can change behavior, and behavior becomes culture.” 

Finally, add a splash of common vocabulary and a shot of the alcohol of your choice and you now have a DevOps Culture Cocktail!  Serve it daily, share it with your neighbors or sip it while reading a good book like The Phoenix Project.   It does get more potent with age.

I recently had the opportunity to present the DevOps Culture Cocktail Party at Fruition Partner’s FruDevCon Conference.  One of the attendees, a hobby mixologist,  formulated her vision for a signature DevOps Culture Cocktail during my presentation.  We asked the hotel bartender to mix it up, passed it around and a new cocktail was born. Here goes:

The DevOps Culture Cocktail
1 part pear vodka
1 part St. Germain
1 part Chardonnay
2 parts simple syrup or 7 up

Top with a spear of pineapple and a cherry.

Improvement recommendations are of course welcome.  Could this become a staple at all future DevOps events?

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.

A Culture of Trust

(also posted on devops.com)

Trust is by far the most critical element of a DevOps culture.  It is also the most difficult to achieve.  IT was not built for trust.  The silo structure that is common in most IT organizations was built for specialization and territorial ownership.  The silo walls are thick.

While DevOps may not be able to break down the silos, but it can encourage and groom a culture of trust.

Trust is difficult to define.  We know when we feel it, we know when we don't.   In 1993, Dr. Duane C. Tway, Jr. published a dissertation called "A Construct of Trust".  In it, Dr. Tway defines trust as

“The state of readiness for unguarded interaction with someone or something.”

Dr. Tway believes that trust is actually "constructed" from three basic elements:

• The capacity for trusting
• The perception of competence
• The perception of intentions

The capacity for trusting is how your total life experiences have developed your current capacity and willingness to risk trusting others.

The perception of competence is your perception of your ability and the ability of others with whom you work to perform competently at whatever is needed in the current situation.

The perception of intentions is your perception that the actions, words, direction, mission and decisions are motivated by mutually-serving rather than self-serving motives.

While trust is individual, a culture of trust is organizational.   Both are earned.  DevOps is a great opportunity to look at Dr. Tway's construct of trust and identify small but meaningful opportunities to steadily increase the trust between Dev and Ops including

• Improved and honest communications
• Increased personal interaction
• Honored commitments
• More listening than talking
• Frequent knowledge sharing
• Welcomed input and feedback
• Admitted mistakes
• Intolerance of blame
• Mutual respect
• A celebration of mutual achievements

What else can you do to create a “state of readiness for unguarded interaction with someone or something” in your organization?  How can you increase a mutual capacity for trusting, perception of competence and perception of intentions?   Perhaps you can start with an honest dialog with and between your Dev and Ops teams.  The answers may be surprising and insightful.

Join me at the DevOps IT Culture Cocktail Party session at Fruition Partners' FruDevCon

I am very flattered to have been asked to present at Fruition Partners’ fruDevCon14 conference in Chicago, IL October  5-9.  In it’s second year, fruDevCon offers the unique perspective of uniting development and process on a ServiceNow platform.   Attendees will not only learn more about “what” and “how” to develop within ServiceNow, they also will get insight into “why” they are doing what they do and how good process contributes to overall business success.   

  

I am particularly excited about this approach since the unity of development and process lies at the heart of the emerging DevOps movement.  DevOps does not rely solely on automating tasks – it is as a much a cultural initiative as it is a technical opportunity. Culture is nurtured from the top down and bottom up.  It starts with changing the way individuals think and behave.  

Culture is actually the focus of my presentation, “The IT Culture Cocktail Party” which will be part of the fruDevCon opening keynote session.  During our time together, we will explore the basics of DevOps and discuss how the integration of service management processes with Agile and Lean concepts can foster a culture of better collaboration and faster deployments between Dev and Ops.  We will also have a little fun mixing up a DevOps Culture Cocktail with best practice ingredients from multiple frameworks.  Since DevOps touches everyone in IT, it is my hope that the message of cultural unity will resonate equally with developers, operators and executives.

If your organization is utilizing a ServiceNow platform, I highly encourage you to attend fruDevCon.    In fact, if you register quickly, there is a 20% discount using promo code ANRBJ3.    I hope to meet you there.

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.