Effective communication is integral to success in DevOps transformations
Ever since the dawning of mankind, or should I say “humankind,” we, as a species have invented ways to communicate with our fellow men and women and gender-neutral colleagues (and, soon to be included, robots). From grunting and bashing (bashing gets the message across quite effectively, albeit rather limited in scope) to cave paintings, symbol-based languages such as Cuniform and Hieroglyphics to modern complex languages that evolve across cultures.
Fast forward a few thousand years …
With the emergence of IT professionals as a species, we took a step back into the caves (data centers) and reinvented our own grunting and technobabble language to fit our own IT culture. Our cave wall images became PowerPoint slides, and we would “bash” users with SLAs. Symbols became replaced by acronyms: SLA, UPC, CI/CD, XML, and our modern languages became the language of the “framework” (e.g for the purpose of this article, DevOps). IT evolved and became embedded and entwined in every aspect of business and society, and we have been forced out of our caves and are now expected to “communicate” with these other alien cultures. Yet, our business colleagues feel we still cling to our technospeak to confuse them. (Read “Communication between IT and Non-It is a state of crises” – it was written in 2015 but business leaders I speak to still recognize this).
Even within IT we have our own sub-tribe languages, spawned by the frameworks and practices we adopt. The framework becomes the “Word.” Framework fundamentalists and framework dogma rule, as we throw terms at each other “incident,” “problem,” “defect,” “release,” “deployment,” “User … pain in the neck.” Sometimes the framework and language becomes a brick in the invisible wall that divides us into IT silos.
We defend our language as it becomes part of our identity and what binds us together. In fact even the framework name itself takes on a meaning and life of its own. When we say “ITIL,” some interpret this to mean “Bureaucratic set of control processes that stifle innovation.” When we say “DevOps,” some take this to mean “Cowboy developers trying to push lousy code on to us without any controls.” (More on this framework interpretation shortly, as it is central to my rambling).
There seems to be one term that is common to all frameworks, something that binds us together. Finally something we can cling to and ALL understand. It is the word “Yehbut!” Whenever anybody from a different silo tries explaining something we say, “Yehbut” (“Yes, but,” meaning in fact “No, because”). In fact, to speed up the flow of communication (as speed and flow are now catchphrases in the age of Agile and DevOps, we even say “yehbut” before the person has finished speaking, thereby eliminating “waste” (wasteful words).
We in IT do not need to hear everything to know what was going to be said or even the intention, we have our own “artificial intelligence” engine built in—it is called “assumption intellect (AI).” We apply “Assumicide”: assuming that we know what the other meant when communicating to us and assuming the other understood what we said. This is obviously a core IT capability, as we see it consistently applied in just about every team in our latest “Phoenix project” DevOps simulation. It would appear that we don’t listen to understand, we listen to give an answer. Shift left. Give an answer before the question has even been asked.
It is the same with the word “DevOps.” People assume they know what it means and interpret the term in their own way. In our simulations we strongly urge BizDevOps, the importance of the role of the business. This receives criticism from experts; quite rightly from their perception, interpretation and intention, they declare that DevOps always included business, sec, QA and the rest of the stakeholders. However, that original intention has gone through the “assumption intellect” filter and has come out primarily as Dev and Ops when it comes to adoption, with the business somehow plugged in, on and somewhere in the middle—if we are lucky. Which is why we make it BizDevOpsBiz: to make it explicit. Mark Smalley has written a thought-provoking DASA whitepaper around this topic. Gene Kim, at a recent Executive Connections session, also stated that product owners also need to shift their mindset from “features” to “business outcomes.”
There also seems to be a common “taboo word” that binds us all together across frameworks. It is a common agreement to avoid asking or answering the question “Why?”—”Why are we doing this framework?” The framework becomes the “goal” in itself. “We are going to implement DevOps, ITIL or any other framework.” We send the different silos onto framework training to learn the latest “terminology” so we can confuse other teams and departments who don’t follow the training.
It seems that our motto is, “Ours not to reason why, ours but to do and die.” (Alfred Lord Tennyson)
The Importance of Communication in DevOps
Why am I ranting on about communication and words?
Three reasons:
- Communication and collaboration seem to be critical enablers or barriers for DevOps success.
- The word “DevOps” seems to have taken on a meaning and life of its own, which is limiting the potential value.
- Communication issues are very costly (see this article from Forbes).
I recently played a Phoenix Project DevOps business simulation with a group of senior leaders at the start of a DevOps transformation. These were their key takeaways. I decided to try and analyze their discoveries in terms of communication.
- Answer the questions “What’s in it for me?” “What if we don’t?” – make this clear to all to ensure the “Why?” (are we adopting DevOps ways of working) is understood and felt. Remove the current FUD (fear, uncertainty and doubt) caused by the latest reorganization.
- “We noticed in the simulation that poor communication leads to assumptions, assumptions in an environment of FUD are negative, and lead to poor decision making, lack of trust, resistance and lack of buy-in.”
- We recognized the “yeahbut, yeahbut”! People were not seeking to understand and explore before answering. People were not confirming understanding or soliciting feedback and understanding. “We recognize that people listen to give an answer, not listen to understand.”
- Coaching for teams in start-up phase. Not “telling teams what you expect and what to DO,” asking teams questions about “behavior” and “impact” (help them to learn to apply continual learning and improvement, to organize effective stand-ups, to apply active listening). Learning new behaviors and letting go of old ways of communicating and behaving requires practice and feedback.
- Tell teams (including product owner) we support and commit to reserving WIP time for them to learn, create cross-functional teams and improve.
- Applying “consequence” management—verbally recognizing, rewarding and reinforcing “desirable behaviors.” Directly communicating and giving feedback on “undesirable behaviors” and “falling back into old behaviors.”
- Fostering open feedback on “undesirable behaviors,” asking questions about feedback and behaviors. (When nobody says something about it, it is implicitly accepted behavior).
- Foster a culture of active listening, understanding. “Good ideas when not heard or acted upon are ‘waste’, and demotivating when not given recognition or heard.” Not recognizing and giving room to innovative ideas will stifle a culture of experimentation.
- Have teams develop own visual management systems together with coaches, to aid insight into workloads and priorities, communication and decision making—The MT (Management teams) must communicate guidelines around priority (portfolio, strategic goals). The visual management board became the modern cave wall painting, a new language of post-its, tape and swim-lanes.
- Start capturing and understanding WIP, WIP limits and constraints to flow. Start capturing and visualizing team pain points and improvements. This will aid communication, open discussion, decision-making and expectations.
- Foster a culture of “measures to improve” (not measures to punish): measures to show behavior change, measures “DevOps” metrics (releases, time to release, quality of release), agree measures of “value” and “outcomes” with product owners, measure team skills and growth, measure impact of iterative “improvements” (see 8-field model).
- Introduce FUBAR of the month with rewards for most impactful learning and improvement. (Remove fear and blame associated with failing). Talk about failures, impediments, constraints, waste. MT will start with own!
- Revisit VSM (value stream mapping) training and make visible value streams with all stakeholders, Pin these up where they are visible to all, ask people to put “pain point” stickers on VSM (allows all to communicate continual learning and improvement needs, focusing on eliminating waste). This also helps recognize the “information” and “communication” flow through the value stream and foster dialogue.
- Calling “Stop” is a very effective communication tool, if “respected.” Calling “Stop” to discuss and agree to eliminate “waste” and improve “flow” through the value stream.
- Engage and involve end-to-end stakeholders in these simulation sessions to foster a dialogue, to practice effective communication, reduce assumptions, create buy-in and stop the “yeahbut, yeahbut” responses.
Although DevOps success clearly relies up technology for the continuous integration, automated testing and continual delivery, it is underpinned by effective communication and collaboration. Communication is not just about terminology or language: Listening is probably more important than talking. It is also about demonstrated behaviors—walking the talk, leading by example. This is what ultimately creates trust. And trust is the foundation for effective collaboration.