devopsy.kinsta.cloud

Category: DevOps Culture

  • Developers Have More in Common With Marketers Than They Think

    Developers Have More in Common With Marketers Than They Think

    Marketing professionals and developers together are critical in advancing customer experience

    More than a decade ago, in the early age of digital transformation, industry analysts and insiders began discussing the need for an increased focus on the collaboration between CTOs, CIOs and CMOs to achieve business goals. It was determined that CMOs would spend more on technology than their technical c-suite counterparts, thus creating an increased need for cross-functional alignment and cooperation.

    Today, we find the same kind of alignment is still required, but on an even deeper technical level—between developers and marketers. They are charged with the day-to-day operations of highly scaled and complex marketing operations driven by increasingly complex martech stacks. Companies across industries and markets are becoming more digitally oriented, so the need for seamless collaboration between business functions is mission-critical.

    There are many reasons for the perception that marketers and developers share completely different business priorities—from the trope of left brain versus right brain to completely different modes of operation, it has been assumed that marketers are practitioners of soft science and developers are entrenched in code. However, when you consider the nature of today’s modern marketing technology, you realize that both skill sets and sets of expertise are crucial to engaging, retaining and growing a company’s customer base.

    To marketers, developers can come across as unapproachable or highly focused internally on technical tasks that distance them from customers. To developers, marketers may seem less technically savvy and unsympathetic to the time requirements in technical projects and the juggling act and trade-offs that ensue for competing priorities. The result is an environment and dynamic in which one party often can feel the other has more control and say over the other. However, what we’re learning is that most of these sentiments are exaggerated or are changing as the business landscape continues to evolve. The truth is, marketers and developers have a lot more in common than they think.

    A recent survey of 500 marketers and developers at companies of all sizes uncovered the real truth behind this relationship and understand its inner workings. We looked at identifying their priorities, challenges and where they see success when it comes to their working relationship. Two things in particular stood out:

    1. Business alignment is overwhelmingly the key objective that both parties agree they need to effectively achieve to succeed.
    2. Customer experience is by far the highest priority where the two overlap.

    Broken down, 79% of marketers and 83% of developers agree that being aligned on business goals and priorities is a huge factor in being able to succeed in their roles. Developers cultivate this partnership in large part by recognizing that the work of marketers is becoming more data-driven and technical—a fact that 73% of marketers report being true.

    Meanwhile, customer success serves as the factor bringing marketing and DevOps closer together. Customer experience represents a critical driver to the success of any business, and on that, both marketers and developers passionately agree. Somewhat surprising, more developers (89%) than marketers (86%) agree with the notion that every touchpoint and interaction with a customer resolutely matters.

    The area where marketers and developers face their greatest disconnect is time. Forty-three percent of marketers feel they cannot get requests done promptly, while an overwhelming majority of developers (86%) are confident in their ability to deliver work within a requested time frame. When it comes to the development of new products or software, this is the biggest pain point for both, leaving each side equally frustrated when trying to appease the demands of the other. But with strategic marketing efforts, better collaboration and a more innate understanding of each others’ roles, marketers and developers can drive powerful business results.

    Here are just a few simple tips that can foster a more harmonious relationship between marketers and developers that results in real business value:

    • Marketers should involve developers in software evaluations as early as possible.
    • Developers should communicate the work required to accomplish a given request and any trade-offs that need to be made to curb marketers’ expectations.
    • Both parties should reconnect outside of specific projects to frequently share context about their goals, challenges and opportunities.

    That last tip is key, as the survey results show marketers and developers are more aligned on those factors than they realize. As the role of marketers continues to evolve in digital organizations and developers take note of this shifting tide, the two have the potential to wade each other through this massive wave of digital disruption. All it takes is walking a mile in each others’ shoes and realizing that both pairs fit.

    — Len Shneyder

  • The Human Value in Automation-Driven DevOps Testing

    The Human Value in Automation-Driven DevOps Testing

    Enterprises are embracing DevOps underpinned by automation to ensure the quality of software across all digital touchpoints. In fact, automation has become the crux of continuous integration and delivery, the vital DevOps testing goals. Without automation, DevOps would become a distant dream, and businesses would struggle to keep pace with seamless delivery and integration. However, DevOps entails more than the implementation of the latest automation tool and demands a more holistic approach. It does so by bringing together processes, people and technologies under a shared vision. As defined by Microsoft, DevOps is the coalition of products, people and processes to facilitate the seamless delivery of value to the end customers.

    DevOps is considered to be the latest advancement of the agile movement. It includes a greater number of stakeholders in the process of delivering value by linking the silo-based teams. It may not be the best practice, but it’s a discipline of people-centric management. Continuous delivery is the technical foundation of DevOps automation, which extends to the agile foundation as well. The close collaboration between the operations and development teams is known as DevOps, which is used to automate the delivery pipeline.

    Role of Automation in DevOps to Increase Productivity

    Since digital transformation has taken over the current business model, more and more companies are embracing the DevOps practice to drive the automated deployment of software. We are shifting toward an organizational culture in which development and testing take place simultaneously, quickly and more often. This helps maintain consistently high ratings on the quality of software with faster turnaround time. The main agenda of DevOps testing is to derive quality outcomes all along the software development life cycle (SDLC) and beyond. So, with the help of DevOps culture, a new code of development, testing and delivery is introduced in the overall SDLC.

    The automation in DevOps empowers companies to:

    • Enhance the reliability, re-usability and quality of all components.
    • Save costs of upgrades and maintenance.
    • Improve the rate of success for standardized processes to ensure the rapid delivery of applications.

    Automate Everything — Is It Even Possible?

    With the help of the DevOps approach, developers automate and accommodate operational activities, from the source code commit to operational productivity. The primary goal of DevOps automation is to remove bottlenecks in the pipeline by implementing automation in a single level of development. However, DevOps is not a fully automated process and is not operational without human intervention. It is the DevOps testing specialists who are responsible for the process to run flawlessly. Governance at every stage of DevOps testing is still indispensable in various processes undergoing automation. Importantly, human administration is still crucial in handling exceptions to complete the tasks of automation.

    The Strategic Role of Humans in DevOps to Ensure a Continuous Pipeline

    Remove the Boundaries of Roles

    The primary feature of DevOps automation culture is about an enhanced collaboration between the operations and development teams. It has led to a cultural transformation at the organization’s level and inside the teams as well, to encourage continuous delivery. Since shared collaboration is an important aspect of the DevOps culture, it strengthens the collaboration within teams. Before the DevOps approach, the perceived lack of interest by the development team regarding maintenance and operations used to affect DevOps testing and business goals. However, this scenario has since changed due to an organizational shift toward automation and DevOps testing.

    The gap between the silos of operations and development no longer exists with the arrival of DevOps. It has removed the boundaries of several organizational roles. Teams are required to focus on the shared goals of DevOps to enhance the end user experience, so the team members need to rethink every investment and decision around this shared goal, which requires human intervention. Automation cannot substitute the decision-making process of humans, for the latter has become vital across the organizational ecosystem as, and when, needed.

    Omit One-Size-Fits-All Approach in DevOps Testing

    Automation cannot be viewed as the eliminator of roles. The organization still requires expert knowledge and skill set inside your team. The focus should be on developing agile and cross-functional teams that are recognized for removing long-established stumbling blocks between the operations and development teams, and for facilitating collaboration. Developing efficient and functional teams would ensure the delivery of superior quality products.

    Continuous Monitoring, Testing and Improvement

    One of the key agendas of DevOps testing is to carry out a deeper level of monitoring. Since rigorous monitoring is needed at every layer of the testing process, from integration to infrastructure and transactions to components, it has become a crucial part of the road map of the DevOps approach. In this digitally connected world, monitoring and testing are no longer distinguishable. Continuous monitoring by testers offers a positive response to the user experience while eradicating pre- and post-production obstacles.

    Conclusion

    With the impetus in the growth of DevOps and agile practices in the past few years, testing has taken a new structure and form. It has evolved into a crucial discipline, and it’s not restricted to a phase of the development cycle anymore. It has become an essential part of the operational activities of production. So, is the role of a tester transformed radically from only a checkpoint to a crucial active participant in the DevOps testing? Teams need to cooperate based on the shared vision of enhancing augmented user experience. We need to understand the fact that automation is not an elixir to deliver on DevOps goals, but merely a part of the DevOps strategy.

    — Komal Lopez

  • DevOps Tools Democratize the View From Both Sides

    DevOps Tools Democratize the View From Both Sides

    How modern product decisions platforms marry the key metrics of features changes to organizational KPIs

    In 1967, Joni Mitchell released one of her most iconic songs, “Both Sides Now.” The song was inspired by the book, “Henderson the Rain King,” in which author Saul Bellow writes about flying to Africa and looking out the plane window, “Look at those clouds down there; it’s very strange to look at the clouds from up above them. I remember as a boy having dreamed up at clouds a lot and having seen the cloud from both sides now, I suppose I shouldn’t really be amazed by anything.”

    Although not her intention and slightly before its time of popularity, the song speaks quite accurately to the tensions between idealized DevOps and the reality on the ground that many organizations are struggling through. On paper, the core tenant of DevOps is about cooperation, seeing problems and processes from multiple team members’ perspectives from each side, but this is easier said than done.

    “But now old friends they’re acting strange
    They shake their heads, they say I’ve changed
    Well something’s lost, but something’s gained
    In living every day.”

    The Unicorns and the Rest of Us

    Some of today’s most successful and disruptive companies—including Google, Netflix and Facebook—have taken their market-leading positions precisely because they have developed strategy and culture around DevOps. It has been part of the company DNA since the beginning and every employee is bought into it. This means fast, agile development and experimentation is part of the culture.

    While many companies would like to capture some of the benefits that unicorns have realized from implementing these development methodologies, for many, this simply is not an option. There is legacy infrastructure, processes and people—who are sometimes the hardest to change. Often DevOps is embraced in small pockets of a company, by teams with newer members working on new projects. The mindset shift that needs to happen to have DevOps—and everything that comes along with it—become part of a company’s culture takes time, commitment and perseverance. However, a good way to start is by demonstrating the fresh, diverse perspectives that can be gained through experimentation and progressive exposure to encourage wider adoption.

    Leveling Up

    One of the ways modern app delivery, operations and business management teams at organizations all along the adoption spectrum are achieving governance, operational awareness and control at speed is by wrapping new code deployments in feature flags and using a centralized platform to control progressive exposure to users.

    By themselves, feature flags are not new. What is new is the centralized and externalized control plane as a service and, newer still, the idea of observing system and business KPIs at the user session or request granularity level for feature flag-controlled decisions.

    When something is rolled out to 5% of the users, it is not likely to light up global ops or business metrics dashboards, even if it is a bit broken—and that makes people cranky. If instead, tools are in place to monitor the KPIs within that 5% population and compare it to the other 95% looking for divergence, you have a much more powerful early warning system.

    These new centralized platforms also extend observability to stakeholders beyond the few wizards driving orchestration and ops teams watching dashboards. An anti-pattern to the local control autonomy spiel modern DevOps patterns call for, this wider visibility protects against local optimization traps in which one team improves its KPI while degrading other KPIs it doesn’t know or care about.

    It can be beneficial to have the idea of key metrics tied to a feature and organizational metrics that look after larger organizational concerns. This inspiration can be traced back to what LinkedIn does with its XLNT experimentation platform, where it calls the organizational metrics “guardrail KPIs.” By always tracking a set of metrics that are critical to the business as a whole, organizations gain a clearer view of the impact that both the granular updates and the larger rollouts are making to the business.

    As Joni said in all her wisdom:

    “I’ve looked at life from both sides now
    From up and down, and still somehow
    It’s life’s illusions I recall
    I really don’t know life at all.”

    No team or organization can know everything all the time, but we can build in visibility to the process of rolling out functionality to our users and create a shared vision of our intentions and the results we achieve. I would argue that if you do look at DevOps from both sides, up and down, you will know the benefits.

    — Dave Karow

  • Getting the Enterprise Digital Core in Shape

    Getting the Enterprise Digital Core in Shape

    While enterprises rush to transform their business digitally, most are taking tactical steps rather than building a comprehensive digital core that can be improved over time. Very few are taking a thorough view of their entire technology portfolio and looking for ways to create a cohesive core—their digital core—to provide them the strength and stability to move forward swiftly in their digitization efforts. The enterprise digital core essentially is the vital set of technologies and employee skill sets that enable the organization to deliver its digital services. These services are both consumed by customers and internally by staff and others.

    How do enterprises get their digital core into shape?

    Emphasize Talent Over Technology

    While a strong digital core includes the technological platform, it is also a people-platform. “The heart of digital transformation isn’t technology but the mindset and skill sets of your staff,” said Andy Lin, senior vice-president of strategy and consulting at Nexient. Digitization, he said, means enabling customers to transact and interact with you anytime they want, from anywhere, using any device. The only way to get there is if leadership makes it clear to staff why digitization is crucial; otherwise, they will struggle to adapt, he said.

    If the staff does understand the reasons behind the transformation, they will—instead of just following rules for the sake of rule-following—be much more likely to adopt a digital mindset. They’ll also be more likely to embrace the training and skill set development they’ll need to make the transformation a success, Lin added.

    Scrum.org CEO and product owner Dave West agreed that the digital core starts with the customer. “There needs to be a clear line from the mission and strategy of the business with the outcomes the customer wants,” he said. Teams need to understand clearly how their work helps deliver the organizational mission digitally to the customer, no matter what that mission may be. That means everyone needs to be clear on the nature of the business, or organizational business, as well as what success looks like

    West also advised organizations that seek to improve their digital core to look both inward and outward for support. From within the organization, of course, support should come from leadership, who must set the course and ensure efforts are going in the right direction. “Externally you need to build a network of support from people and organizations that have done it before,” he said.

    Put Cloud at the Core

    Of course, a strong digital core must have a strong technological foundation. In today’s typical enterprise, that may very likely mean more about subtraction than addition. While emerging technologies, such as internet of things (IoT), artificial intelligence (AI)/machine learning (ML) and others are recommended to be integrated within enterprise software, “Many of them are not generally suited to run on legacy IT infrastructure,” said Maxim Ivanov, CEO at enterprise software development firm Aimprosoft. “The digital core relies on intelligent automation scalable platforms that are integrated in the cloud and prepares data for next-generation technologies.”

    Gabriel Salazar, digital solutions manager at systems integrator Enstoa, agreed that building a cloud-based infrastructure goes a long way to improving the digital core. “It’s important, however, not to simply carbon-copy the business processes used prior,” said Salazar. “Look to take advantage of all automation, machine learning and analytics offered by converting and folding them into your updated business process.”

    Finally, if organizations want to have a strong digital core, they are going to have to work to maintain it. “Due to the speed of technology change, getting your digital core in shape is a continuous process. Start by understanding what is preventing you from supporting business goals, what is causing ongoing stability or performance issues and what reduces your time to market,” said Nick Polachek, senior principal of strategy and transformation at Maven Wave Partners.

    To do so, Polanchek recommended building the digital core iteratively while maintaining the focus on delivering business value or resolving current issues. It’s also important, he said, to have a thoughtful future vision for your digital core and ensure that each delivery is at least aligned, if not an improvement, over core technology already in place.

    After all, keeping that digital core in shape is an ongoing process that will require ongoing work and practice.

    — George V. Hulme

  • Are Your Development Processes Truly Agile?

    Are Your Development Processes Truly Agile?

    Many organizations are making a move to agile-powered environments, but agile development is more than a name. How do you determine if your organization is truly agile? The evaluation starts with the Agile Manifesto. If you’re following the principles laid out in the manifesto, that’s a good sign that you’re on an agile journey.

    For those not familiar with the manifesto, however, let’s review its points quickly. The Agile Manifesto’s core is simple—the primary points of the manifesto include the following:

    Individuals and interactions take precedence over processes and tools. This means the organization and its leaders place more value on people than they do on processes. People respond to business needs and they drive the development process within the organization.

    Working software takes precedence over comprehensive documentation. This is not about not providing any documentation at all, but you should streamline documentation. Any documentation that does exist should be necessary only for current and future development.

    Customer collaboration over contract negotiation. Engaging customers throughout the development process makes it easier for your people to meet the needs of your customers. Doing so means all business case features are clear and useful to customers.

    Responding to change over following a plan. This means change is welcome throughout the project, each project and allows for priorities to shift over time versus following a rigid or scripted development plan. 

    The Agile Manifesto 12 Steps

    Essentially, the core values of the Agile Manifesto can be fully detailed in 12 steps, or principles. These principles support the key points of the manifesto and provide additional detail as to how the practices can be followed in an agile environment. Again, for those who currently follow the Agile Manifesto, the following may be redundant. For those new to the concept, these steps provide clarification and direction to drive agile processes overall.

    • Self-organizing teams encourage great architectures, requirements and designs.
    • Regular reflections on how to become more effective.
    • Frequent delivery of working software.
    • Simplicity.
    • Support and trust for those involved in the process.
    • Enable face-to-face interactions.
    • Working software is the primary measure of progress.
    • Agile processes to support a consistent development pace.
    • Attention to technical detail and design enhances agility.
    • Collaboration between the business stakeholders and developers throughout the project.
    • Customer satisfaction through early and continuous software delivery.
    • Accommodate changing requirements throughout the development process.

    Based on these principles, there are three points—the final three listed here—that we often find the most compelling. A colleague of mine, Tobias Spöcker, scrum master and QA engineer, says these points naturally float to the top for an organization such as TOPdesk.

    The reasons for this are fairly obvious. We create products that are sold to thousands of customers around the world. To pinpoint any development problems, we look to the scrum process described by the scrum guide, with an emphasis on the last parts of the process. For example, the following illustration is edifying for explaining this process:

    Agile scrum process

    Notice in the “product release” phase illustrated above that the team listed here focuses on finished work for the development sprint. This portion of the model should be able to present a product incrementally to the stakeholders, including the customer. Ideally, these increments are released through a continuous delivery model. Here are two principles that further illustrate the point: Collaboration between the business stakeholders and developers throughout the project and customer satisfaction through early and continuous delivery of the software.

    There’s an additional consideration when providing value: Develop what is right; don’t simply develop something right.

    Adding Value

    At TOPdesk, providing the proper value to customers is a major goal for us. To achieve our organizational goals, we consider the impacts on our customers so when we start on a new product development project, we always work with some of our customers so they are involved in the development process, which makes the process and the product better for everyone. Those of our customers that have participated in our development processes usually tell us that they find the experience valuable and that being a part of the process also helps them when they use the solution. These same customers also express satisfaction in our efforts—as partners in the development process—and with us as an organization.

    Direct Feedback is the Key to Better Development

    The immediate and direct feedback we receive also helps to achieve another of our key operational principles: accommodating changing requirements throughout the development process. Through the partnership with our customers during the development phase, we’re able to receive regular, constructive feedback—even criticism—that leads to changes and evolutions in the product map and development stream. This feedback facilitates refinement of the most important processes and features, and moves them to the top of the priority list, leading to a project that’s undertaken with a focus on the most valuable areas so that development capacity (on the part of our organization) is spent the most wisely.

    Agile-Organization

    In Sum

    The agile mindset and the scrum framework are powerful tools if they are used in the right way. When considering following any development principles, don’t go in blindly. It is a good idea to see which parts of the toolbox help your organization be the most agile, efficient and customer-focused, and utilize the processes and principles that work best for your organization.

    Consider direct feedback from customers, which can be implemented immediately into the product scope. Provide simple-to-use customer communications vehicles, including metrics built into the software, surveys and feedback portals. Live demos of the product, when ready, can be extremely effective in helping you collect copious feedback efficiently. However, if your feedback loop is too big—meaning there are too many cooks in your kitchen—the whole process will quickly balloon beyond profitable, resulting in a less agile development process.

    The projects we develop using these principles are the ones that deliver the most value to our customers the most quickly. Including feedback from customers makes the development team more confident in what they are creating, and our customers tell us that they feel their needs and input have been heard, which they greatly appreciate.

    — Nancy Van Elsacker Louisnord

  • 5 DevOps Terms That We All Use, Yet No One Can Define

    5 DevOps Terms That We All Use, Yet No One Can Define

    I’m all for DevOps. Sometimes, however, I have a hard time talking about DevOps. The reason is because many of the key terms related to DevOps lack clear and precise definitions.

    Let me explain …

    DevOps is such a big deal that it has bred its very own lexicon. Search Google for “DevOps terms,” and you’ll find a slew of “dictionaries” and “glossaries” dedicated to defining the various terms that go hand in hand with DevOps.

    Yet despite these resources, some deep ambiguities remain regarding the actual meaning of various terms that you hear frequently in DevOps-centric conversations. Let me walk through some of the biggest.

    Continuous

    DevOps is all about continuous this and continuous that. Continuous integration. Continuous delivery. Continuous deployment.

    To me, the problem with the word “continuous” in this context is that it lacks an exact meaning. No one is integrating, delivering or deploying software in a literally continuous fashion. That would mean having zero delays between different releases, which is not the case. Even organizations that do CI/CD really well manage deliveries and deployments of only once per day or so.

    Maybe instead of “continuous,” we should just say something like “fast.” Because that’s what “continuous” really means in most cases.

    CI/CD

    Speaking of CI/CD, that’s another term that is ripe with ambiguity. It’s clear enough what “CI” stands for (continuous integration). But does the “CD” stand for “continuous delivery,” “continuous deployment” or both? Or does it not matter?

    Moreover, does a your application delivery process qualify as a CI/CD pipeline simply by including a continuous integration server (to do the CI) and some kind of automated deployment tool (to cover the CD side of things)? Or does a CI/CD pipeline also necessarily include build and test automation? I think most people would say the latter, but the term itself does not imply that.

    Microservices

    Microservices are all the rage in the era of DevOps. Depending on how you define a microservice, however, they have been all the rage for decades, long before anyone was talking about DevOps.

    The idea of distributing applications into multiple services is not new. That’s what SOA was all about in the 2000s. Going back further, there were microkernels, a concept popular in the 1980s. In microkernel architectures, the operating system kernel runs as a set of distinct services, rather than as a monolith.

    The question, then, is what makes a microservice, or a microservices architecture, different from other types of distributed, service-based architectures. Maybe it’s the size of the service, but there’s no official definition of what distinguishes a microservice from a non-microservice.

    Agile

    It is often said that DevOps builds upon the principles of agile software development. Those principles were defined, at a high level, in the early 2000s and spelled out in the “Manifesto for Agile Software Development.”

    It’s clear enough what agile means, but I’ve long struggled to piece together the exact relationship between agile and DevOps. Is DevOps “agile applied beyond the software team,” as one DevOps company puts it? Or are agile and DevOps distinct practices that just happen to have similar goals?

    It’s hard to say, because there is little consensus about what exactly “agile” means in the context of DevOps.

    DevOps

    Last but not least is “DevOps” itself. Different people have defined DevOps in very different ways. AWS says it is “the combination of cultural philosophies, practices, and tools.” Other definitions focus on philosophy, and leave tools and specific practices mostly out of the picture.

    Blurring the definition of DevOps further is the fact that virtually every tech company in the world calls itself a DevOps company today, with little concern for how, specifically, its products or services meet that nomenclature.

    What does DevOps really mean? I don’t think we’ll ever have a singular answer to that question.

    Conclusion

    In fact, I don’t think there will ever be clear definitions for any of the terms I’ve listed above. I’m not suggesting there should be.

    But I do think it would be helpful to the DevOps community as a whole to recognize the ambiguity in many of these terms. We use these words as if everyone knows what they mean, but the reality is that that is often not the case. If you want to use terms like “continuous” or “agile,” do so, but remember to clarify what those terms mean to you, because you can’t assume that they mean the same thing to others.

    — Chris Tozzi

  • Successful DevOps Initiatives Start With Company Culture

    Successful DevOps Initiatives Start With Company Culture

    What initially drove the need for embarking on the DevOps journey in your team or at your company in the first place? Was it:

    • Market shift?
    • New leadership or an acquisition?
    • New product or service idea?
    • Cost savings or consolidation?
    • All of the above?

    Whatever drove the need, my guess is there were pre-sales demos, reorganizations and training on new tools that were promised to solve all your DevOps problems along the way. Now, I must break your heart just a little: Buying new tools or apps will not, on their own, ensure positive DevOps outcomes.

    A tool-first approach is ineffective. In fact, it may actually generate backlash from the individuals or groups who are invested in protecting the status quo and result in a wasted implementation effort. Imposing new methodologies or processes across teams through new tools can cause people to dig in, generating responses ranging from passive-aggressive to overtly destructive—both contributing to failure.

    It Starts With Culture

    Your success on the DevOps journey starts with culture. Culture transcends tools, methodologies and processes, making use of all but not relying on any. Culture was, and always will be, present, and much like continuous development—routinely referenced in DevOps—it is continuously influenced by everyone and everything in its environment.

    The successful implementation of DevOps must begin with a conscious effort to reassess and evolve a company’s culture, supported by the tools. For example, continuous deployment as an initiative will only find traction when members of the team all believe, philosophically, it is best for the organization. It requires a certain kind of individual.

    A culture of rapidly evolving and adapting teams focused on continuously discovering, developing and delivering demands a commitment to evolving toward a more contemporary integral DevOps toolset, not the other way around.

    Culture Alignment as a Competitive Advantage

    Cultural alignment is not a buzzword bingo box that gets checked off. One’s sense of alignment with a clearly articulated mission and set of values, coupled with a way of working in a team and supported by the right tools, generates velocity and efficiency. This alignment becomes a competitive advantage.

    But, doing so demands all participants to be more conscious of how what they do affects everyone and everything else, in real time.

    Culture Change is Difficult but Achievable

    It can be very daunting or even scary if your company culture has a long history, producing images of the Borg or Hive, depending on your age bracket. Changing a culture is difficult. Here are some thoughts on where you might start.

    Learning agility: Focus on learning to dance with VUCA (Volatility, Uncertainty, Complexity and Ambiguity) instead of being consumed by it.

    Diversity: Commit to working with people with wide-ranging intellect, backgrounds, titles, CVs, life experiences, ways of learning, gender and energy, instead of working with your mirror.

    Trust: Build a work environment based on psychological safety—a sense of confidence that the team will not embarrass, reject or punish someone for speaking up. Knowing takes time and deliberate effort.

    Leadership: Adapt and promote a leadership style such as the 3 C’s of change leadership–communicate, collaborate and commit.

    Coaching Culture: Consider championing a coaching subculture by applying a methodology such as LACE to work through difficult conversations:

    • Listen to understand.
    • Ask powerful questions.
    • Challenge and support with feedback.
    • Establish next steps and accountability.

    Worth It

    We started with a little heartbreak. But I have had enough conversations about DevOps success and failure to believe that you already knew it was not just about tools. We have all felt the weight of culture when it is not in alignment. Employing some or all of these recommendations will set you down the path of creating your own language that is a requirement for building a culture. Now stop looking at the next great messaging protocol and start working on building an agile, aligned culture.

    — Joshua Platt

  • CTOs Should Embrace, Stick to a No-Meeting Day

    CTOs Should Embrace, Stick to a No-Meeting Day

    You know the feeling: You open your calendar in the morning to find a completely booked day, back-to-back meetings and not even 15 minutes of time to complete any of the items on your to-do list. In fact, your day tomorrow and the day after look just as booked.

    An HBR study conducted last year found that face-to-face requests are 34 times more successful than email when trying to effectively communicate or persuade someone. And, we all know that spending time with colleagues is critical to cultivating relationships and building company culture. But what if engineering team leaders took away just one day of these interactions to create more headspace for their teams?

    For the last seven years, I’ve opened space in my engineers’ schedules by mandating that one day per week must have zero meetings. While putting this rule into place successfully has been challenging, the benefits I’ve discovered consistently reinforce my decision to keep it alive and spread the word to other CTOs and engineering leaders.

    Here’s why you should consider implementing this rule and how your team can fully reap its benefits.

    Humans (Especially Engineers) Struggle To Re-Concentrate

    As technology advances and new tools provide us ways to reach each other faster throughout the day—and at all hours—the wealth of options to connect can cause communication overload. Add meeting after meeting into the mix, and focusing on one project without interruptions becomes nearly impossible.

    The phenomenon of feeling like you’re doing many tasks at once, but never truly finishing any of them, actually has a scientific explanation behind it: When you focus, the left and right side of the prefrontal cortex work in tandem. When you multitask, you switch between the two sides of your prefrontal cortex. Although this switch takes just a fraction of a second, it can actually take up to 40% longer to complete the same tasks than if you focused on each separately.

    While this multitasking phenomenon holds true for everyone, engineers especially feel the pain of multitasking, as most software development requires serious and uninterrupted concentration. As engineers figure out how parts of the system interact with other parts, distractions during this complex work might mean starting from scratch in the midst of a project.

    Removing meetings from the equation one day of the week provides them a window to take advantage of completely uninterrupted time. I’ve also noticed that my team now tends to organize projects of the week around this day off from meetings, reserving the no-meeting day to execute on critical tasks that require completely uninterrupted work, which contributes to increased productivity during that day. They slate in more complex work and time-consuming projects for this day and tackle smaller projects throughout the rest of the week.

    No-Meeting Days Encourage a State of Flow and Deep Work

    When people do what they love and feel passionate about their work (and don’t experience distractions while doing it), they often enter into what researchers have called a state of flow. In fact, psychologist Mihaly Csikszentmihalyi covered this topic in a recent TED talk, sharing his opinion that money can’t make us completely happy, but those who discover happiness have one thing in common: They find pleasure and lasting satisfaction in activities that encourage a state of flow. Giving your engineers just one day per week to reach this state could lead to increased and longer-term satisfaction with their overall work.

    Not only could a day without meetings enable your engineers to reach a state of flow for at least one day per week, it also could lead to enhanced skill sets. Cal Newport, a professor at Georgetown University, coined the phrase “deep work,” a state of activity performed in a distraction-free concentration zone that pushes cognitive capabilities to a new limit. By creating this deep work zone, you invite your engineers to unlock creative thinking and discover the solution to something new, simply through access to a deeper level of concentration.

    Commit to It and Stay Honest About It (I’m Talking to You, Managers!)

    The no-meeting day philosophy is not necessarily new. A number of companies talk about it in different ways, but when you look under the hood, you might find that not all managers enforce it well. I’ve discovered this lack of rule enforcement leads to a lack of employee respect for the rule.

    Therefore, it’s up to managers to weave it into their team’s culture. If you lead by example, you’ll set the tone and encourage other team members to follow.

    If you see meetings happening on a designated no-meeting day, encourage team members to move them. Re-state the benefits at recurring staff meetings (as needed) and ensure all new employees become well-versed in the benefits and reasons why the team participates in such a day. Most importantly, if you find a certain day doesn’t work well for the majority of your team, change it. Stay flexible and open to trying new ways to make this rule fit into your current team structure and schedule. The more you involve others in the creation of the rule, the more likely they’ll be to stick with it.

    Yes, every engineering leader wants his or her team to be as productive as possible. But often in striving to reach this overarching goal of peak productivity, managers miss the point: Scheduling less and taking a step back from day-to-day socialization and busyness is actually more—at least for one day a week.

    — Hector Aguilar

  • Technology: Isolation in the Age of Automation

    Technology: Isolation in the Age of Automation

    Dependence on technology makes us more independent overall, but it also makes us more isolated. So, what happens if things come to the point where we depend on machines more than we depend on other human beings?

    Earlier this month I attended a presentation about machine learning on mobile phones at Google IO 2019. Right now Google is spending a lot of time and money developing machine learning models and capabilities that operate solely within the mobile device. No connection to the internet is required. It’s a big deal.

    During the presentation, the company showed a video that featured an illiterate woman in India who uses her phone’s text recognition features to read to her. All she needs to do is point the phone’s camera at a recipe or newspaper and the phone converts the text to speech.

    I found the story inspiring as a technologist and as a human being. But it’s not all peaches and cream. At the end of the video, the woman said something that gave me pause. When talking about using the technology to book a train ticket, she said, “I can book it myself. I don’t need anyone’s help.”

    There’s no doubt the phone liberated her, very much in the same way that the light bulb liberated millions of other people in times past, bringing human activity forward beyond the setting sun. Dependence on a particular technology can create greater independence overall. However, I do wonder what happens when things evolve to the point where we depend on machines more than we depend on others, when we no longer need “anyone’s help.”

    To my thinking, human interdependence is the thread that binds the fabric of a society together. The thousands of little interdependencies that make up the human experience have beneficial side effects. To get along, we learn the basic rules of civility. We learn to say “please” and “thank you.” We learn how to wait in line at the DMV. We pick up after our dog. We open the door for others. It’s all part of the implicit contract that makes living with other people possible.

    But, these days it seems we depend more on machines than the kindness of strangers. The fact is, you don’t have to be nice to a machine, even for a self-serving purpose. You can yell at your cell phone. You stick your tongue out at the ATM as it accepts your deposit. Whether you’re nice to it or not doesn’t matter. Your deposit is not going to be processed any faster or slower. Your cell phone isn’t going to disconnect you because you were rude to it.

    Take away these simple rules of civility and strange things happen. It’s interesting that road rage is common, yet sidewalk rage is rare. Maybe wrapping ourselves up in a piece of silicon-powered transportation hardware predisposes us to a hostile attitude when interacting with others in the same situation.

    As I stated earlier, depending on technology makes us more independent in the big picture. But, it also makes us more isolated. Whereas in the past, talking about the weather with a stranger might be a prelude to another conversation that’s more meaningful, today the stranger next to me usually has his ears plugged up listening to his own interests. And, if I really want to know about the weather, I can ask Alexa.

    Modern technology gives me help on demand. I no longer ask a stranger for directions to the train station, I use my phone. It seems as if I need the help of others less during those small, random moments of vulnerability. A machine is but a voice prompt away. And, thus, the thread that binds me to the world at large gets a little bit looser.

    Now don’t get me wrong—isolation is nothing new. Five hundred years ago most people never traveled far from where they were born except on very special occasions. Village life is a case study in group isolation. But, while villages were isolated from the outside world, inside the village it was a different story. The social fabric was dense; the threads were tight. Being shunned by the group was a matter of life and death.

    Today we’re all over the place, literally. But we move in our own domains in which we end up wishing happy birthdays to people we’ve never met but who somehow have meaning to us by way of LinkedIn, Facebook and the plethora of other social platforms brought to life and sustained by something other than human labor.

    Is this such a bad thing? Dunno. I like it that my phone is now my personal stenographer. It helps me think better. But, I’m not sure that Google Assistant will ever be a good best friend. What’s even stranger is that a time might come when I don’t even need one. It will be just me and my mobile device. Then I won’t need anyone’s help, ever.

    — Bob Reselman

  • The Terrain of DevOps is Strewn with Pitfalls

    The Terrain of DevOps is Strewn with Pitfalls

    As Gene Kim, one of the leading thinkers in DevOps, once said, “DevOps is not about what you do, but what your outcomes are.” What he’s telling us is that DevOps is about enabling a rapid flow of work that transitions from development to testing to operations, but the bottom line is that it’s about achieving results. Unfortunately, this too often gets lost in modern-day DevOps practices.

    In this article, I will discuss five common pitfalls that occur in DevOps if you don’t pay attention to the endgame and how your organization can avoid falling victim to them.

    DevOps and Automation: Measuring the Wrong Outcomes

    Some people believe that, at its core, DevOps is about trying to automate everything. But ask yourself this: Once you automate, are you really delivering a better outcome?

    The answer is not always yes. While metrics such as deployment frequency or mean time to repair (MTTR) are interesting DevOps indicators, they are no more interesting to determining if your team is delivering actual value than measuring the number of lines of code submitted or counting the number of keystrokes by the development team. You measure outcomes by determining a baseline from where you start and compare that with where you end.

    We need to understand that DevOps is about much more than automation; it’s about the entire pipeline and how your team moves from ideation to delivery to production. Even large companies with world-class DevOps teams don’t always clearly see the problem and can struggle managing the value stream and putting together multiple pipelines. An anonymous but real-life example of this is an organization I know that had been doing DevOps for 18 months, yet hadn’t delivered anything into production in that span. Are they really doing DevOps? DevOps is a process, but if it produces zero value, it’s not delivering on its promise.

    The key is focusing on delivering value and measuring value delivery into production. However, before you can begin measuring value, you have to define what it means to each individual deliverable. Common metrics include the number of story points, actual revenue from product comparison and customer satisfaction. With your clearly defined metrics in place, you can measure value as it gets delivered to the customer.

    DevOps and Fragile Environments

    One Achilles’ heel in the DevOps process is the pre-production environments where code gets deployed and tested. Automating a delivery pipeline relies completely on code being built and deployed to various environments. Fragile environments mean that the developers and testers are wasting time dealing with problems originating from the environment and not the code itself.

    While we wish all environments could be on-demand; the fact is, most are not. Another DevOps expert, Randy Bias, has an analogy about pets versus cattle in describing servers, and the same analogy can be used for environments. If environments are not standardized and repeatable, you have to be willing to move on from it like a farmer moves on from livestock; you can’t hold onto sentimental attachments like we have with our pets. What’s most important is that in no case can an environment be singular in nature.

    One element of the solution is to create code and automate, but the key is building up environments that are complete. Every environment needs proper builds, proper data and proper tests validating the environment. Additionally, the automation must have the stability to perform successfully every time. If you have piece of automation that fails even just 5% of the time, that’s unacceptable.

    The only way automation works in an environment is if you can trust the environment. When the environment is unstable, it’s like playing Russian roulette: No one knows exactly where the danger lies. It could be in the environment, the code, the data, the middleware … a number of places. When a problem arises, developers are often the last line of defense, but dealing with an issue such as this pulls them away from getting real work done.

    Disconnected Teams

    On this point, I’d like to share a warning: Disconnected toolchains lead to disconnected teams. The planning, development and testing teams can lack cohesion, and the release and operations teams often struggle to be on the same page. Each of these groups have their own tools and management, but they need to be able to communicate with each other effectively to make things work smoothly. In an ideal world, planning initiatives would flow into features for the development and testing team, which would flow into release pipelines and operational changes. Every team still can speak its own language, but the tools need to be interconnected and unified across the teams.

    Mismanaging Hybrid

    The term “hybrid” has many different uses in the software development space. Hybrid methodology refers to combining waterfall, agile and DevOps practices. Hybrid environments means your environment is housed in multiple locations such as the cloud, on-premises, virtual or code. There’s also hybrid geography, hybrid architecture, hybrid style—the list goes on.

    The key to transitioning to DevOps is properly managing the different types of hybrid. If you can’t manage hybrid delivery, you can’t manage your entire delivery and you can’t improve your delivery holistically. Organizations must learn to manage in a world of hybrid delivery and be able to handle cloud and on-prem, as well as teams all over the planet.

    Fixing Non-Constraints

    The Theory of Constraints is about pinpointing the bottlenecks in your process and fixing them. Any work that’s not focused on eliminating the constraint will not result in improvement and could be considered a waste of time.

    It’s important to remember that if you haven’t fixed the bottleneck, you haven’t improved anything. At the same time, if you’re automating the non-constraints, you’re wasting efforts by trying to improve what doesn’t need improving.

    As we’ve pointed out, DevOps does not equal automation. If an organization has messy processes and tries to automate them, they’ll be left with an automated mess. Therefore, organizations will see the best results from automating their constraints and just as important, not automating the non-constraints.

    — Jeffrey Keyes