devopsy.kinsta.cloud

Tag: people

  • In DevOps, Chatbots are a People Problem

    In DevOps, Chatbots are a People Problem

    By now, you are undoubtedly aware that you can call up a chatbot or install an AI assistant into your IDE and generate entry-level code and deployment scripts.

    Indeed, if you just go to a site like ChatGPT and enter “generate Python code to do X” where X is something you need to be done–or an example like “read a file and print out the contents one line at a time,” it will do it. And if you keep it simple, it will do it well. If you say “again, in Java,” it will comply and do it well.

    Then say “new chat,” and tell it to “write a bash script to deploy an app named X written in Java and using Gradle to a cluster named Y,” it will do that also, informing you of the names of the deployment and service YAML files. Then you can say, “generate the deployment file mentioned,” and it will. And then you can say, “parameterize the Java version,” and it will do that, too. This iterative revision can continue until the deployment code, containers and deployment files are complete. If you have not yet, I urge you to spend the half hour going through these steps once required, so the potential is obvious.

    It is not yet to the point where I would (or you should) trust it with complex systems, but all of that busy work we’ve been trying to overcome with templates and preconfigured containers? We can actually get around the bulk of it now. The same is true for testing of all kinds. There are tools that will auto-generate test scripts for a given set of source code. They will also generate test execution code. That means that the only step left—and the one that has held testing back because of the volume of work—is reviewing results … But wait, there’s more! In security testing, AI can help eliminate false positives. In performance or QA testing, it can filter out all but the most egregious issues (as defined by the org or by a larger pool of apps).

    The problem we need to address today is the people issue. What we have traditionally used entry-level people for—and trained them in Dev/Ops/DevOps with—is no longer necessary. Because the AI can do it. That is stunning and really very cool, if you think about it.

    But it heralds a danger that every org needs to be aware of. What we do and how we do it is changing. For the better, but change always brings uncertainty, and the foreseeable bit we need to confront is, “Now that we don’t need entry-level people for these steps, how do we recruit and train them?” I do not yet have a definitive answer for this question, because I am a product of my time, so I see things in terms of learning the bits that make up the whole—advising people interested in DevOps to learn at least one Linux command shell, to understand how networking works in containers, to write the scripts to get containers (and/or public cloud instances) up and running, etc.

    I do think that every org should start using these tools at a pace that makes them comfortable because it allows us to continue our “more with less” growth without significant pain. But we need to make certain we are training the next generation of DevOps engineers in the process. For the foreseeable future, we’ll still be the ones bug fixing and troubleshooting, so we need to understand the environment and the applications. We are starting to get some sweet tools to help us at a higher level, though. Anyone who has inherited complex systems knows that the learning curve of tons of source files that make up many subsystems and all of the spaghetti code that these can be comprised of is painful. I don’t normally mention brand names here, so I’ll just say there is at least one tool out there that you can ask to “describe what this code does” and it will run with it and give you an answer in plain English. This might be the training tool of the future, with the ability to compare what you see in code with what the AI describes in English.

    But for now, even if you don’t hunt down app description AIs, having entry-level people review the files that the AI generates will serve two purposes: First, to validate what the growing AI space is capable of and second, to get entry-level engineers into the entry-level bits of the systems.

    And keep rocking it. Make sure you have a path for DevOps in the AI future, but remember that the creation of the calculator did not statistically change the number of mathematicians, just made the bulk of them more productive. That’s all we’re doing here, just a bit more flexibly … But in the end, like a calculator, the AI has an equation that it fills and reports back with.

  • DevOps Transition: The Cultural Commitments and Challenges

    DevOps Transition: The Cultural Commitments and Challenges

    Enterprises can achieve certain levels of success by filling a need in the market, hiring skilled teams and utilizing cutting-edge tools and technologies. However, to set themselves apart and chart a course for long-term success, they need to address the values, beliefs and behaviors that make up organizational culture as carefully as they address business decisions. It’s culture that ultimately informs the decisions made about how a company evolves its concepts from idea to value, so when you want to make a change and grow, that’s where you need to start.

    One area where culture is particularly important is the introduction of new practices and processes applied to software engineering and the role that a DevOps strategy plays within organizations. DevOps encourages a mindset of communication, collaboration, integration and automation among software developers and IT operations, so it’s more than just a new set of tools; it’s a cultural shift. This change doesn’t happen immediately or automatically, it requires deliberate steps and actions to be taken, and calculated decisions to be made.

    The shift also requires commitment. A recent Gartner report, “New Insights into Success with Agile in Digital Transformation,” found that organizations must be prepared for a commitment of three or more years to ensure success when moving to a more agile development process. Teams with less than a year of experience with a new development process show a success rate of 34 percent, while that rate jumps to 64 percent with between one and three years of experience. After three years of agile experience, the success rate skyrockets to 81 percent.

    New Technologies Accelerate Momentum, not Create It

    Implicit in the decision to move to DevOps is the desire to develop faster. To do that, organizations often begin the process by saying to themselves, “We need to automate things.” They buy a variety of testing automation tools, production delivery tools and anything they think will make them more agile. However, if they don’t take steps to prepare the people in the organization, things can get worse, not better, because the new elements can create isolated teams centered around “campfires” where separate teams use the various new automation tools individually.

    When teams are undergoing transformation, we often see them go through a roller coaster of up-and-down results. This was illustrated in the DORA report, “Accelerate: State of DevOps 2018: Strategies for a New Economy.” When the transformation begins, teams quickly identify wins and automation helps lower performers improve, creating an uptick in overall performance. However, as the process moves along, automation increases test requirements, which are still dealt with manually, and a pile of technical debt blocks progress. At the same time, the mounting technical debt and increased complexities cause additional manual controls and layers of process around changes that, more often than not, slows work. Teams generally don’t see an upswing in results until putting in relentless efforts toward improvement, leveraging expertise and learning from their environments, which finally results in a jump in productivity.

    This is a moment when organizations need to lead with their brains, not their pocketbooks, and stay committed to the process. To minimize the risk of failure, they must address the people and the process with the same rigor and commitment they address the technology. In fact, evolving the culture and process associated with how people work is the biggest challenge in adopting DevOps. People resist change and no amount of technology makes change easier.

    Any initiative that begins with just buying software or technology to make the organization agile is a mistake. The best way for a business of any size to launch a DevOps initiative is to get people comfortable with the vernacular and the process before changing anything. I’ve seen organizations go so far as to change the name of existing processes just to get teams thinking differently before the real change is made.

    Putting in Tools Before a Plan is Like the Cart Before the Horse

    After seeding the terminology and idea of change, the next step has to be tactically thinking through how the organization will evolve. It’s often thought that tools will make an immediate impact, but not enough planning is done to integrate the tools before being taken out of the box. Basically, they end up like a bunch of kindergartners at recess: Everyone has their own toy to play with but they do it alone and no one works together.

    Before putting in new tools and changing processes, there needs to be understanding around where the gaps and inefficiencies are so KPIs and metrics can be mapped back to tell where progress is being made. You can’t manage what you can’t see, so you have to develop visibility into the process to understand where those inefficiencies currently are. When that is achieved, remaining constantly vigilant to understand the constraints that exist while establishing new processes and using the new DevOps tools will allow you to continuously improve.

    It needs to be known that the reward is worth the risk. Making the move to DevOps can’t be thought of as a decision or a choice, it’s an imperative for organizations that want to remain competitive. Every organization needs to become a software company and to do that they need to move to DevOps and make continuous improvement part of their DNA. Organizations can’t fear the move, they just need to be diligent with the transition, monitoring and follow up when adopting DevOps.

    — Bob Davis

  • Roadblocks to Successful DevOps Often Human, Not Technical

    Roadblocks to Successful DevOps Often Human, Not Technical

    Usually, when people talk about DevOps, they focus on the technical aspects. However, in my experience we need to highlight what lies behind technology: the people. To effectively implement DevOps, we have to understand that many obstacles are not technical, but human.

    In working with various organizations in their DevOps journeys, I have seen six main roadblocks to a successful DevOps implementation:

    1. We mistakenly blame technical obsolescence: Tech teams should avoid justifying slow processes and lengthy deployments just because of the existence of old systems. To do the best with current systems, analyze your workflow and decide whether the problem is less a matter of technical tools, but one of attitude and organization.
    2. We don´t cooperate: DevOps doesn’t work unless teams can work together. There are three steps to building collaborative teams. First, work hard. Your good work speaks for you; it gains you the respect and cooperation of your colleagues. Second, highlight the contributions of others. Offering recognition shows that each member of these diversified teams is important. Finally, learn how other teams are being evaluated so that you better understand their behavior and can work with them in achieving real cooperation.
    3. Our egos get in the way: Ego leads us to believe that our approach and knowledge apply to every problem and that we can simply solve these issues. It prevents empathy and the ability to properly help to those who come from a different context or background. In DevOps teams where people come together from different perspectives and backgrounds, this is particularly important. So please check your ego at the door.
    4. We are unwilling to leave our comfort zone or the status quo: DevOps is about speeding up processes and providing new ways to work. As a result, DevOps teams should question traditional methods and understand that some rules no longer apply in the digital world.
    5. There is a lack of leadership: DevOps teams succeed under real leadership. Real leaders give visibility to everyone and understand that anyone can offer critical contributions, even when least expected.
    6. We suffer from cognitive bias: Cognitive bias comes from our background, our personal experiences and our careers. However, we shouldn’t let this condition us. It is essential to move forward and understand that our experiences and knowledge do not apply to every context. DevOps teams must be aware of cognitive biases to build a proper solution for problems that may arise.

    These six human aspects can often form obstacles to DevOps implementation. To help overcome these challenges, I typically recommend three broad strategies to organizations:

    • Technology is a means but not an end. It is important to understand that technology is what helps us solve problems, but it’s not the solution in and of itself.
    • Understand the problem and find balance. Avoid over-engineering; you do not need to prove how much you know about technology in general, you need to find the proper solution.
    • Be humble and curious. Technology is never static. There is always something new to learn. In the field of DevOps, it’s critical to constantly investigate and renew ideas.

    A successful implementation of DevOps is not only about automation. It is also about people who make decisions and use tools. However, for many enterprises, transitioning to DevOps represents a fundamental shift in how individuals and teams will have typically worked in the past. This is why I encourage DevOps teams to evaluate their workflow and be aware of aspects such as ego or biases, as they do affect performance. Handling these situations might require professional assistance. I suggest working closely with human resource professionals or turning to business psychologists to understand these human aspects. In turn, this will enable your DevOps teams to walk toward success.

    — Ernesto Cardenas

  • DevOps is Failing, But Here’s How to Succeed

    DevOps is Failing, But Here’s How to Succeed

    As the Data Economy continues to gain momentum, many companies have turned to DevOps in hopes of achieving agility and velocity to compete and win. Whereas it’s no secret that DevOps can have a major impact on agility, what’s not widely known is that most DevOps projects actually fail. In fact, a simple search of “DevOps failures” returns a range of recent results from minor issues to major fiascos. So, what are the warning signs that an initiative is failing to live up to expectations, and how can you fix it before it’s too late?

    Focus on People, Not Tools

    There are several types of potential problems that undermine the efficacy of DevOps, and the most common one—which is the easiest to overlook—is failing to recognize that DevOps is a changing of processes. So, as with any kind of process change, it can only be effective when it’s embraced and adopted by all people involved. Organizations that are successful are able to not only shift processes, but also win the hearts and minds of workers and get their buy-in early on.

    When leaders approach DevOps as a tools-first methodology without addressing outdated legacy systems or the underlying IT cultural issues required to make newer tools work for their organization, projects have a tendency to either fail or fall short of expectations. In today’s competitive digital business landscape, DevOps teams need to be able to deploy multiple test environments multiple times a day to collaborate and test effectively.

    But deploying DevOps technology is often the easiest part. The real problem is trying to use the same tired data management techniques with those new tools. If marrying new tools with old structures (or systems) were simple, most companies today would already have DevOps approach in place. For initiatives to be successful, though, requires a significant shift in thought from leaders and workers alike to achieve both short and long-term development goals.

    Slow-to-Change Culture

    DevOps is all about using rapid iterations and collaboration without requiring formalized meetings to move forward, broker alliances or seek permissions. Given that DevOps is a people-driven process at its core, you know you’re in trouble when your teams are holding routine meetings lasting 30 minutes or longer. If you are doing this, it means the organization is still operating in a siloed manner, which undermines DevOps efforts.

    Creating a successful initiative takes clear communication, because even though everyone wants the same result, they often want said result on their own terms. Introducing DevOps efforts into a well-established organization isn’t easy, and often there can be culture shock and even pushback from rank-and-file workers all the way to mid-management or senior leaders.

    With that in mind, to build a culture that enables agile development, it’s important to communicate objectives clearly and act with discipline early. There should be a well-defined explanation of the objectives, metrics and goals by which your DevOps initiatives will be measured across the organization. It’s not enough to adopt DevOps practices just because it’s the buzz right now; rather, you need to be able to understand how it can help you rebuild your business process and achieve specific development goals—or else your success is not likely.

    You can’t evolve a company culture overnight, but with the right approach and commitment to the DevOps journey, you can lay the groundwork for organizational change and achieve more agility.

    Inefficient Workflows (Data Friction)

    DevOps initiatives are often dependent on applications, which are powered by business data, but getting that data to the right teams can create an enormous amount of drag on the workflow. We often call this data friction. This is a prime example of data friction, or the tension between demand for data access and the constraints that stand in the way.

    This commonly leaves DevOps teams in one of three places, each with their own drawbacks: using stale and polluted data sets, stopping Dev and Test to wait on data provisions and refreshes, or just developing on purely synthetic data (punting the data problem to Test). To avoid returning to the same constraints, we need to rethink the way our teams access data in a way that minimizes the current friction so that we’re no longer choosing between quality, security and agility.

    Data should flow securely, freely and at lower cost, eliminating the friction around data. Synthetic data should be used for development because it is the correct data to use for development, not simply because it is the fastest. Taking a DataOps approach—tackling the data constraints around people, process and technology—is the only way to ensure you are eliminating data friction, rather than shifting it to someone else.

    Conclusion

    Companies set themselves up to repeat mistakes when they try to throw even more technology at the problem, without considering how existing infrastructure, culture and tools will work together in a DevOps strategy. At the end of the day, a tool is only as good as the teams who use it, and DevOps as a methodology should always be considered a continuous cycle of improvement. It’s time to broaden our perspective on the aspects of data management that we can improve upon to also include the people behind the tools. The future of DevOps depends on our own team’s flexibility and willingness to continually improve our own processes.

    — Adam Bowen

  • Why the DevOps Trinity is Key for Digital Transformation

    Why the DevOps Trinity is Key for Digital Transformation

    As digital technology continues to disrupt and transform businesses across industries and around the world, the ability to deliver high-quality software rapidly will make the difference between survival and extinction for many companies. DevOps seeks to change the dynamics in which operations and development teams interact. Ultimately, successful adoption of DevOps and the process of continuous delivery are likely to determine whether an organization thrives or fails in the digital age.

    To build a sustainable DevOps culture and achieve true DevOps success, organizations need to consider the DevOps Trinity—people, processes and tools—and understand how to connect all three:

    People and Culture

    The core tenet of DevOps is a culture of collaboration and shared goals, which eliminates finger-pointing and promotes teamwork, with everyone working together in support of the same outcome—reliable software quickly delivered to production. In essence, the goal is to enable the different stakeholders in the software development and delivery process to reach the mutual understanding and empathy needed to drive alignment on shared goals. To achieve this change, teams need to have trust, honesty and responsibility.

    Process and Practices

    DevOps aims to achieve predictable, efficient, secure and sustainable operational processes. Using a DevOps approach, simple processes become increasingly programmable and dynamic. Automation supports this objective by using technology to streamline the steps within the process.

    Tools and Technologies

    Some categories are more essential in a DevOps toolchain than others, especially continuous integration (build) and infrastructure as code (configure) tools. The common elements of the toolchain include applications for coding, building, testing, packaging, releasing, configuring and monitoring. Often, rather than a single tool, there are sets of tools (or toolchains) of multiple tools, that make up the process.

    A sustainable DevOps organization cannot be achieved without all three components of the DevOps Trinity.

    For those looking to learn more about people, processes and technology needed for successful DevOps implementation, join us in San Francisco Sept. 16-19 for DevOps World | Jenkins World. With this year’s conference theme “TRANSFORM,” attendees will learn how organizations are transforming software delivery, adopting DevOps and returning business value to their organization from DevOps initiatives.

    Don’t miss Viktor at DevOps World | Jenkins World! Be sure to register today for 20 percent off your registration using the special devopsy.kinsta.cloud code just for our readers: JWDEVOPSCUST

    — Viktor Farcic

  • 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

  • If DevOps is Required, Then It’s All About Change Management

    If DevOps is Required, Then It’s All About Change Management

    For more than two years, I have participated in a number of panel discussions at Boston DevOps, our local DevOps meetup.  Panels have been put together from several disciplines to address issues through the successful adoption of DevOps and reaching optimized use of this current methodology in software development.

    As relevant as the DevOps challenge is for every technology organization, it remains elusive. Many groups simply are not cracking the code and in some cases simply do not know how to effectively start the change. Check out SMART DevOps as a way to get started.

    A recent panel in which I participated was set up as an informal question-and-answer session, including questions from attendees viewing a live stream of the event. The introduction by one of the panel members laid out the complexity of issues required to optimize DevOps in an organization. It was clear from the audience questions, as well as those from the live stream, that there was discontent among representatives of all three groups who have been combined into a DevOps function–issues related to implementation and ongoing results. As I prepped for the panel, I came upon a Gartner Group article that had an extremely interesting quote in it: “The DevOps trend goes way beyond implementation and technology management and instead necessitates a deeper focus on how to effect positive organizational change. The DevOps philosophy therefore centers on people, process, technology and information. With respect to culture, DevOps seeks to change the dynamics in which operations and development teams interact.”

    One of the questions from the live stream was: “If DevOps is so great, why is everyone so unhappy?” Another question from the panel moderator very clearly and succinctly asked about the kinds of cultural change happening in organizations, separate from new tools and new practices. The commentary from some technology-oriented panel members precipitated the rapid disintegration of audience discussion into a heated debate about tools and technology.

    Observing that rapid switch away from very “soft” questions about culture to what tools will and will not support aspects of DevOps was enlightening and frightening at the same time. It was very apparent to me that this major shift in how information systems organizations were structured and managed was a throwaway in terms of organizational change. The Nike phrase “Just Do It” comes to mind.

    The issues were obvious to me. In no way had most organizations viewed the combination of three separate, virtually autonomous departments (one of which is adjacent to customers) each with a different culture, as an organizational change. And, by the way, a change to be accomplished while maintaining a 24-hour idea-to-delivery cycle, with each new idea coming within seconds of the last. The departments in question were not filled to the brim with sales and marketing extroverts. Rather, they were groups and individuals who were used to looking at the problem in front of them and solving it without having to resort to communicating with others. Like its close relative Agile, DevOps relies heavily on communication and conversation to be successful.

    The situation is a wake-up call to technology leaders and managers. If you are working in an organization that has embraced DevOps with the goal of providing customers with what they want almost immediately, check in with all of your technology teams. They may be floundering in what they did not perceive as an organizational change. If you are a technologist trying to implement DevOps successfully and suspect that there are underlying organizational issues, there are several things you can do to be effective and help your organization realize a successful implementation. Start the conversations that need to happen to have optimized DevOps, learn some of the principles of collaboration and consensus, and draw upon the expertise of outside resources who can facilitate you and your teams through the organizational complexities of a transition—“a philosophy, a cultural shift that merges operations with development and demands a linked toolchain of technologies to facilitate collaborative change.”

    This article was co-authored by Kevin Fisher

    — Callie Gargiulo McDowell

  • DevOps Assessment: Assess, Analyze, Implement, Achieve!

    DevOps Assessment: Assess, Analyze, Implement, Achieve!

    DevOps has taken hold in IT. A growing number of organizations are adopting DevOps to deliver applications and services at higher speed; evolve and improve products at a faster pace than in a traditional software development and infrastructure management environment; and better serve their customers. After realizing the benefits of development and operations teams working together instead of in siloed environments, organizations are fast embracing the idea of DevOps.

    To move forward in the DevOps journey, companies first should outline, identify and map the areas where they need improvement. Having a clear idea of maturity of your current IT infrastructure will help you greatly in that process.

    What is a DevOps Assessment?

    Adopting DevOps practices is not a one-day process. And, if it’s not done correctly, companies can do more harm than benefit. So, it is necessary for any organization to know whether the practices they are following are in line with the DevOps initiative. A DevOps assessment is nothing but a set of questions that personnel from different organizational areas can answer. Based on the analysis of the answers, the organization can see whether it is moving in the right direction. DevOps assessment helps outline current maturity and identify a road map of improvement areas.

    Why go for a DevOps Assessment?

    An organization with continuously changing IT and performance needs might be thinking of going for—or may have already started—a DevOps initiative. It’s important to ask the following questions:

    • Do I really need DevOps?
    • Is my infrastructure flexible enough for DevOps?
    • What value is DevOps going to add to my business?
    • Are my DevOps strategies right?

    If yes, then the DevOps assessment is totally built for you.

    What Are the Typical Questions in a DevOps Assessment?

    A  DevOps assessment comprises of three stages: Dev and Test, Release and Deploy, and Manage and Monitor—all of which are part of any product development cycle. The assessment includes questions mostly about production test cases and environment, test cases and test data, the level of automation, complexity, visibility, proficiency in the dev-test-release-deploy-manage processes, etc.

    What Can You Achieve with a DevOps Assessment?

    Once a DevOps assessment has been completed, organizations can get a clear idea of functional areas which are underperforming, performing as expected or overperforming.

    A typical DevOps assessment report provides an evaluation of an organization’s current DevOps ability and recommendations for improvements based on the responses. Not only that, the organization also can get an idea of where it is compared to its competition, the expertise it needs to cement its position, the most valuable talent assets in the organization and the talent pool the organization needs to recruit. A DevOps assessment can help the organization align its software development and IT operations processes with business goals, and ship products faster without compromising with quality and with more reliability because of increased agility and ability to adapt to changes.

    In short, it will help:

    • Technical teams to baseline their performance and understand strengths as well as areas of improvement
    • Recruitment team to develop capabilities and recruit related talent
    • Management team to target the investment areas
    • Operations team to understand the most critical operations

    While DevOps has proven its accelerative impacts on development processes and timelines and quality assurance, it also imposes demands that every organization must be ready to address. DevOps Assessment is a real necessity to get an idea of where you are and where you can be on your DevOps journey.

    About the Author / Chaitanya Jawale

    Chaitanya Jawale is founder and CEO of Opcito Technologies, a leader in microservice-based product engineering and automation. Chaitanya comes with strong background in product engineering, datacenter automation, DevOps and multi-cloud orchestration and management.

  • Overcoming the People, Culture Barriers to DevOps Adoption

    Overcoming the People, Culture Barriers to DevOps Adoption

    The fact you’re reading this article on devopsy.kinsta.cloud suggests you’re already a DevOps fan. Or maybe you’re visiting this site because you’re considering moving to DevOps in your organization, or you’ve been told you must move to DevOps and are figuring out how on earth to do it.

    Whatever your view on DevOps, let’s get my position clear from the outset: I am a big believer in the power of DevOps to deliver continual innovation to an organization. I advocate DevOps in every project I do because I believe those organizations that innovate and change the fastest become the leaders in their sector, and since almost every business innovation relies on a technology innovation first (“every company is becoming a technology company,” after all), DevOps is the best way for an organization to adapt to, and benefit from, new technologies and gain a lead in the market.

    However, as anyone who has managed the transition from waterfall to DevOps will know—or, in fact, anyone who has overseen any change management project will know—the transition is rarely a smooth one. So, what is behind this reluctance to innovate and work in new ways?

    First, the Technical Arguments

    At some point, most organizations have been burned due to a lack of quality control in technology, whether a security breach, bugs or implementations/changes that went horribly wrong. We all know stories like these. They can have an immediate and catastrophic effect on the organization’s ability to do business. Therefore, there has been a tendency to inhibit change in favor of “stability” and known entities, and to adopt a “Better the devil you know,” strategy.

    DevOps has rocked this view of the world, and teams are reticent to move away from tried and tested approaches and processes because they are held responsible for operational stability. In addition, those people in a quality-control role believe their very purpose and job is under threat. There is also a view that DevOps is system- or application-centric, and can introduce risk to an interconnected IT estate.

    While these are all valid concerns, it is worth bearing in mind they are all technical arguments against DevOps, and they have all been countered before. Implemented correctly, DevOps does not jeopardize stability or undermine quality (in fact, many would argue it does the exact opposite), and it does not undermine a person’s role in development or operations, but rather liberates them from their silos.

    Culture is the Real Reason

    From my experience, innovation of any kind cannot be held back by technicalities alone. While the technical arguments are certainly valid, in most instances, the reluctance to adopt DevOps comes from something much more basic: the organizational culture borne from natural human behavior. Most people are simply risk-averse and resistant to change, so the resistance to DevOps is just a manifestation of human nature.

    The only way for DevOps to succeed is to change the organizational culture to be more open to change and to adopt an “innovation mindset.” The change must also encompass the whole organization. If you only bring half of the business with you, the innovators will become frustrated and find ways to circumvent processes and policy, resulting in additional operational risk and shadow IT.

    The influence that senior managers can have in facilitating—or undermining—the move to an innovation mindset must also be factored in. It is common for senior management to inadvertently foster a hero culture, where those individuals who get things back on track after a catastrophic event are rewarded, yet the well-structured and “stable” DevOps deployments are not given the same weight or focus. Again, it is human nature to be drawn to the dramatic event than the non-event. But you must ask yourself: As exciting as firefighting is, is it a sustainable way to run a business?

    Instilling a new mindset into a business is the same as any other transformation project. It requires you to tackle the four elements of process, organization, technology and information to bring about meaningful and sustainable change. To bring DevOps into your organization you must:

    • Align operational teams with development teams, embedding where possible for early involvement of Ops.
    • Ensure that operational/non-functional requirements have the same weight and priority as functional requirements—no user story is complete without a stable and secure operational environment.
    • Automate where possible to reduce human error and increase the speed of delivery.
    • Improve knowledge management to reduce “hero culture” or bottlenecks where knowledge is concentrated across a few people or one team. Never make exceptions for “heroes”; you need their support more than anyone else because they hold the biggest sway over the rest of the team.
    • Have accurate and comprehensive configuration information. Having a good understanding of the IT estate (including interconnectivity) can help move an organization from a one-size-fits-all governance model to a tailored risk assessment approach through better understanding of the impact of changes.

    DevOps often fails when people can revert to their default behavior. Only by actively identifying and supporting a project in a DevOps manner (considering process, organization, technology and information as previously explained) will you be able to change to a new “business-as-usual” innovation mindset and behavior. But this needs strong sponsorship, guidance and patience.

    DevOps must become the culture of the organization, driven from the top as well as the engineering teams, and people need to understand the implications for their role and responsibilities. CEOs and leaders need to actively support and drive the change, while providing the necessary working environments (tools and training) for those people who will be held accountable for operational stability. It is no good investing in technology and training for engineering to innovate if your ITSM functions are not brought along with the change, for example. But if you bring everyone with you, and address all concerns along the way, you will soon be reaping the rewards of the DevOps approach.

    About the Author / Romy Hughes

    Romy Hughes is director at Brightman. Romy is a business change specialist with expertise in service integration and management (SIAM) for managed services, business transformation and IT service management (ITSM and ITIL). Connect with her on LinkedIn.

  • DevOps Chat: Maslow’s Hierarchy of Needs & DevOps with Omed Habib

    DevOps Chat: Maslow’s Hierarchy of Needs & DevOps with Omed Habib

    OK, I admit it. Thinking of Maslow’s Hierarchy of Needs and DevOps doesn’t seem like an obvious connection. But Omed Habib of AppDynamics gives us the connection of how Maslow’s theory applies to developers and DevOps people. Because after all, they are people too, right? Right?

    Anyway, this is a great conversation that I think you will enjoy. As usual the streaming audio of our conversation is below and the text is below that. Enjoy!

    Alan Shimel: One, two, three. Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. Today’s guest on DevOps Chat is Omed Habib from AppDynamics. Omed, welcome to DevOps Chat.

    Omed Habib: Thank you, Alan. Pleasure to be here.

    Shimel: Thank you. So, Omed, I would imagine most of our audience is already very familiar, at least pretty familiar, with AppDynamics. You guys have sort of become just a huge success in the APM market, though some may call what you guys do not exactly “APM”—I’m not even sure if AppDynamics calls it “APM” anymore—but, nevertheless, company that’s had tremendous amount of success. What’s your role at AppDynamics?

    Habib: Well, I originally joined AppDynamics as a product manager. My first couple of years, very proudly brought our PHP, Node.js, Python APM agents to market. And, as of a couple years ago, I joined the product marketing team, so I’m now helping lead the strategy behind all of the outbound product responsibilities.

    Shimel: Sure. So, Omed, in simpler times, just three, four years ago, it was easy to put AppDynamics into that sort of APM bucket, if you will, but that’s not necessarily the case anymore, is it?

    Habib: You know, the term “APM” itself, like you said, is starting to put into question. What AppDynamics does, at least in my opinion, is very simple. I think what is becoming—the definitions that are changing right now are the processes within the software environments and where AppDynamics plays a role or, rather, where AppDynamics—sorry, APM as a concept plays a role. Historically, we’ve had divided teams, right—operations are responsible for production monitoring, and so they would have the production-monitoring tools; developers had their siloed environments—they would ship their code—and so they had their decouple tools.

    But what we’re starting to see now is a shift in runtimes becoming far more sophisticated, and the barrier to entry to production is so much lower now that developers and operations—I’m gonna introduce a whole new term; we call it—it’s not new, but I’m just gonna call it “engineering teams,” “application teams,” are now responsible for the entire software development life cycle of the product, so developers are now deploying code; operations folks are now responsible for not just the infrastructure and the production monitoring, but also they’re starting to look at everything from an application perspective, versus an infrastructure perspective.

    The other thing that I’m noticing, Alan, is that we’re starting to see far more abstraction here of the infrastructure and the deployment models of applications. In other words, teams are no longer responsible for spinning up servers and configuring hardware and configuring the specs behind the infrastructure. All of that’s becoming abstracted, and so it’s causing—again, I’m not gonna call it “dev teams” or “ops teams” because I see these two teams merging, I’m talking, five years, maybe possibly in 10 years, possibly even sooner than that, down the line. I’m just gonna call it “engineering teams.” Engineering teams responsible for the application, the product itself.

    And I see these roles starting to merge. We’re starting to already see _____ the ops responsibilities. You know, Google’s introduced the SRE role, right? The site reliability engineer. And the nature of that role is someone who comes from a developer background, facing the challenges of operations and the idea behind that is to have a developer mindset of “How much of this can you automate using code?” And so they’re trying to solve—again, it goes back to the abstraction idea, right? Everything becoming abstracted. So what they’re essentially trying to do is automate as much of the infrastructure as possible so that, end of the day, a developer can do what they do best, which is checking code and work on features and work on the backlog.

    What we’re seeing today, right now, is the crossroad of development teams starting to take a step back and realize that, “Hey, what the heck is going on here? We have this giant backlog full of features and we’re doing nothing but putting out fires all day long. We have bugs; we have performance issues; we have database issues; infrastructure issues.” Right? So if you were to look at it—[chuckles] it’s kind of funny. I get very Maslowian here, but if you look at Maslow’s Hierarchy of Needs, right?

    Shimel: Mm-hmm.

    Habib: I’m getting kind of philosophical here, but I got a point. [Chuckles]

    Shimel: No, no, go ahead.

    Habib: Maslow’s Hierarchy of Needs, essentially, states that everybody, every human with a purpose, goes through this journey, but they have to go through levels, and it starts with the foundational layer, right, into the second layer and a third and fourth layer. But the very top of that pyramid is what they call—what he calls “self-actualization.” And self-actualization is when you, as a human being, as a person, you get to actually do what you were on this planet to do, where you solve for everything else—shelter, security, your social needs, your physiological needs. And so you get to a point where you say, “Well, what is it that I was here to do to begin with?” Right? And so you get to actually work on the things that are larger purpose of you as a person.

    Developers, I’ve noticed, are actually going through a Maslowian hierarchy. The very premise, the very foundational premise, of what they do is their toolset—their development environments or sandbox environments, their pre-production environments—and so what we’re noticing here is that developers are starting to go through their own Maslowian-style pyramid, in that the foundation of the pyramid, essentially, is a development team solving for their proper development environments, sandbox environments, embracing a DevOps culture, ensuring a pragmatic, iterative software-dev life cycle, ensuring for proper infrastructure, making sure that they have the proper monitoring tools in place. And so, as they continue to move forward and advance from one layer to the other, they no longer have bugs in production, they’re no longer solving for bad code being shipped, because they’ve already solved for that. Right? The teams that have not are stuck at the bottom of the pyramid, and the teams that have advanced forward are hitting a point of self-actualization.

    And so, if I were to draw a parallel with Maslow, I’d say that developers—development teams, applications teams—today, have hit a point of self-actualization, which essentially says, “Well, what are you actually here to do?” And what you’re actually here to do, as a development team, is to work on moving the business forward—work on the backlog, work on the features. And what are those features? Those features come from a road map and have been prioritized, from business strategy perspective. So you’re essentially getting your development and engineering teams back in line with what they were there to do to begin with, which is “Now let’s start to move the business forward.”

    From a philosophical perspective, that’s what DevOps was to begin with, right? That’s what developers and operations teams are hired to do to begin with. Unfortunately, because of the lack of sophistication in the tools and the processes, what we’ve seen in the last few decades is that, developers and engineering teams and operations teams, they’ve been stuck in this rut on the first foundation of that pyramid or the second level of that pyramid. And it’s change blindness, right, from a psychological perspective. It’s, when something happens, some kind of change happens, so slowly over time, you don’t notice it whatsoever, and so you start—you eventually start seeing these development teams accept. Unfortunately, they’re trying to accept their roles as, “Yeah, I just fix bugs all day long.” Right? “I just put out fires all day long.”

    Shimel: Yeah.

    Habib: [Chuckles]

    Shimel: And you –

    Habib: That’s because you’re stuck at the bottom of that pyramid.

    Shimel: Yeah. And you know what? It’s funny you say that, Omed, because I’ve been in technology, oh, 25 years, and so we used to call it “They’re working in the sausage factory, but they really don’t know how we make sausage.” Right? And this happens. I see it in software’s life cycle and supply chain, where everyone kinda does their job but they don’t realize how their job is part of the larger picture. Right? If someone’s just stuffing meat in the sausage machine, in the back of the sausage machine, but they never see what the sausage looks like when it comes out or what it tastes like, it’s very hard for them to imagine or to empathize with the guy who has to eat the sausage. And, all too often, that happens, especially in software development. I’m sorry to say, but –

    Habib: Yeah, no, you’re absolutely correct.

    Shimel: Yep. So –

    Habib: What’s funny is that not only is the pyramid very similar to how software developers evolve, but Maslow also said that, if you’re stuck at any one of the foundational layers or, for example, if you don’t even have the foundation, that actually goes into the symptoms of what a person experiences. For example, if you don’t have a roof over your head and you’re constantly worried about the elements, right, the symptoms of that is gonna be anxiety and paranoia and discomfort, right? Development teams—I mean, you can draw the exact same parallel and say, “Well, if you don’t have a proper DevOps environment, then the symptoms of that are gonna be X, Y and Z,” right? Anything that is lower than self-actualization is gonna have symptoms, and those symptoms, obviously, are bugs in production, application issues, the backlog growing ever so bigger without you actually even touching it, technical debt increasing, so on and so forth.

    But it kinda reminds me—when you talk about the guy that works in the sausage factory, it reminds me of the famous story of the three—I might butcher the story, but it’s the three workers that were working on a cathedral. A passerby comes by and asks the first person, “What are you working on?” and he says, “Oh, I’m just—I’m working on this stone and I’m just hacking away at the stone.” And then he goes to the next person and says, “What are you working on?” He goes, “Oh, I’m just working on this wall, and it’s something that’s gonna be used on this home.” And he goes to—and, by the way, all three of them are doing the exact same thing.

    Shimel: Mm-hmm.

    Habib: He goes to the third person. He says, “What are you working on?” And he says, “Can’t you see? I’m working on a cathedral.”

    Shimel: Hmm.

    Habib: So, when you’re at the bottom of that pyramid, you lose sight of what you’re doing to begin with.

    Shimel: Got it.

    Habib: When you’re at the top of the pyramid, a point of self-actualization, right, where you’re supposed to be to begin with, where you’re supposed to be doing what you’re actually supposed to be doing, then you begin to realize the big picture. When you realize the big picture, then, as an engineering team, you are realigned back to the strategy of the business. And self-actualized engineering teams understand not just what they’re working on and how they’re working on it but also why they’re working on it. And with that comes the additional responsibility of, “Well, if you know why you’re working on it, then how do you measure success?” ‘Cause you already measured success at the bottom of the pyramid, for your application, but, if you’re now at the top of the pyramid—and, as a self-actualized engineering team, you’re not just measuring the success of the application, right—performance of the application, the technical performance of it—but you’re also measuring the success of the business performance of your application.

    Shimel: Sure.

    Habib: And that is what we’re starting to see today. A lot more engineering teams who are moving to the top of that pyramid are now getting reintroduced to having a seat at that table of “Hey, I’m not just a software developer. I’m not just an IT cost center. But I’m a partner in the business strategy behind this application.”

    Shimel: Yep. “And I deliver customer satisfaction.” Fantastic. This was a great—great conversation, Omed. Very insightful. Unfortunately, well, we’ve gone way over our time, but we’ll deal with it.

    Habib: [Chuckles]

    Shimel: Omed, we’d love to have you back on at some point, though, ’cause our audience is so developer-centric and ops-centric too, but “tech-centric,” I guess, is a better word, that I’m sure they identify with this, and I’d love to continue this conversation. So perhaps we’ll –

    Habib: Yeah, it was a pleasure chatting with you.

    Shimel: Yeah. We’ll find some time and do it—do more of it. Or maybe you wanna write about it on devopsy.kinsta.cloud. We’ll talk about it offline. Anyway, Omed Habib, AppDynamics, thanks for being this episode’s guest on DevOps Chat, and thank you for everyone listening, and we’ll see you again on another DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud.

    — Alan Shimel