devopsy.kinsta.cloud

Tag: devops culture

  • Psychological Theories Behind Agile Software Development

    Psychological Theories Behind Agile Software Development

    As a software engineer who spent nearly 20 years working in social services—including working in institutions such as the U.S. Peace Corps, Child Protective Services, Chicago public schools and for governmental agencies in probation and parole programs—before making the leap into Silicon Valley, I found what helped ease my transition were my team’s retrospective meetings and the individual support from veteran engineers.

    This article is an attempt to draw from my clinical psychological background to make sense of the psychological theories of practice that I believe drive the success of any software development team’s reflective practices.

    Agile Software Development

    When I joined PagerDuty, I was immediately impressed by the implementation of Agile software development, the “you build it, you own it” philosophy, support of customer concerns and other diverse experiences necessary for companies and individual engineers to grow in today’s software market. However, I was particularly drawn to PagerDuty’s embrace of the Agile Manifesto’s last principle: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” At PagerDuty, we call these retrospective meetings.

    Our retrospective meetings embodied social and psychological theories of best practices so well, I realized that such meetings could help engineers, particularly those who find social interactions challenging, become exemplary leaders with interpersonal soft skills.

    Psychotherapeutic Theories of Practice

    Since many people in the software industry are likely already familiar with retrospective meetings, let’s dive right into the psychological theories underlying reflective practices rather than how retrospectives are practically implemented. The main theories of practice that I will focus on are psychoanalysis, vulnerability, stages of change, restorative justice and systems theory.

    Psychoanalysis

    At the root of all psychotherapeutic practice is some type of introspection that both the client and therapist together engage in understanding. Most notably, psychoanalysis attempts to discover and interpret past, unconscious or unknown thoughts, emotions, impulses and memories that currently impact the client’s thoughts, feelings, behaviors and entire life.

    Similar to psychoanalysis, successful retrospective practices reflect on the past thoughts and behaviors of the individual and team to make all group members aware of the things that perhaps only certain individuals were cognizant of. In Sigmund Freud’s work, free association allows individuals to express whatever comes to mind, without censorship or even organization. Engineering teams can adapt this method by encouraging free and uncensored verbal and written communication by making only certain information public and keeping managers from attending meetings.

    Vulnerability

    With the recent popularity of TED Talks, many have already been introduced to Dr. Brené Brown’s research on vulnerability. Dr. Brown discusses the power of connection in the human experience across all spectrums and how people with the strongest sense of connection believe that they are worthy of healthy human connection, which increases the courage to be authentic and vulnerable through risking rejection from others.

    In software development, reflective practice has the potential to cultivate a group that embraces, respects and supports each member’s vulnerability. According to Dr. Brown’s theories, a team will become more bonded, productive and creative when reflective practice supports members working through feelings of vulnerability, such as the uncomfortable feelings that come along with being dismissed, disrespected, not considered or facing difficult challenges that impact technical output, job performance and productivity. In contrast, healthy retrospective practices embrace and accept uncertainty, group responsibility and failure.

    Stages of Change

    Piggybacking off of vulnerability theory, the theories of the stages of change required for individuals to adjust habitual behavior is relevant because retrospective meetings should provide an atmosphere to “tune and adjust behavior” as needed. This model is relevant to the many successes of 12-step support groups for individuals recovering from trauma and addiction. It also helped me understand why I witnessed so many people continually returning to maladaptive behaviors. The 12-step programs and other theories of change suggest that, to make positive changes, individuals need to accept and move out of denial and into understanding of their problematic and unmanageable behaviors.

    As stated previously, healthy retrospectives will embrace uncertainty and failure, allowing individuals in supportive environments to face and accept the behaviors requiring adaptation. Denial can be a form of self-preservation, especially for individuals who believe they are powerless to make changes; however, denial will also lead many software engineering teams into further problematic behavior if retrospective groups do not have proper techniques for confronting maladaptive behaviors that need to be changed.

    Restorative Justice

    Restorative justice models of practice focus on both the offender and the victim (and sometimes their respective communities) to come to an agreement about the response to violations that will restore balance in all parties involved. For more on restorative justice theories, you can read this comprehensive review of research on restorative justice models in schools, published by The WestEd Justice & Prevention Research Center.

    While (most) engineering teams have not dealt with criminal activity—which is one of the main use cases for restorative justice models—they can still exhibit some components of restorative justice theories when processing events that caused disturbances in team productivity or emotional well being. I worked with restorative justice models by being a facilitator for “Peace Circle” groups, which have outlines for planning actionable items that all members support and by holding everyone accountable to follow through on these items in upcoming retrospective meetings. By focusing on recurring events or events with the most impactful and widespread consequences, teams can prioritize inclusivity of all participants, which is also imperative for social justice models. Healthy retrospectives will come to a common understanding of the group’s goals and help those in disagreement come to a way to accept group norms.

    Systems Theory

    Systems theory, often considered a cornerstone of social work, suggests that a person’s psychology and behavior often affect and are affected by the individual’s family, community, work and other societal systems. Being from Chicago, a city with a population consisting of roughly 30 percent African-American and 30 percent Hispanic people, I was taught how the white majority that I’m a part of implements societal and systemic factors that impact minority lives.

    To help understand systems theory, consider Dr. Deborah Prothrow-Stith’s research on violence that parallels current black urban violence with Alexander Hamilton’s death in a duel. She discusses how all the factors that reformed white men’s dispute resolutions (such as wealth, legal counsel, alternative means to power and criminal justice interventions) were entirely unavailable to black youth. In fact, the net asset difference between white and black families has increased since the Civil War. Despite what most perceive as advancements in equality and civil rights, darker-skinned groups have relatively less wealth compared to their white counterparts.

    These observations are important because they provide systemic context to individual behavior, which is primarily attributed to the autonomy of an individual. Many systems will continue unchanged if their norms are attributed to individual acts and the policies in place are not questioned. While individuals are often blamed for their behaviors, retrospective meetings acknowledge that teams influence individual behavior and that the entire team takes responsibility for the system and individual experiences. Successful retrospective meetings will provide a team the chance to change systems rather than placing the responsibility for systemic changes on any one individual.

    — John Coleman

  • 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

  • Simplifying Through DevOps in Banking

    Simplifying Through DevOps in Banking

    There are a great many assets available on the internet that talk about what DevOps is and how far DevOps adoption has come. So we will not repeat the “what” and the “how far.” Instead, we will focus on the road ahead and future of simplification and transformation at banking organizations and the role DevOps is likely to play in the same—in all three areas of “Run the Bank (RTB),” “Change the Bank (CTB)” and “Transform the Bank (TTB).”

    Figure 1: Change-Run-Transform Bank – POA with DevOps Maturity

    In this article, we take a look at what shape we think DevOps-driven simplification in financial organizations can take in the near future and also some opportunities for such simplification. As depicted in Figure 1, with DevOps maturity, the siloed processes of CTB, RTB and TTB will come closer together, allowing common activities and processes to be carried out in one place. The others will get simplified and automated thereby reducing elapsed time of cycle from ideation to production and application management drastically. This will yield benefits not only in terms of cost and time, but also in terms of feature availability to business.

    Banking Focus

    In banking, the early adopters are leading the march with a lot of good practices such as standardized tooling for specific technology areas, orchestration, feedback loop setup, process and technology rationalization, etc. The focus needs to continue on the same.

    We think that the challenge that DevOps architects need to now focus on is to be able to use DevOps to help financial organizations bring down the non-discretionary spend by simplifying the previously ignored maintenance, operations and infrastructure realms. The core of this DevOps driven simplification is needs to be move cost of maintenance to its lowest possible and hence releasing funds to discretionary areas in “Change the Bank” and “Transform the Bank.”

    While the point of arrival for DevOps-led transformation should be “full automation” and “zero maintenance” but they are a bit far in the future because the return on investment (ROI) on the monies and effort required to make that happen needs to justify the same. We see the focus shifting to value delivered to business by transformation of an application or suite of applications. Figure 2 depicts the core repeatable activities of a DevOps-led simplification exercise while keeping in mind these improvement cycles need the setup of feedback loops at each stage.

    Figure 2: Repeatable activities for DevOps-led simplification

    This brings us to our next idea, that the road map to DevOps-enabled simplification needs to be paved with metrics and measures and these metrics cannot be randomly chosen. These metrics have to be actually measurable and be divided into two areas of business metrics and IT metrics as we explain below and need to be diligently tracked to aid course correction.

    For example, release orchestration processes for applications are mostly complicated, need a lot of manual effort, have strict compliance requirements as well as security mandates, need to be carried out more frequently nowadays because of shorter deployment cycles and have to manage ever-increasing complexity of component interaction (upstream and downstream). Now, release orchestration is also a very important step in the entire CI/CD pipeline. So standardization and simplification of release orchestration process makes immense sense. But how does one measure success and quantify improvement?

    As already stated, intelligent insights (metrics and measures) are important in this process for both business and technical team members so that everyone has single source of truth for current status and distance from end goal. This kind of automation also helps focus on the continuous improvement pillar of DevOps adoption by logging everything that matters, have frame-by-frame data for everything that helps. This collection of metrics aids analysis of success as well as failure thereby furthering the cause of continuous improvement.

    Continuing with the example of release orchestration, there are many important best practices that help ensure that wheel is not reinvented. Some of the important learnings that only practitioners will be able to let you in on are as follows:

    1. Tools that need scripting will not be able to help you scale and create low-maintenance solutions.
    2. You need to invest in tools/orchestration solutions that help you visualize, get intelligent insights in a jiffy and can report in a variety of forms and shapes.
    3. Tools need to be able to capture and track business metrics, too.
    4. You need to spend effort on organization level compliance and security.
    5. Strive to automate your most effort-intensive and/or lengthy processes.

    Each step on DevOps maturity scale will have many such learnings and best practices that must get shared across the length and breadth of the organization.

    DevOps and Banking: Future Trends Prediction

    Based on our understanding & knowledge of financial organizations, we believe that the following areas will see focus in the next few years:

    Figure 3: Trends in short-medium term in DevOps adoption

     

    Continuous Improvement within Federation

    • Technology teams will need to enable and encourage localized innovation within a federated boundary of toolsets that will, in time, bring Dev and Ops toolsets to near mirror images of each other.
    • By federation, we mean a detailed homogeneous blueprint that gives flexibility but within an overarching boundary of tools and procedures while encouraging continuous improvement.
    • This must also inform relevant stakeholders about areas for continuous improvement that make the most evolutionary impact to business and use metrics suitably to track and reward improvement.

    Outcome Management

    • We also think that DevOps adoption needs to be driven by outcome management with evidence of impact taking the driving seat for road map management.
    • Focus will be on point of arrival (POA) and continuous measurement of business and IT metrics for outcome management.
    • We also believe that Culture-Automation-Lean-Measurement-Sharing (CALMS) model of DevOps will find more believers.

    Evidence of Impact

    • Metrics and metrics-based course correction will become the Holy Grail in the simplification exercise. The metrics collection will need to focus on areas of both business and IT. The metrics and measures will need to be redefined as:
      • Business Metrics for business value delivered or improved such as new products / services launched, conversion rate, net promoter score (NPS), customer retention rate, CSAT, ESAT, etc.
      • IT Metrics for value improvement and value management such as cost performance index, reduction in defect debt, reduction in lead time to change, etc.

    Design Thinking

    • We believe that the next big disruptor in this space will be bringing design thinking into the mix to ensure that DevOps-led automation is more customer-centric and iterative.
    • We see focusing on test data management (TDM) across the organization as an important step to ensure continuous delivery.
    • In our opinion, the testing process will undergo complete rethink with support of processes such as risk based priority and risk based test case design, test bed splits, TDM and so on.

    KM, Training and Governance

    • Tools and processes for knowledge management, training and governance need to ably support the DevOps-led simplification.
    • These processes will need systemic focus to create and nurture self-learning technology teams.
    • Transformation of the way of working to rationalize processes such as collaboration for lean and improved handover of work packages.

    DevSecOps

    • Security will be extremely crucial in the process of DevOps-led simplification. All the automation, cloud adoption, pipeline creation, IoT adoption and more is throwing up many new security concerns, thereby leading to a focus on DevSecOps.
    • Security processes will potentially need to move their execution points up in the CI/CD pipeline and be divided into stages based on iterations sizes and deployment cycles.
    • Focus on shifting left application security and role-based security.

    Conclusion

    The next wave of simplification of IT spaces in banking organizations will be aided by DevOps. To look for opportunities, a systematic approach toward DevOps will help—it will be perilous to ignore detailed assessment of existing spaces that will detail the current state, point of arrival simplified state, road map for simplification and the key guiding principles for the transformation.

    Carrying out pilots and proof of concepts in DevOps is not a problem; the challenge is with scaling—in all areas: tooling, training and processes. The key is to manage the horizontal and vertical spread of same/similar toolsets that also help drive efficiency associated with scale and standardization. DevOps-led simplification will need changes to processes, technology and people management (culture). The current role structures might need to be demolished to ensure there are no fiefdoms and cross-functional teams handle all requirements of Dev-Test-Ops. Finally, all the changes need to be able to define the new way of working  so that Change-Run-Transform organizations can be brought together.

    This article was co-authored by Babu Unnikrishnan, Head, Banking & Insurance Technology Group at Tata Consultancy Services.

    — Anshu Premchand

  • The Struggles DevOps Administrators are Up Against

    The Struggles DevOps Administrators are Up Against

    DevOps has quickly gone from being a niche concept to a widespread practice that is gaining traction rapidly in both large and small organizations. As it becomes a key part of many development teams, administrators must work to integrate DevOps techniques, tools and practices into a wide range of teams, from operations to development, support and management.

    The seamless completion of this implementation, together with the overall change in methodology and culture from top to bottom, provides a smoother workflow. The issue, however, is that admins are being asked to do more with less. DevOps administrators from large companies are struggling to keep pace, partly due to the newness of the practices, and in part out of a need to provide a competitive advantage for the business. Additionally, they find themselves in the middle of many different cultural pressures. All of this is leading to problems in fully implementing and reaping the benefits of a fine-tuned DevOps machine.

    That said, working through the implementation of a DevOps techniques will be worth it in the end and to make the transition easier, here are some specific pitfalls that administrators should try to avoid.

    Reliance on DevOps Technology

    One burden that is often faced by DevOps admins is an organization’s over-reliance on technology. In theory, technology is the easy part, but too often organizations become enamored with the newest shiny automation tool and find themselves in a cul-de-sac of isolation, forgetting to bring the rest of their organization with them.

    The wave of digital transformation that many organizations are experiencing can present additional difficulties as new technology is being implemented throughout different business units and administrators find themselves in high demand.

    Automation is awesome, but it isn’t the answer—it’s part of the recipe. The solution requires attention to processes and culture. According to a Gartner study, 73 percent of what organizations should focus on consists of attention to culture and communication, information exchanges and building operations process and organizational consistency. Only 27 percent should be on tooling.

    As the growing emphasis on DevOps places an added burden on infrastructure teams already struggling to cope with the digital transformation in their organizations, unification will be key to success. Ignoring the importance of creating a harmonious culture that embraces DevOps and processes that foster the methodology can be costly. Ensuring that tools are utilized in a smart way alongside people and processes will ultimately lead to more success.

    Building Collaboration Between Dev and Ops

    DevOps trust and transparency is at the core of release management. This level of collaboration and trust ensures that both sides of the equation agree when it comes time to ship software.

    Both sides in Dev and Ops frequently misunderstand the other’s motivations around production control and release management. Stability is king for Ops, and they would love nothing more than preserving uptime in each release, even if it means a blockage of imperative software updates. Dev, on the other hand, wants to move quickly, and they often make assumptions about what is required to support software in production. To help unite the two requires administrators have the ability to fill in the information gap that exists between Dev and Ops.

    In a way, DevOps admins work as the therapist for a severed relationship between Dev and Ops. Bridging the divide between these two departments can, at times, feel like counseling an organization to communicate better. But doing so through integration and collaboration is a surefire way to make life easier for everyone involved. DevOps doesn’t force people to become who they’re not; instead, it promotes cooperation, tolerance and shared responsibilities between the teams. 

    Lack of Transparency

    What many administrators also lack is a way to clearly understand, prioritize and utilize the data they have. From an agile practice perspective, that level of visibility should be established early on in a data reporting structure—project, initiative, etc.—and with the proper software solution. A solution that combines application release, environment, quality and deployment data across the portfolio to drive continuous improvement of software delivery.

    Being able to utilize this data makes a world of difference for delivery teams to be able to quantify, correlate and predict outcomes to help solve problems and make better decisions. The most basic, yet beneficial, insight you can have when making these decisions for an organization is to have the transparency to know that what you are doing is working.

    Creating a Culture vs. Working in Silos

    Application release delays costing hundreds of millions of dollars can be caused by poor management of complex enterprise software releases. A big part of the issue is that the very nature of agile and DevOps is to work in smaller teams, which can naturally create silos. For a given release, there can be many teams and, in some cases such as test environments, teams from different projects can collide due to lack of oversight. This complexity presents significant management problems and, without insights across the entire process, release trains are bound to crash.

    A culture of working in small teams on a single release lends itself to working in silos, and that isolationism often conspires against organizationwide success. This construct needs to be broken, as it produces an additional level of complexity and unification that will be a key point of emphasis for organizations in their road to digital transformation success.

    This unification will be especially important in large organizations that see frequent changes to their software release cycles, sometimes daily. It is imperative for these organizations to avoid silos and favor better communication with pronounced team roles, especially with the added confusion that the rapidly evolving delivery cycle can bring.

    Creating a cohesive and harmonious DevOps culture will benefit everyone in an organization in the long run. To be successful at this, though, it’s imperative that DevOps admins are given the rein to institute the change that they see fit. Admins must educate themselves on the latest technology, learn how to use and monitor it and bring in the rest of the teams so everyone can work together. But the burdens they are up against need to be dealt with on an organizational level from the top down, creating the ultimate DevOps working environment for all.

    — Bob Davis

  • Can You Implement DevOps in Large Organizations?

    Can You Implement DevOps in Large Organizations?

    Trying to modernize workflows through DevOps can be a challenge for any company, but there are different challenges, risks and benefits for bigger companies

    It is now more or less standard procedure to implement DevOps principles in startups or smaller companies. But what if you’re trying to utilize DevOps in large organizations? This is a bit more challenging, but let’s take a look at how such enterprises might approach a DevOps transformation through a few of the core tenants of DevOps.

    Rapid Feedback

    There are different types of feedback that come with DevOps: automated feedback about specific code (typically through unit and integration testing software), personal feedback from other team members, consumer feedback from customers using your product and cross-team feedback throughout the organization. Startups and small companies may find it easier to have open lines of communication between individual team members as well as across teams.

    Large organizations will need to make a conscious effort to keep team communication open. On the other hand, they will have more resources available (both money and employees) to field customer and in-house feedback about individual services or larger products. They may also be able to better purchase and implement automated testing and CI/CD tools, which leads to …

    Automation

    One of the biggest tech benefits to a DevOps approach is automating away the manual tasks that bog down critical projects. Large organizations often have the time, money and people to set up automated tools, such as CI/CD pipelines, unit and integration test suites and config management systems. The biggest challenge in the enterprise world is trying to make everyone happy.

    One approach is to standardize on a single tool for each purpose, such as Jenkins or Chef. This can enable your IT staff to specialize in those tools but may make some users unhappy with being forced into a tool they may not prefer. The alternative is to allow each team or business unit to use their own preferred software, but this can turn into a “toolset hell” with a mashup of every combination of applications within your organization. Each approach has its pros and cons, and often comes down to a management decision.

    Eliminating Silos

    Having individual teams that handle their part of the puzzle and nothing else is the biggest hurdle that enterprises face when trying to apply DevOps principles. The combination of “dev” and “ops” (and other disciplines, such as “sec” and “fin”) is naturally split out in a large organization, so recombining them can be a huge undertaking. Then again, that gap is exactly the problem the DevOps approach seeks to solve.

    Some companies solve this by having a separate team that handles the cross-team support and communication. Other companies break down these silos by enabling employees to migrate seamlessly between teams depending on the project or application. The more “DevOpsy” method is to utilize ChatOps and centralized documentation repositories for open communication and collaboration, which can help break down unify the distinct teams.

    Holistic Thinking

    The idea of holistic thinking tends to come easier to larger organizations, as successful enterprises typically have a system in place for “big picture” thinking, either through a management or product team, or through a cross-functional committee. That said, communication of this vision down to the employees, along with communication up to that management team, is crucial for enabling outside-the-box thinking to get past any roadblocks and hurdles that are in the way of creating and deploying the end product. Sometimes, the hardest part is convincing programmers that not everything needs to be solved with code!

    DevOps in Large Organizations: Challenging but Rewarding

    Some folks think that DevOps only applies to startups and small companies, but we’re seeing more and more teams benefit from implementing DevOps in large organizations. The benefits of the above DevOps principles are numerous, but frequently come with a different set of challenges based on your organizational size. Once you are aware of those challenges and have a plan to overcome them, you can start to transform your enterprise to a DevOps shop.

    — Jay Chapel

  • Does the DevOps Engineer Exist? How Beliefs Can Influence Hiring

    Does the DevOps Engineer Exist? How Beliefs Can Influence Hiring

    Does a DevOps engineer actually exist? That’s a risky subject to broach for a person who specializes in DevOps hiring. To the untrained eye, the easy answer is, Yes. However, to all the so-called DevOps engineers out there, the answer isn’t so cut and dry.

    While valid stances around this vary, here are some things to consider when hiring a DevOps engineer and the effects your mindset will have on determining who you choose.

    DevOps is not merely a set of tools but a philosophy that brings people together (cue two verses of “Kumbaya”) and structures a set of thinking that promotes personal ownership. This starts by bringing awareness to the consequences of individuals’ actions leading to a shared sense of responsibility toward creating successful products.

    Therefore, just hiring one or multiple DevOps engineers is seldom enough. When thinking of these hire(s) as a cure to your lack of DevOps, you are inadvertently hiring for the exact opposite of what DevOps aims to achieve. DevOps is a mindset rather than a set of linear workflows.

    It’s a methodology that must flow through cross-functional teams. It starts with your DevOps engineers, that’s for sure, but it does not end there, since the goal is for multiple teams to collaborate effectively toward the same end goal. By keeping your DevOps engineer(s) siloed in a “DevOps Department,” you’re solidifying the silo effect that DevOps was created to eliminate in the first place.

    What Exact Change Can We Expect?

    So now that you’ve hired a DevOps engineer through your trusty DevOps recruiter, what’s next? We know that just hiring someone with some DevOps skills won’t do the trick and neither will more hiring. The goal is not hire for experience with flashy tools but for technical expertise and enough interpersonal skills to spread a collaborative attitude. You’re looking for help restructuring how your teams collaborate, where everyone is now responsible for the finished product.

    When a group of people share this responsibility, a culture of healthy pushback and questioning is formed. Sure, everyone still concentrates on their specialties; however, restructuring everyone’s priorities toward continuous improvement brings a newly shared goal that is usually new to almost all parties involved who have not experienced this before.

    Whether you’re a Dev, Admin, QA or even a manager, this healthy questioning helps teams better understand the value everyone contributes. People begin analyzing their own work through a more critical lens and later do so when analyzing their colleague’s work (not always to everyone’s immediate delight). What were once separate departments can now gain a true understanding of what each group contributes.

    People begin questioning less on how much weight their colleagues are pulling and more about how their own actions affect the shared end goal which seldom exists before a DevOps mindset is introduced.

    Interviewing for the Right Fit

    So, can you really categorize this hire as simply a DevOps engineer while they are championing your company’s new work philosophy?

    A DevOps hire brings value that is not always tangible but helps mold companies and move colleagues’ priorities in the same direction. It begins with thinking about processes and aggregating everyone toward the greater good.

    Technical expertise is much easier to hire. The greater challenge is getting everyone on board with this whole idea of DevOps. Sure, maybe C-level management is bought in, but how do you get your lifelong employees to embrace such a seemingly radical change? This is where an effective interview process can make all the difference in finding the right DevOps engineer.

    Considering how communicative a DevOps engineer needs be to bring this change to tech and non-technical groups, a role-play method could help, in which your candidate explains DevOps to a nontechnical team member. It’s not enough to simply grill someone on technical acumen when you can more effectively see how they can make the idea of DevOps tangible to everyone in your company.

    If they can only communicate with fellow technical experts, they probably are not the right hire. However, if they can put the effects of DevOps in layman’s terms for other employees, it’s a safe bet they’re right for the job. There’s nothing quite like a real-world situation that could realistically be one of their first orders of business once on the job anyway.

    So, What’s Next?

    Again, this is not just about a toolset and whether someone has leveraged Kubernetes or AWS. This is about hiring someone who can restructure teams and implement philosophies. There is no such thing as buying DevOps or hiring someone to handle your “DevOpsing”—from setting mutually targeted goals and creating a dynamic of collective responsibility, a DevOps engineer will impact far beyond leveraging Jenkins, especially if this is your company’s first time around the DevOps block.

    So, after role-play and trusting your gut feeling on a person, can you genuinely call this an engineering hire? Some may still argue yes; however, this person is doing far more than just bringing technical knowledge. They have seen and helped companies digitally transform and can do the same for you. The best way to start is knowing what you are looking for far beyond a glossy skills matrix on a resume.

    — Michael Race

  • Living in a DevOps World (Part 1)

    Living in a DevOps World (Part 1)

    The concept of DevOps has grown and evolved into a conceptual and working model for more effective and efficient software development and implementation. That said, there are some differences of opinion on the real-world value of any DevOps approach to date, and on the best way to create and implement a real-world DevOps environment. This two-part article will focus on what an agile DevOps approach is meant to address, and what it is not meant to address.

    DevOps sits at the nexus of three essential business technology functions: software development, quality assurance and operations. A short and concise definition of DevOps proposed in 2015 seems as appropriate as any:

    DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into regular production while ensuring high quality.

    The definition was suggested in the book, “DevOps: A Software Architect’s Perspective,” and the authors have hit upon the essence of the practice. The key, of course, is how to put that concept into practice.

    Perhaps the first step on the journey to effective DevOps is the recognition that the concept is the result of the rise of the Lean and Agile software development methodologies. Those methodologies, among other things, emphasize the following:

    • A focus on customer value.
    • The elimination of waste.
    • Reduced cycle time (accomplishing work faster, releasing faster).
    • Shared learning.
    • Avoiding batching (don’t do things until required).
    • Theory of constraints (break things up, focus on individual issues).
    • Continuous integration, testing and delivery.
    • Faster time to market.

    DevOps in Practice

    Adherence to the principles above meant that something had to be invented to accomplish them and that something was DevOps. Over time, an effective DevOps practice should address any number of business technology pain points. The following short list of those pain points and the DevOps response should prove instructive.

    System Downtime

    The developers’ curse since systems were developed, system outages are inevitable as long as systems are designed, tested and implemented—even with increased automation—by imperfect beings. DevOps acknowledges that by changing the focus from trying to create applications that never fail to designing systems that can recover quickly, thus decreasing aggregate systems outage time over the life cycle of any application or system.

    Stagnation

    This was a staple of traditional systems development and is most closely associated with the waterfall methodology for systems development. After requirements were created, the development team would be locked away for weeks, months or, in some cases, years before emerging with “fully” working software that inevitably no longer satisfied rapidly evolving business requirements. DevOps is designed to fit hand-in-glove with the Agile practice of short windows of incremental changes instead of long release cycles, putting working software in the hands of customers as quickly as possible.

    Team Conflict

    Having been borne from the cultural combination of Agile and Lean, DevOps has taken on the problem of functional silos that are often erected between development, operations and the business customers. It follows the methodological approaches of collaboration and teamwork first to understand what others know and to leverage the best of it to solve business problems more rapidly. There is also a cultural bent toward experimentation, continual learning and constant improvement. This leads to blameless post-mortems, where instead of finger pointing when something goes wrong there is collaborative discussion and learning to correct and prevent the problem from occurring again.

    Knowledge Silos

    Functional silos have led to compartmentalized knowledge. If the old game was that knowledge is power, the new game in the DevOps world is that knowledge is freely exchanged as an enabler to solving business problems. DevOps addresses the problem of information being lost in translation between the development and operations functions by eliminating the functional barricades and making knowledge sharing the highest form of collaboration.

    Inefficiency

    Waiting for things to happen used to be a standard operating procedure in the pre-DevOps world. Project plans were created and managed to account for the time it might take for new code to be moved into a testing, quality or even production environment. This was a momentum killer for projects and at times a morale killer for developers waiting to see what changes they might need to make to their code set. The combined Agile and DevOps approach has rewritten the traditional approach to code migration, smoothing and eliminating wait times so that projects flow more seamlessly from start to finish. It also has the benefit of keeping business resources—testers, approvers, etc.—more engaged as a result of a constant flow of new functions and features to test and use. And lest this be viewed as simply a way to keep the technical stuff moving along, it’s important to remember that there is a financial aspect to this as well. Reducing speed to market with new functionality, reducing or eliminating idle hands—be they technical or business—and delighting customers with a steady stream of enhancements and features all go directly to an organization’s top and bottom lines.

    That, after all, is in many ways what the DevOps approach is all about. All of these critical areas become the means to accomplish it. Part two of this article will focus on some more of the benefits of a DevOps approach, and how to achieve them.

    — Dave Farinelli

  • 6 Steps to Take DevOps to the Next Level

    6 Steps to Take DevOps to the Next Level

    Enterprises should be winning at DevOps and reaping the rewards of their digital transformation initiatives. After all, DevOps is not new. Its practices, technologies and processes have been widely accepted for years. Agile techniques, which underpin DevOps, are not new, either. Similarly, digital transformation may have started as a “tech solution” but it is now recognized as a C-suite imperative.

    So why are the majority of business underexploiting their potential? Enterprises stand on the brink of a new era of opportunity heralded by 5G, the IoT and AI. So, how will DevOps rise to the new challenge of increased speed, scale and complexity?

    Time to Worry?

    Test automation levels in organizations speak volumes. Automation is an important marker of DevOps maturity and an indicator of how well a business can compete on quality at speed. So, it is a little worrying that software teams continue to rely on manual processes, with just 16 percent deploying automating common test activities.

    It is often observed that DevOps requires cultural change to really take hold. Motivating and retaining top talent is as important to the health of a DevOps implementation as the latest platform or framework. Yet, it is often passed over in favor of a “quick-fix” in the form of a tech solution. Relatively small adjustments in how teams approach DevOps can make a huge difference, as any practitioner of nudge theory will tell you.

    Here are six top tips to get DevOps delivering again.

    Silo or Service Approach?

    Consider switching to a horizontal software organization, sometimes known as a flat hierarchy, in which people are responsible for end-to-end ownership of the service they are tasked with. It is empowering because it gives them a complete view of what the service should be responsible for. In a vertical organization, the developers tend to become siloed and it can be hard to appreciate the bigger picture.

    Adopt Microservices and Container-based Architectures

    These technical advances have influenced how teams are built and how they operate. Their relative isolation forces teams to be organized independently. With that, comes flexible working and responsibility for the complete life cycle. View microservices and container-based architectures as opportunities for DevOps team members to have more ownership of deployments and results in faster release cycles.

    Publish Matrices for Increased Visibility

    There is a lot to be said for increasing transparency between teams and their members. Foster some healthy competition, share best practices or simply provide criteria for teams to match performance. This can be achieved with automated matrices that show software development and release agility, operational efficiency and quality of service. This kind of transparency is a motivator and will act as a catalyst to improve engineering.

    Automation Leads to Motivation

    Automation is vital for achieving scale and speed, as such, it is rightly seen as a DevOps must-have. It is also valuable because it frees up people’s time from routine activities and manual, repetitive, error-prone tasks. These manual tasks do not just burn precious work hours and reduce quality, they also grind down morale. Give developers interesting things to work on that are strategically important to the organization.

    Immediate Feedback

    In DevOps circles, people obsess about the importance of tightening customer feedback loops. But in an age where social networking is ubiquitous, it is not just customers who want immediate recognition more than delayed gratification. Employees are no different! Provide immediate feedback on code/ build/ test/ deployment /deviations from guidelines as they happen, so that corrective actions can be taken immediately.

    Top-Down Commitment

    DevOps requires C-suite commitment. This is especially true in the early stages of a DevOps implementation. Projects stall for various reasons. For instance, businesses can find it challenging to adapt organizational structures to fit the DevOps way of working. Technical hiccups occur too when technologies are new and its practitioners are learning the ropes. Active, unified support from management helps smooth the path to DevOps, deploying help and resources to ensure the project remains on track.

    DevOps is one part technology, one part process and one part people. It is easy to take it for granted. Too often, businesses prioritize the tech and the processes and forget that what makes DevOps transformational. It is the bringing together of two (formerly) distinct groups, the development and operations teams. A nudge, a pat on the back or a common goal go a long way. These softer skills pack a bigger punch and deliver a better bang for the buck.

    — Naveen Kumar

  • 4 Bad Habits DevOps Administrators Fall Into

    4 Bad Habits DevOps Administrators Fall Into

    The concept of DevOps is central to any organization’s ability to deliver applications and services quickly and efficiently. As it gains traction in many high-profile organizations, DevOps administrators must work to integrate DevOps practices, tools and techniques into a wide range of teams, from development and support to operations and management. Completing this implementation seamlessly leads to better productivity and a smoother overall workflow.

    Bad Habits Derail DevOps

    But along the way, administrators tend to fall into bad habits that affect their ability to deliver these services effectively and efficiently. Here are a few of the most common habits that need to be broken.

    Working in Silos

    Some DevOps teams work in silos, in which development isn’t just one team but many. Think about a group project where everyone divides and conquers on tasks and at the end comes together to integrate different parts, which in turn have different formats, styles, etc.

    This is a bad habit that needs to be broken as it produces an additional level of complexity, with everyone working to solve their own issue at hand in their silo. Operations then struggle to unify the activity into a consistent process. This, coupled with occasional tensions between development and IT operations over different approaches to infrastructure and competition for resources, creates opportunities for failure. As the growing emphasis on DevOps places an added burden on infrastructure teams already struggling to cope with the digital transformation of their organizations, unification will be key to success.

    It is also true that DevOps can find success in small organizations where teams of people are focused on smaller, one-off IT projects, rather than the enterprise as a whole. These smaller teams have the luxury of sticking to themselves and the allowance to work on sequential projects, while their projects don’t scale up to the enterprise stage because they don’t have to. But smaller organizations such as these also likely won’t see much of a difference if they were to adopt a DevOps approach.

    That difference will be most noticeable in substantially larger organizations that see software release cycles rapidly changing on a daily basis. It is imperative for these organizations to avoid silos and to instead have pronounced team roles, better communication and the ability and willingness to break free of old habits that only cause chaos and confusion in the rapidly evolving delivery cycle.

    Planning Too Much, Too Soon

    Success requires continual improvement and refinement, rather than an initial push for certain changes without an overarching plan. The focus of administrators looking to implement DevOps should be on doing all things continuously by starting small.

    Early focus should be on selecting one or two new DevOps teams that start a new initiative. Then, with these new teams in place, you can build on successes and work through challenges slowly, and begin to scale this through the organization. In the beginning of the process, it’s also important to identify one person such as director of operations or chief planner who can be responsible for seamlessly integrating DevOps into your project. This lead owner can then work project by project, setting goals and showing the rest of the team the results in real time. Insight into the progress will allow the team to see their work paying off, and in turn, make it possible for them to realize the benefits of scaling up slowly.

    You need to know what the business problem is and the anticipated benefits, therefore measuring every factor that contributes to DevOps success. DevOps promises an array of automation. This can’t be achieved in a single attempt or overnight. Enterprises have to focus efforts on continuous integration, following it with continuous delivery and eventually continuous deployment.

    Believing Implementation is Easy

    After admins are finally swayed by the promise of DevOps, a belief often held is that the implementation of the practice is smooth and easy. And while DevOps can often lead to a simpler life for specific jobs in IT, the reality is that in many instances, the ease of deployment comes at a cost. It can shift an imbalance of responsibility for production control and quality management to the operations side, and burden the team rules and processes if IT departments fail to understand how to adapt.

    As with any process in any organization, the amount of effort required to support software delivery is a constant. Often, administrators fall into the habit of believing DevOps will handle itself. But if you are managing a large enterprise, you will have teams accountable for quality, performance and change management. The difference with DevOps is the way in which automation is leveraged to place control in the hands of application development teams and redefines the relationship between operations and development. This is a good thing, but the administrators need to be there every step of the way in the process.

    Failing to Take Full Advantage of Continuous Integration and Delivery

    Continuous integration and continuous delivery (CI/CD) are key to successful DevOps teams. However, a bad habit many DevOps teams can fall into is failing to take full advantage of all the CI/CD benefits. The process must to be fast and efficient, as anything that slows down any part of the process increases the cycle time and slows down delivery. To break the habit, DevOps teams need to focus on eliminating bottlenecks in their pipeline to then facilitate agile development processes.

    Your CI/CD pipeline allows for the chance to administer efficient automated testing into your process, but shouldn’t stop at continuous delivery and continuous integration. Another step in doing all things continuous is continuous improvement. DevOps teams and administrators are constantly evolving to fit the needs of the pipeline, and it is imperative that teams spend some time every day discussing and hashing out the small things that can be improved upon. Over time, these changes—no matter how small—will have a profound effect on the enterprise and overall quality of morale between administrators and their teams.

    — Matt Geddes

  • 3 Steps to Building a DevOps Team Focused on Customers

    3 Steps to Building a DevOps Team Focused on Customers

    In most enterprises, Dev and Ops people inhabit different worlds, show scant regard for one another and communicate as little as possible—unless it is to vent about something done by “one of those” people over there. Dev and Ops are the chalk and cheese of software development and, mostly, that’s the way they like it. The concept of being on the same team—creating the best possible software for customers—might be quite alien.

    Obviously, Dev and Ops people are missing the big picture: They inhabit the same customer-focused world and need to get along for the greater good of the company, the customers and the quality of the software they are pushing out the door. Neither “side” will ever likely make that observation, and, even if one side did make it, the other would almost certainly reject it with derision.

    Consequently, the impetus for change and team-building must come from elsewhere, from an outside consultant or a C-level executive—ideally, a person with a firm grasp of cultural nuances if not the nitty-gritty of what Dev and Ops are all about.

    Step 1: Move Beyond the Stereotypes

    Savvy enterprises know they have to bring the “sides” together. The first step involves cultural cleansing, essentially scrubbing the ingrained and highly divisive stereotypes that exist.

    Ops people see developers as irresponsible code jockeys who thrive on creating new things and don’t care a fig about the business, leaving Ops to deal with their cavalier antics.

    Developers tend to see Ops as stick-in-the-mud, uncreative types who dislike change, and resist innovation because it will complicate their lives, even when such innovation will benefit the customer.

    On the whole, both stereotypes hold more than a grain of truth. They are like two sides of the bicameral brain.

    Companies must work hard to dismantle these stereotypes, which ultimately are counterproductive to creating unity and the high-quality software demanded by the customer.

    A good way to get both sides to cozy up to one another is to bring them together for a series of informal meetings, ideally at an offsite location where they can relax and socialize over a few days. In this way, they can understand and appreciate their respective roles and contributions—and view everything they do through the perspective of serving the needs of the customer.

    Step 2: Focus on the Customer

    Enterprises increasingly are tasked to deliver more features to their customers, faster and cheaper. Users’ expectations for more/better/faster/cheaper features are shaped by their experiences of web and mobile applications that keep doing more automatically or at the click of a button.

    With competitors releasing new features every few days or even hours, enterprises cannot afford unpredictable, lengthy and inefficient software releases caused by Dev and Ops not being on the same page and not understanding the needs of the customer.

    Unsurprisingly, many enterprises are doing whatever it takes to deliver better software faster, notably:

    • Having measurable goals;
    • Incorporating automation and continuous delivery into DevOps; and
    • Pursuing a relentless focus on testing.

    The whole process is frequently untidy and painful, but immensely positive if done properly.

    A major element of every enterprise’s strategy for delivering better software faster is to bring Dev and Ops together, ideally under one roof—united by their focus on the needs of the customer.

    Step 3: Measure Performance by Customer Satisfaction

    Once the groups are on the same page, you should start measuring their performances in terms of how well they meet customer experience. Developers will have the incentive to make sure that the goods they deliver to Ops are high-quality and stable, while operations people will have the incentive to make sure they release enhanced capabilities to customers as quickly as they can—before the competition does something similar or before the enterprise loses the customers to some other alternative.

    When Dev and Ops people work together, they can gain insight into the negative effects of their old behaviors, better understand their joint goal of delivering top-notch software to customers quickly and eliminate all or most of the terrible wait times that typically exist between Dev and Ops.

    In Summary

    Chalk and cheese don’t mix. Neither do Dev and Ops people if you accept the cliché of the two sides being antagonists locked into their fiefdoms. However, modern enterprise software development forces companies to move beyond clichés and fiefdoms to embrace a customer-focused vision of DevOps.

    — Victor Cruz