devopsy.kinsta.cloud

Author: Paul Wilkinson

  • DevOps: Assessing Behavior Flows Through an Organization

    DevOps: Assessing Behavior Flows Through an Organization

    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.

    — Paul Wilkinson

  • Is Your Organization ‘Fit for the Future’?

    Is Your Organization ‘Fit for the Future’?

    Takeaways from a recent conference suggest more work is needed in DevOps adoption among organizations

    This was a question explored by CIO Platform Nederland and the DevOps Agile Skills Association (DASA) in a recent event I attended, hosted by Transavia. Many organizations have already embarked or are about to embark upon Agile transformation initiatives, driven by growing business demands. This event focused on sharing experiences, learning from the practical examples (successes and lessons learned) from Transavia and ABN AMRO, and exploring the way forward to successfully create a high-performing IT culture that is “Fit for the Future.”

    The event was well-attended—unsurprising, really, when you remember the wise words from the late Robert Stroud, former Analyst at Forrester: “To unlock the promise of DevOps, CIOs must lead and support a cultural change within their technology management organization, but as any leader knows, changing institutionalized behavior is the toughest of all management challenges. CIOs must recognize when a trend becomes an imperative for survival. DevOps has become this imperative.”

    DevOps and Agile transformations being seen as imperative for business survival. But not just business survival, according to the “2017 State of DevOps” report, which declared, “By 2020, half of the CIOs who have not transformed their teams’ capabilities will be displaced from their organizations’ digital leadership teams.”

    Rik Farenhorst, CIO of Transavia and chairman of the DASA Leadership Forum, presented lessons learned from Transavia. He stressed the importance of changing mindsets and giving equal, if not more attention, to creating desired “behavior” change and not relying too heavily on structure, processes and automation and hoping that the right culture emerges. “People first,” “live your values” and “lead by example” were his key messages, stressing that values must be translated into corresponding desired behaviors as well as unlearning old ways of doing things. Another important discovery was accepting that not all teams are so far and not all teams can mature at the same speed.

    A great example of “lead by example” was the leadership team’s daily standups and visualization of strategic priorities, gaining more situational awareness and shared understanding and commitment.

    Matthijs Dee and Ivo Carton from ABN AMRO presented their journey from Agile to DevOps, also pointing out the fact that teams mature at different speeds and the need to share lessons learned between teams. ABN AMRO adopted a DevOps playbook that teams could use, containing a kind of toolkit for improving team capabilities. Equally, Dee and Carton noted ABN AMRO’s challenges in moving from “command and control” and traditional hierarchic management models to new leadership styles and behaviors. In ABN AMRO’s case, the organization needed to focus on BizDevOps—it’s not all about code, it’s about delivering business value.

    Farenhorst mentioned “values” in his presentation, while Dee and Carton mentioned “principles.” Both of these concepts need translating into team behaviors and leadership behaviors must help empower teams to make this shift.

    My presentation, “DevOps Will Fail … Unless,” I revealed the findings culled from more than 400 global teams having participated in the Phoenix Project DevOps simulation and gave a Top Three set of takeaways.

    The first was the need to focus on BizDevOps—making the shift from “features” to “outcomes” and from a flow of “code-to-commit to a flow of “idea-to-value.” This was also one of the top challenges for organizations at the most recent DevOps Enterprise Summit.

    My second tip mirrored advice from Transavia and ABN AMRO: The need to define, agree and commit to “desired behaviors” and what is effective collaboration (here is an example of what I mean).

    My third tip was embedding continual learning and improvement as core behaviors. DevOps is new and all about experimenting—it is a long journey and needs to be done as iterative improvements. At the same time, the pace of change coming at us is increasing, as is the amount of change. Teams need to be able to respond to change. I also quoted Mike Orzen, author of “Lean IT”: “Improving your work is just as important as doing your work”; as such, impediments and improvements should also be made visible on the backlog of work for teams and leaders must ensure adequate time is given and reserved for work-in-progress, for teams to improve.

    Following the presentations were three break-out sessions: “Value Creation and Management,” “Organizational Design – Agile/DevOps at Scale,” and “Sustainable Culture Change.”

    These are some of the challenges raised in the Culture break-out session I attended as a follow-up to my presentation:

    • An interesting discussion was around “control” and how to empower the management layers and have them empower the teams. As a CIO, this layer between you and the work floor can diffuse your vision by the time it reaches the shop floor and at the same time leave you unaware of what is happening.
    • Management by walking around was suggested, as a CIO being visible on the shop floor and soliciting feedback. Listen to concerns and enter into a dialogue about vision, goals and what it means.
    • Teams often are faced with fear, uncertainty and doubt (FUD) about new ways of working. What will it mean to their job? To their responsibilities? And will they be able to do it? Leaders must remove the FUD and create a safe environment. Safe to take risk, to experiment, to fail, to give feedback. Managers must foster a “no blame” culture.
    • A study by Google (2012) called Project Aristotle, named in tribute to Aristotle’s quote, “The whole is greater than the sum of its parts,” looked into why some teams work and others don’t. One of the key conclusions was that “psychological safety” was the “it” factor: A sense of confidence that the team will not embarrass, reject or punish someone for speaking up.
    • Change team behaviors. We adopt these approaches and don’t see the behaviors we expect. Not everybody wants to change. Leaders need to be able to identify the silent killers, what is under the water, what are drivers for working against. At the same time, teams need to be willing and able to work effectively as a team and need team training (not just individual training). Team training also needs to address soft skills such as communication, feedback and collaboration.
    • Leaders also need new skills in organizational behavior management to be able to identify behavior drivers and how to create sustainable behavior change.
    • Lead by example was named, but what is that? What behaviors are expected from leaders? Sometimes managers are only one step ahead in this new working. DevOps is new, there is no fixed framework; it is about experimenting what is right for your organization. This is all new.
    • Ask yourself, “Why are we doing Agile, DevOps, Lean? Are we adopting these approaches as a goal in themselves? Or are they to solve a specific set of problems or deliver a specific set of results? And how does this relate to strategic goals?” This must then be translated into, “What is in it for ME?” for the various stakeholders (business, IT management, teams, customers). Success can only be achieved end to end, which means all end-to-end stakeholders must understand the “why” if they are to commit to the journey.
    • Build empathy and trust and asking questions to get open feedback—not telling (command and control).
    • Authenticity: To build trust, be empathetic to FUD; listen to concerns; demonstrate (words and deeds) how these will be taken seriously; and recognize achievements. Empathy must be authentic; if your behaviors are not seen as real, you will lose the trust you are trying to create.
    • Shift from a (real or perceived) “blame culture.” Failure is OK as long as we learn and improve as a result. If there is no trust, then people fear consequences of making mistakes and are less willing or likely to want to experiment or speak up.
    • Leaders should show vulnerability, too. Set an example of having failed and learned. Admit in these turbulent times when new ways of working really are new, managers don’t have all the answers—it is a journey of experimenting, learning and improving and giving feedback.
    • Allow teams time to learn and discover themselves. Recognize that not all teams mature at the same speed, appropriate leadership styles and coaching for teams. Use external (to the team) coaches.
    • Be prepared for the difficult discussions and decisions. Not everybody can and not everybody wants to change. If you are dependent upon heroes, get rid of them—literally or metaphorically. One example noted was a toxic working culture with teams held to ransom by the hero, while another example was having the hero share knowledge, coach and create more T-shaped capabilities.
    • Look for “change champions” in teams—peer level respect. Empower them with the right skills and recognize their contributions and the team successes. “Give a podium” to success from desired behaviors such as experimenting, learning and improving.

    From the discussions it was clear that C-level managers need to learn new skills and demonstrate new behaviors, while management layers must learn more behavioral and organizational change skills. Teams must not only learn DevOps technical skills, but also team-building and soft skills.

    CIO Platform Nederland and DASA will be organizing future events and sharing content and experiences from member organizations to address these needs as a follow up to this kick-off event.

    — Paul Wilkinson

  • DevOps and Collaboration: Fraternizing with the Enemy?

    DevOps and Collaboration: Fraternizing with the Enemy?

    DevOps is all about collaboration, we hear.
    “You must collaborate,” say managers initiating DevOps adoption programs.
    HR make new posters declaring the corporate values “We value Collaboration & Teamwork.”
    Can’t fail!
    Then when it appears not to be as effective as we had hoped we tell teams they are “Empowered” to collaborate.
    Blank stares!
    When things still don’t appear to be working we tell teams they are “self-steering,” “self-organizing, collaborative teams”….
    Still, we don’t get what we were hoping for.
    Luckily the tool vendors come to the rescue and tell us why it is failing. We need “collaboration tools and software” – Throw some “Slack” at it.
    Can’t fail!

    This is when we usually get frustrated managers knocking on our door asking about the Phoenix Project DevOps simulation. They are moaning about communication and collaboration! When we talk to the teams they are frustrated and moaning about “empowerment” and managers not “walking the talk.”

    In my mind these lack of collaboration skills is not really surprising. Why?

    Impression: Well, it doesn’t help when the word has also historically been connected to global conflict situations. “He faces charges of collaboration,” “fraternizing with the enemy.” Dev & Ops. Traditional adversaries?

    Interpretation: The interpretation of the word itself is also part of the problem. I googled an English Language Help Desk:

    Collaboration: “To work together with somebody in order to achieve a single shared goal.”
    Cooperation: “Work with other people by achieving one”s own goals as part of a common goal.”

    In an HBR article titled, “There’s a difference between cooperation and collaboration,” it was argued  “… Managers mistake cooperativeness for being collaborative,” adding, “… most managers are cooperative, friendly, willing to share information – but lack the ability and flexibility to align their goals and resources with others in real time.” If managers don’t get it then what chance do the teams have when told – “You must collaborate”!

    Induction: Part of our failure to be able to effectively collaborate could come from our schooling. We are chastised at school for asking others for help, for looking to see how somebody else is doing it—”That is cheating”—things are changing with more “collaborative assignments.” Yet, my children (now in their early 20s) were not taught what effective collaboration is, other than discovering for themselves. As my daughter explained about her school assignment, “You have to do it yourself if you want it done because others will slink off and not do it, then my individual grade may suffer.” They are told they need to collaborate but individual performance grades are scored. My daughter once came home stressed and almost in tears, declaring “Oh no! I have been given another collaborative assignment for my most important subject!” Children leave schools distrustful of collaborating.

    Indoctrination and Imperative: There is also the historical perspective. When we, the current workforce entered our chosen profession we had decades of functional silos that created a “them” and “us” attitude. This stimulates a sort of “territorial imperative” or “tribalism,” not helped by our own “technology” languages and tribal cultures. We have learned over time that other teams “dump things on us” or other teams “stop us from getting stuff done.” In other words, Other teams frustrate work.  (Territorial imperative—”the drive in animals and man to take, hold and defend a particular area, zone, turf,” —e.g. defending their best practice framework! And attacking others that come near!).

    Inconsistency: We then built walls between these teams and if they wanted something from each other they needed to escalate it to their manager. Managers would collaborate or not, especially when they were given conflicting, inconsistent goals and KPIs. Development teams are given goals to release as fast and as often as possible. Operations are given goals to make sure everything is as reliable as possible and available at all times.

    I had an example of this “them and us attitude,” once with a board of directors. I split them into two teams and gave each team a pack of ABC cards (Attitude, Behavior and Culture) and within 10 seconds heard, “Oh good, our team will win this!” automatically creating an atmosphere of competition and winning and losing, I hadn’t even explained the task yet! Teams compete.

    ‘It’ factor: A study by Google (2012) called Project Aristotle, named in tribute to Aristotle’s quote, “The whole is greater than the sum of its parts,” looked into why some teams work and others don’t. One of the key conclusions was that “psychological safety” was the “it” factor, “… a sense of confidence that the team will not embarrass, reject or punish someone for speaking up.” Because we have not learned to collaborate and because we have a “them and us” history often accompanied by blame, there is fear, uncertainty and doubt (FUD) about speaking up, sharing ideas or giving feedback.

    In the dark: However, there is another significant reason for poor collaboration, as I have discovered from running hundreds of Phoenix Project simulations with teams globally. It is the fact that nobody has defined the “behaviors” that demonstrate effective collaboration. We assume everybody knows what we mean when we say, “You must collaborate.” Fact: We don’t!

    Below are the results of a series of recent Phoenix Project simulations. One of the goals was to learn DevOps practices such as CALMS and the Three Ways, while another goal was to learn effective team-working and collaboration.

    I asked the teams at the start of the sessions, “What is effective collaboration? What behaviors will I see today that demonstrate this”?  The teams came up with a list of behaviors (each team came up with a top five or six behaviors; this is the consolidated list from seven teams).

    • Transparent communication – “open and honest” and “frequent.”
    • Calm and constructive dialogue (no blame, accusations and shouting).
    • Feedback “asking for and giving feedback.” Constructive feedback.
    • Shared team goals (and cross team). What are we aiming for? Impact on others and their goals. Maybe conflicts that need managing.
    • Listen – is it clear and understood? Show that you listen.
    • Being open for dialogue, being approachable –not closing the door or hiding behind.
    • Giving and taking responsibility.
    • Sticking to agreements.
    • Central moment to get together (e-2-e).
    • Knowing the roles and responsibilities, sticking to responsibilities.
    • Mistakes are OK.
    • Be proactive to get information needed.
    • Equal treatment: “Respect” ideas from ALL
    • Don’t HOPE, confirm.
    • “Willingness.” Confirm and agree.
    • Ownership of responsibilities.
    • Clear agenda and purpose of meetings.
    • Pleasure – celebrating success.

    “Are these behaviors you want to see more of in your daily work?” I asked.

    Yes! Was the answer.

    “Do we now all commit to sticking to these behaviors today, in this simulation?

    Yes! Was the answer. Easy! See there’s nothing to this collaboration stuff.

    However …

    During the simulation it soon became evident that roles and responsibilities were not clear or not being carried out; it was not agreed which information was needed by the business nor when; goals were unclear, meaning that priorities were arbitrary; people did not understand procedures and did not ask for help; assumptions were made (“I told you …,” “I thought you meant …”); people taking responsibility were not respected (“Let’s stop and try and sort this out …”)— everybody just carried on running around! “Headless chickens,” said one delegate; people were not listening to each other; there was a lot of “assumicide”; mistakes were made and people blamed—there was no exploration as to why and what can be done to stop these  mistakes. Mistakes were often corrected by somebody else but without giving any feedback to correct future mistakes; agreements were unclear across the team; there was no end-to-end flow—work and information was ping-ponging back and forward.

    “All in all, just like reality!” declared the teams.

    See how easy collaboration is. Within one hour of making a list of desirable behaviors, they were totally, utterly and universally ignored. Nobody appeared to own these behaviors or to confront each other on them.

    After the Experiences in Simulation

    At the end of the simulation round we looked at the team scores (number of releases, number of successful releases, business value realized). It wasn’t a pretty sight. The CEO wasn’t happy. The team felt stressed, unhappy, frustrated and powerless.

    We explored what this had to do with “effective collaboration.” Had anybody used the list of behaviors? No.
    Had anybody consciously practiced these behaviors?
    No.
    Did anybody give feedback on these behaviors when they were clearly not done?
    No.
    “Giving feedback feels strange, it feels like we are criticizing and blaming,” said one delegate. Another assumption!

    “It’s hard,” said one delegate. “The manager needs to manage this,” said another.
    “It was YOUR list and YOU all agreed this, why is this a manager’s job to get you to do what you said you wanted to do?”
    There was silence. “It’s not easy, we fall back into old ways of doing things, we need help!”

    Is it a Bird, Is it a Plane, Is it a Bus? No, it’s a coach!

    As the simulation progressed, the team refined their list of desirable behaviors based upon their experiences. They were coached for two rounds and consciously practiced and experimented with the behaviors. The coach role became a critical catalyst.

    In the final round the team owned, and were executing on these behaviors without coaching.
    Why were they suddenly executing?
    They felt less stressed; they were trusting each other; they felt the positive impact on their work; they saw, felt and shared the value gained by these behaviors. They felt immediate positive consequences from these behaviors.
    Why no more coaching?
    The team were taking it in turns to lead their own stand-ups; they were giving feedback and correcting their own behaviors. These were the additions the teams made to the behaviors as they practiced them.

    • Transparent communication – “open and honest” and “frequent” (Relevant, and timely as agreed with the various stakeholders).
    • Feedback “asking for and giving feedback.” Constructive feedback. (Related to agreed behaviors and responsibilities, calling stop, then swarming to solve an impediment, constraint, or remove waste; immediate fact based feedback).
    • Shared team goals (and cross team). What are we aiming for? Impact on others and their goals. Maybe conflicts that need managing. Understanding strategic portfolio and how we contribute to strategy, show you understand and agree common goals and prioritize accordingly. Goals for both value creation (features and benefits) and value leakage (risks, debt).
    • Leadership within team – team members took turns in facilitating the stand-up and retrospective. This role was respected.
    • Listen – is it clear and understood? Show that you listen, sender: Ask for clarification, ask to confirm understanding, listener: summarize what was understood and agreed. Avoid assumptions.
    • Being open for dialogue, being approachable—not closing the door or hiding behind. All were engaged and equal in the stand-up and retrospective. All were asked for feedback, ideas, suggestions.
    • Giving and taking responsibility. Respecting team behaviors; e.g if somebody calls “stop,” or “respect somebody taking responsibility for an improvement stand-up.”
    • Sticking to agreements. Confront people to understand why agreement not met and what can be done about it in the future (e.g conflicting priorities, lack of understanding).
    • Central moment to get together (e-2-e). Scheduled stand-ups, retrospectives, and improvement prioritization.
    • Knowing the roles and responsibilities, sticking to responsibilities, confirming your responsibilities, confronting people on responsibilities (feedback). Showing that you take ownership.
    • Mistakes are OK – no blame, so long as it is used as an opportunity to learn and improve.
    • Be proactive to get information needed (or ensure information is available, e.g. visible management board, avoid unnecessary “disruptions).
    • Equal treatment: “Respect” ideas from ALL. Ask people for input, engage ALL in ideas generation and decision-making.
    • Don’t HOPE, confirm.
    • “Willingness.” Confirm and agree – “Willingness” and “ability,” empower to be able. Share knowledge, cross train, coach, help.
    • Ownership of responsibilities. Confronting people on responsibilities.
    • Clear agenda and purpose of meetings. My role, what is expected from me? What is in it for me? avoid “wasting” time in meetings.
    • Team coaching to give feedback on behaviors.
    • Create trust by demonstrating team behaviors.
    • Check understanding and commitment to “agreements” and confront people (feedback) on agreements.
    • Improving own work as a team.
    • Asking for and offering help.
    • Having insight, overview, visibility.
    • Limit WIP (reserve WIP for learning, improving, technical debt).
    • Pleasure – celebrating success. Product owner shared results including customer feedback. Team complemented each other.

    The teams were then asked to make a list of behaviors and actions they wanted to take away and apply. Their line managers and assigned team coaches were there when the list was made and gave commitment to help guide, coach and empower teams to experiment and practice these new behaviors in their daily work.

    The team would prioritize one or two behaviors to start with and consistently practice in the coming weeks. When the new behavior becomes the accepted norm and a “habit” they would focus on more behaviors.  This fits in with the Third Way of DevOps: Continuous experimentation and learning. “Understanding that repetition and practice is the prerequisite to mastery.” And to tie this back to Aristotle the philosopher (not the Google project): “Excellence is an art won by training and habituation … We are what we repeatedly do. Excellence, then, is not an act but a habit.”

    Meetings, Including Training Sessions!

    And finally, one of our industry’s most popular, and wasteful, examples of collaboration are poorly run meetings, which are the biggest time-sink in organizations and a source of frustration. I include some training classes as forms of meetings.

    In more than 100 training sessions in the last year, less than 10 percent have started on time.
    Nine minutes late is the average. Delegates say this is normal in their organizations. When I ask people what their own personal learning goals are for sitting eight hours in this “training meeting,” more than 25 percent had not defined this and more than 70 percent had not agreed this with the “sponsor” of the training.

    We need to manage our overload of wasted meeting effort. How? One way is the ask for goal and agenda in advance, asking what value you need to bring in and what value you need to get from the meeting; also to limit your time to the agenda items relevant for you or your team.

    Efficient collaborators decide when they do, or don’t, have unique value to add—“maintaining focus on what matters.”

    The same applies to training, asking, “Why am I going on the training?” “What am I expected to learn?” “What problem is this training expected to help solve?”  “What will I be expected to do differently after the training?” “How will the learning be transferred back to the workplace?” “Will I be mentored and coached?” “Will I be given opportunities to experiment?” “Will I get constructive feedback?” “How can we demonstrate that the new knowledge delivers expected benefits?” This is better than the most common answer, “I don’t know I was told to come to this training!”

    A training is also a form of collaboration between you, the trainer and the person sponsoring the training.

    There is an “I” in Team, after all. “I” am responsible for my effective contribution to team performance.

    — Paul Wilkinson

  • DOES18: Challenges and Enablers for DevOps Success

    DOES18: Challenges and Enablers for DevOps Success

    “What happens in Vegas, doesn”t stay in Vegas” … a great quote to end the recent DevOps Enterprise Summit 2018 (DOES18) in Las Vegas, urging attendees to take and share the new insights and knowledge gained. This article is an attempt at sharing my discoveries.

    This article contains a summary of the challenges that delegates told me about when visiting the GamingWorks stand at the summit. These closely match our global findings, with more than 400 teams having participated in the Phoenix Project business simulation workshop.

    This article also describes highlights from the sessions I had time to attend—highlights mostly in relation to the challenges mentioned above, and biased toward toward people, culture and behavior, as this to me is the No. 1 success or fail factor for the successful adoption of DevOps ways of working.

    Challenges

    I asked more than 100 people, “What is your top challenge or barrier for your adoption of DevOps ways of working?” I have ordered them based upon the number of times mentioned, highest first. Many of these I captured before the opening of the summit:

    Leadership:

    • Leaders applying the “pointy-fingered” approach. “You are now self-empowered. Make IT happen.‘
    • Lack of “empowerment” and not “walking-the-talk” to foster the right culture.
    • Not wanting to let go of a “command and control” management approach and fear of becoming less relevant.

    Product Management:

    • The need to shift from a “feature” focus to more “outcome” and “business value” focus.
    • Product owners “demand” but don”t share why.
    • Low focus on “technical debt” and “issues” versus “benefits.”
    • Need higher-level product management (business decision makers) to balance “innovation” with “risks” (e.g technical debt).

    Value Stream:

    • Poor end-to-end visibility (including business “before” and “after” activities).
    • A narrow focus on Dev and Ops, mostly a Dev “pipeline.”
    • No impediment backlog visible for the stream.
    • Too much local optimization.

    Value and Metrics:

    • Too much focus on internal, proxy metrics.
    • Need more “value” and “outcome” metrics to gain buy-in to scale up.

    End-to-End Communication and Team Collaboration:

    • “Them” and “Us” – lack of trust.
    • Poor listening and communication skills to explore and understand.
    • Lack of end-to-end understanding of the business impact and value we are all working toward.

    Poor Management of WIP:

    • Poor balance between types of work, feature vs technical debt, improvements, training and knowledge-sharing.
    • Engineer disconnect between “what you are working on and the business impact.”

    Continual Learning and Improvement:

    • Not enough WIP reserved.
    • Poor team ownership and ability to structure this.
    • No visible backlog of impediments/improvement.
    • No prioritization of improvements.

    Project to Product:

    • Projects claiming resources.
    • Product owner resource conflicts and challenges.
    • Flip-flopping, context switching work.

    Buy-in and Resistance:

    • Why should we change?
    • Fear, uncertainty, doubt.
    • Suspicion of intentions.
    • Managers not wanting to change and lose “power.”

    Certainly not a lot of CI/CD or technology stuff mentioned here!

    What were some of my highlights as they relate to these challenges?

    DOES18: Introduction and Opening

    In his introduction, Gene Kim revealed one of the goals of the summit was a need to “Elevate focus on spanning business/technology divide,” which clearly relates to a high-scoring challenge. Another topic in the intro was the need to “upskill,” announcing a new skills research project to be launched. The challenges above and the highlights from the sessions give a clear indication of some of the skills needed. Considering the challenges above, I sincerely hope the survey also focuses on business skills as well. In the “Lean Coffee” roundtable sessions, one of the announced topics was “Transformational Leadership,” clearly linking to the top scoring challenges mentioned. More about this topic in my closing.

    DOES18 Sessions

    In a session titled, “Product Management Meets DevOps” a key recommendation was to “build and run teams combined with service ownership,” stressing a need “to connect people to your strategy” and declaring “IT cannot be separate from the business,” and finishing with a need to “manage product value streams, not projects.”  (This was the only session in which I heard the word “service”). To me, these highlights clearly make a link back to the challenge teams have in understanding business impact and value. These recommendations will require a changing role for product management to ensure strategic priorities are embedded in the value stream, and a more engaged role of product owners in teams to ensure a shared understanding and focus on “outcomes” and “value” in relation to strategy, rather than on features.

    Benefit: Enabling the flow of strategic intent

    Mark Schwartz explained that almost all large enterprises are faced with “impediments” that are a barrier to DevOps success, and these are usually people and organizational issues, not technology. He introduced his new “War and Peace and IT” book, and explained an impediment faced by Napoleon in his Russian campaign—Napoleon had “long decision cycles.” By the time he got the right information to make a strategic decision, the fast-changing short decision cycles at the battlefield meant his decision-making was ineffective. The same applies to the way we currently manage IT: long decision-making cycles from idea to business case to program and project resourcing while DevOps teams operate at a fast, agile pace. Mark suggested a need to speed up the “entire lead time from idea to impact” (a topic also explored in Mark Smalley’s latest DASA whitepaper, “The Business Value of DevOps“).

    Benefit: Enabling the faster flow of strategic intent

    Schwartz went on to suggest three ways to build more agility into the end-to-end value stream and delegate decision-making to a lower level: the “product model,” decentralizing decision to the product team; the “budget model,” decentralizing budget to the team to manage both “innovation” and “keeping the lights on”; and the “objective model,” just give the team the key objectives to be achieved and let them decide how to make it happen anyway they can.

    This to me represents a considerable mindset shift from the hierarchical “command and control” management paradigm and requires transformational leadership. In my mind, whatever model is chosen needs to fit with the highlight from the previous session, “Connect people to your strategy.”

    Benefit: Enabling faster decision-making around strategic intent

    Anders Wallgren‘s session, “Measuring DevOps – The Key Metrics That Matter” was standing room only, with a packed audience taking pictures of all of the slides. I must admit to being surprised, as this is the fifth DOES conference and organizations have had five years to put metrics in place! I can only assume the vast majority were just starting their journey. I was pleased to see not just the traditional metrics often quoted such as “deployment frequency,” “lead time to change,” “mean time to recover (MTTR),” and “change failure rate,” but also business value metrics such as revenue growth; customer value metrics such as customer experience satisfaction; team culture metrics such as education and growth; and the pipeline metrics such as release velocity. This was one of the top-scoring challenges facing delegates who visited our table: “Fhifting from internal metrics to business value metrics.” This focus on business value metrics ties in again to the highlight from the first session above, “Connect people to the strategy,” and the important role product owners have in sharing the strategic intent.

    Benefit: Enabling measurement of strategic intent.

    Dr. Mik Kersten presented “Project to Product: How Value Steam Networks will transform IT and the Business,” suggesting that project management and traditional cost models are the wrong models, an idea supporting Mark Schwartz’s observations. He went on to add, “Fragmented value streams kill personal productivity,” as well as “impact employee satisfaction.” Silos and proxy metrics not related to business value will also destroy a DevOps transformation. He made some powerful arguments for a complete end-to-end value stream (Not just a DevOps value stream).

    These messages were further endorsed by Carmen De Ardo in his session, “Connecting IT to the Business at BMW Group,” during which he also stressed, “Flow time is not just code-to-commit but also, and more importantly, idea-to-value.” Carmen also stressed that the “flow to value” is not just the flow of “features” but also “defects,” “risks” and “debts,” which to me represents a need to manage “value optimization,” a balance of “value creation” and a reduction of “value leakage.”

    Benefit: Enabling value optimization of strategic intent.

    Damon Edwards, in his session “Operations: The Last Mile,” expanded on the theme of end-to-end value streams, with a powerful case about disruption, context switching, waiting, escalations, lack of trust and employee dissatisfaction—all this because of “four forces that undermine operations” that need to be addressed to empower operations:

    • Reduction of Toil—non-valued repetitive work that can be automated.
    • Queues, which disintegrate and obfuscate value streams.
    • Silos, causing disconnects and mismatches.
    • Low trust—the need for “psychological safety, the No. 1 predicate for success.”

    Benefit: Enabling the removal of behavioral flow barriers and waste.  

    Dominca Degrandis in her session, “Making Connections Visible: How to Defrag Your Value Stream,” stressed, “The hardest thing we do is communicate across teams,” making a call to make connections visible as well as “how the different types of work enters the system, where they enter and which tools are used.” This touched on a topic I discussed with DeArdo at itSMF Fusion: the information value stream.

    Benefit: Enabling the removal of end-to-end information and behavioral flow barriers and waste.

    One of the most powerful sessions for me was the presentation from Dr. Steve Spear: “Discovering Your Way to Greatness: How Finding and Fixing Faults is the Path to Perfection.” He suggested, “Design all work to SEE problems.” Make this part of a philosophy: “See, Solve, Spread (Share knowledge).” He suggested, don’t ask “How is it going?” Ask, “What is not working, and what can we do about it?” This ties in nicely with a finding from the latest State Of DevOps report: “Relentless improvement work leads to excellence and high performance.”

    Benefit: Enabling the relentless removal of barriers and waste and the optimization of strategic intent.

    DOES18: A Customer Case

    Mascha Boender  and Stefan Groot presented an ABN AMRO case, “Crossing the DevOps Chasm: From Taboo to Enterprise DevOps,” in which they discussed their bottom-up journey of experimentation. They designed their approaches to see problems. They admitted failure, demonstrating their learning and how they made iterative improvements. They stepped away from a maturity model to a capability model, recognizing that one size doesn’t fit all teams. They provided a “Moonshot workshop,” focusing on specific team goals and ambitions and how these aligned to business strategic goals. They provided a DevOps playbook (based on captured team best practices) to help new teams develop practices at their own pace. To develop team “soft skills” such as communication and collaboration, they used the Phoenix Project business simulation workshop. This was done also with more than 30 leaders to create a mindset shift and demonstrate the change of leadership behaviors required to empower the teams and foster an enterprisewide culture change.

    Benefit: Enabling bottom-up and top-down “skills” and “culture” and aligning team goals to strategic intent.

    The State Of DevOps

    Nicole Forsgren and Jez Humble presented, “The Data Behind DevOps: Becoming a High Performer,” in which they shared findings from the latest “State Of DevOps” report. I won’t go into detail. I suggest you read the report, then read it again. Suffice to say their key messaging echoed many of the other sessions above: “Focus on outcomes, not output,” the need to “identify constraints and continually improve,” and for me an important topic: “Influencing culture through leadership and autonomy.”

    The ABN case above was an example of how they gave teams autonomy to change and  how they helped change leadership behaviors.

    DOES18: Final Thoughts

    As I stated at the start, culture to me is the No. 1 success or fail factor. The “State of DevOps” report stressed the importance of leadership on culture. Leadership was the top challenge mentioned by delegates visiting our stand. I”d like to share with you an article on devopsy.kinsta.cloud on how to influence leadership behaviors: The article is written through the lens of “communication,” tying back to a comment from Dominica Degrandis: “The hardest thing we do is communicate across teams,” and tying in with the ABN AMRO case about developing communication and collaboration skills.

    And finally, getting back to the start of the summit and the need to “upskill,” with the announcement of a skills survey, I’d like to provide some input. Here is a DevOps Agile Skills Association (DASA) article, “DASA Provides Core Skills Key for DevOps Success,” which summarizes the “people and culture” elements from the “State of DevOps” report (this year and previous years) matching these with findings from more than 400 teams having participated in the Phoenix Project DevOps simulation. This I believe can provide input into the survey.

    — Paul Wilkinson

  • ‘Yehbut’: Communication in the Age of DevOps

    ‘Yehbut’: Communication in the Age of DevOps

    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:

    1. Communication and collaboration seem to be critical enablers or barriers for DevOps success.
    2. The word “DevOps” seems to have taken on a meaning and life of its own, which is limiting the potential value.
    3. 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.

    — Paul Wilkinson