I’ll admit it, this article is a little strange. It is an experiment. But DevOps is all about experimentation, right? This article explores how information and behaviors in fact “flow” through an organization. It is based upon my observations with literally hundreds of DevOps teams. I have used the Three Ways of DevOps to show how and why many organizations struggle with this flow of information and behaviors, and what you can do to identify and prevent behavioral “defects” in your organization.
Simple, Really: Mindsets and Behaviors
IT organizations embarking upon Agile or DevOps ways of working are basically attempting to realize behavior change—simple. Consistent, new “desirable behaviors” that deliver value and reduce risks, wasted effort and costs—simple. This sustainable behavior change demands a change in mindsets and beliefs; it also means unlearning old ways of behaving—not so simple. This requires feedback and correction.
Start with the ‘Why’
Changing mindsets relies on the right messaging. Understanding the “why” and the “purpose” is seen as a critical factor in changing mindsets and ultimately behaviors. The right messaging is not just in terms of words, but also in terms of behaviors, such as people “walking the talk” and “leading by example.”
Desirable behaviors are about people doing the right things. Doing the right thing implies making the right decisions; for example, prioritization of work. To be able to make the right decisions requires having the right information, such as mentioned above—the why. Knowing and understanding the why helps underpin decision-making and prioritization. However, we see many teams that do not fully understand the why behind new ways of working. Somehow the message did not arrive. Somewhere in the flow of information the “why as a justification” ended up as the “why as a question.”
This made me realize that information and behavior flows through an organization. I decided to look at many of the challenges organizations face when adopting new ways of working, by using the Three Ways of DevOps.
The First Way: Flow
The First Way of DevOps is all about the flow from left to right, understanding the flow of work, seeking to increase the flow and never passing a defect downstream.
Understanding the Flow
The messaging I mentioned above flows through the organization traditionally top-down and bottom-up; with the shift to Agile ways of working, this flow is through the end-to-end value stream. This flow is upstream and downstream: Downstream is the flow and hand-offs; upstream is feedback.
I mentioned above that desirable behavior is related to making decisions. If we consider the traditional decision-making authorities in an organization, we have from left to right: strategic, tactical and operational decision-making. This can be seen, for example, as the CIO and business management team (strategic decisions), e.g., product portfolio and key goals; product owners and IT delivery managers (tactical decisions), e.g., product backlog, IT changes; teams and employees (operational decisions), e.g., sprint planning, incident prioritization.
The importance of decision-making was also confirmed in a recent Forbes article, “The Netflix Decision Making Model Is Why They Are So Successful.” Netflix’s desirable behaviors are driven by a set of corporate values. The first value is judgment, which “outlines the company’s decision-making ways and accompanying expected behaviors. Notably, Netflix encourages its employees to ‘make wise decisions despite ambiguity’.”
Every so often, it is decided to embark upon an Agile transformation at a strategic level. This decision is communicated throughout the decision-making levels as an intent—usually the why is vague and left open to interpretation. A set of values or principles are also communicated, such as customer-centric, end-to-end responsibilities and continuous improvement. However, these usually are not translated into desired behaviors. An implied set of behaviors are linked to these values and principles, and can end up being inconsistent with the original intention. This miscommunication of the why and the desired behaviors downstream is a form of a defect—often causing assumptions, driving poor decisions and resulting in undesired behaviors.
For example, as a frustrated senior level manager complains that teams won’t take ownership and frustrated teams protest about lack of empowerment, desired behaviors were not defined and agreed. As a result, they were not displayed, waste occurred, frustration, delays, lack of return-on-value from the effort and behaviors spent.
Another concept of flow is constraints—constraints stopping or slowing down the flow. In terms of behaviors, a constraint could be attitudes and beliefs (not understanding or believing in the new behavior), lack of skills or ability to perform the behavior and allocation of time to learn and experiment or improve behaviors. So, not only must we ensure that we do not pass defects downstream, we also must ensure feedback can identify constraints, impediments and barriers that are stopping the right behaviors from flowing smoothly through the end-to-end stream.
Other types of constraints could be ignorance, indifference, confusion, fear, uncertainty, doubt—or, as Mike Orzen said in a discussion, focus, attention and trust.
So, on one side we have:
- Intent, implied, assumptions and inconsistent behaviors flowing from left to right (cause), meeting….
- Indifference, confusion, fear, uncertainty, doubt, lack of trust etc. (effect)—you get the picture.
- A management solution to this is then to tell people to collaborate, or to tell people they are now empowered—again, without defining the associated behaviors.
“… Application delivery is a set of very human-oriented tasks, a key factor that determines the speed to value is trust,” wrote Carmen DeArdo in his latest book, “A Leader’s guide to Digital Transformation,” co-authored by Jack Maher. “As teams lose trust in the validity of the work as it flows through the lifecycle, a large amount of rework and waste is introduced.” he wrote. Trust is probably one of the biggest enablers or barriers to the smooth flow of behaviors through the system.
The Second Way: Feedback
The Second Way of DevOps talks about shortening and amplifying feedback right to left so that corrections can be made. One form of this is giving feedback when poor information is passed downstream or undesirable behaviors are displayed, enabling us to correct the messaging and the behaviors. Inconsistent messaging, in the form of managers giving conflicting signals or failing to “walk the talk,” are forms of defects. A commonly chosen ABC card (Attitude, Behavior, Culture) in global workshops is, “Don’t do as I do … do as I say.” However, if there is a culture of blame or a lack of safety associated with giving feedback to correct defects in behavior, then feedback isn’t given. Undesirable behaviors and inconsistent messaging goes unchecked.
Failing to stimulate and act on feedback is another form of defect. This means undesirable behaviors continue to occur. All these behavioral defects create cultural and behavioral debt. As this debt accumulates, the ability to deliver value diminishes. In response to this, managers often revert to old management and control styles of behavior (cause), creating more resistance and reducing the willingness to give feedback or experiment (effect). Again, examples of passing defects downstream and creating more barriers and impediments to the flow of desired behaviors.
As suggested in DeArdo’s book, “Feedback should be treated as though it were the most precious of our resources, because it is.”
The Third Way: Experimentation and Learning
The Third Way of DevOps is about continuous experimentation and learning—recognizing that repetition and practice are the prerequisites to mastery.
Agile ways of working are still relatively new. DevOps is still evolving. Old management styles and models are no longer fit for purpose in this new world. Leadership in this new world is also characterized by experimentation. As one CIO stated, “Leaders are expected to walk the talk, but we don’t know what that looks like in this new model.” Leaders often fall back to an S1 leadership style—which is in conflict with the culture associated with Agile ways of working. Poor leadership styles and behaviors, as mentioned above, are also a form of defect—more behavioral debt.
Feedback becomes even more important to validate experimental approaches and to learn and improve. However, the Third Way also stresses the need to allocate time for the improvement of daily work. We sometimes see impediments on team backlogs, but we don’t see behavioral or cultural debt as a backlog item. We don’t see this on the backlog of management teams’ behavioral debt, either. Teams often are frustrated with a lack of time reserved for technical debt, impediments or improvement work—let alone behavioral debt. As Orzen stated, “Even more important than daily work is the improvement of daily work.” Continual learning and improvement should be core skills and behaviors.
As stated in the Third Way, repetition and practice are prerequisites to mastery. There is nothing new about this. It isn’t that the DevOps movement came up with this “new” philosophy: Aristotle, around 300 B.C., stated, “We are what we repeatedly do. Excellence, then, is not an act but a habit.”
We need to practice and repeat behaviors until they become habits, or culture—like “the way we do things here.” Practice also requires feedback to validate improvement gains as a result of practice.
Top athletes practice with the guidance and feedback from coaches. Scrum and Agile coaches are often assigned to Agile and DevOps teams as they practice and grow. These coaches are skilled in training on Agile and DevOps tools, such as standups, retrospectives, value stream mapping, Kanban and Kaizan. But what we see globally is that not all coaches have behavioral management skills.
Another form of feedback from practice is measurement. In terms of DevOps, teams measure metrics such as number of releases—successful releases. We don’t often measure the behavioral change. We can measure the frequency and decisions from standups, but can we measure giving feedback, confronting undesirable behavior? One small example I use is measuring the amount of “yehbuts”—yes, but!—in a dialogue, or worse still, “yehbuts” before somebody has even finished talking. This is an example of a communication defect. Another example is assuming that we understand what somebody has told us without confirming if what we believe we heard was the actual intention.
Communication defects are a major barrier to successful flow of information. Another measurement needs to be related to the impact of behavior change, such as improved customer and employee satisfaction and less rework because of assumptions. Although measuring the actual impact is difficult, having the dialogue itself is valuable: How is what we are doing adding or reducing value to the team and to the organization?
Conclusion
If we want desirable, consistent behaviors focused on creating high-performing teams, we need to look at how messaging and behaviors flow through the system and recognize defects we are passing downstream. Our vague intentions need to be quantified in terms of desirable behaviors. We need to build in feedback mechanisms to signal defects and undesirable behaviors. We need to identify the constraints and impediments that may be causing undesirable behaviors such as fear, uncertainty, doubt—behaviors that may be slowing down or stopping our transformation to new ways of working. We need to recognize that experimentation and practice is needed—knowing that we will struggle and fail, but ensuring we learn and improve as an end-to-end capability. Leadership skills, styles and behaviors need to be aligned to facilitating the three ways of behavior flow. Finally, remember there is really nothing new about this.
Case
In a Phoenix Project simulation, after recognizing the above defects, a team posted the strategic portfolio and goals on the visual management board. The CFO explained these goals and why each backlog item was prioritized against value creation (benefits and value to be realized)—an example of clarity of the why. At the same time, the CFO displayed the right behaviors—being at the standup to explain to the team and ask for direct feedback and understanding.
At the same standup, the CISO and IT team explained the potential “value leakage” backlog items in terms of debts, risks and defects, so that together—business and IT—could make the right decisions on prioritization.
“This made me realize,” said the product owner, “I was now able to make a better-informed decision, because of the team’s input on value leakage—giving feedback from the usage of the applications and the negative impact. It also gave me more trust in the team as they demonstrated an understanding of the ‘why’ and had a clear understanding of value. If, as a team, we did not fully know or understand the value, this created a great dialogue to explore it and ensure we didn’t pass a ‘defect’ (wrong decision on prioritization downstream).”
The team in the simulation learned that as well as visualization of impediments on their backlog, they also needed to visualize the behavioral defects that needed work on and allocated time.
