DevOps is no longer a new word in the IT industry; it’s 2020 and nearly every organization either wants or is trying to evolve its culture and methods to these ways of working. However, adopting such revolutionary change is not easy and numerous challenges are faced by both the leaders and the ‘doers’; DevOps is very much a bottom-up AND top-down movement. Here are some common challenges I have observed in my fieldwork:
1. Dysfunctional Culture
Cultures that heavily command and control and bureaucratic can be very demotivating places to work. Where people are punished for raising problems or knowledge and information is hidden will stop people from sharing and collaborating. Where failure is seen to be something to be avoided, people will try and cover up mistakes rather than learn from them and they will be afraid of trying new things. Culture is very hard to define and seems very hard to change. It’s the values and behaviors of the people in an organization and needs to be addressed at this human level; it requires we talk about emotions and feelings, not just bits and bytes.
2. Resistance to Change
Not many people like to change their way of working; they have become used to their method of doing things and are frequently unwilling to adjust their usual routine or processes. Many people prefer working in silos and might not want to communicate with others and so DevOps leaders frequently face resistance in the transformation process. Some neuroscientists, like Britt Andreatta, believe that humans are fundamentally wired to resist change for evolutionary reasons.
Here’s an example of where a change agent or an organization may experience resistance: a tester that has traditionally performed manual testing may be asked to automate the test scenario or steps in a continuous integration pipeline. They might resist changing their style of working because they need to learn how to automate their previous manual test scenarios and feel it’s beyond their capability. Another example is a QA manager who has been used to having a large team of testers to oversee: they may see that their testers are being distributed across multiple teams as part of an organizational redesign to cross-functional squads, which they may feel threatens their status as a leader and manager.
3. Lack of Clarity of Vision
Many organizations want the improvements that DevOps promises but often insufficient time has been invested in properly planning on how DevOps will be adopted. Leaders may not have explored what DevOps may require in terms of organizational redesign or they may be resistant to this. Organizations frequently leave DevOps leaders and advocates to plan alone without leadership support to nurture and practice the true DevOps culture.
DevOps transformations without proper plans and strategy make it very difficult to accomplish its goals. Lack of vision makes it challenging for DevOps leaders to create a clear-cut plan when it comes to deciding on estimation, roadmaps, and deliverables. And it also makes it very hard to communicate and share the vision across the wider organization when it lacks clarity.
Sometimes DevOps change agents have a proper plan and strategy for DevOps adoption that they have proposed to our management or C-suite, but if these leaders are not openly supporting and evangelizing the execution plan for DevOps implementation it can stymie the DevOps adoption processes.
4. Teams Do Not Collaborate
The main goal in DevOps is to encourage and enable Dev, Ops and other teams to work together thus breaking down barriers between silos. Teams will have their own goals; the development team is focused on change and the IT operations team on stability. Ensuring teams share goals is a fundamental challenge for those leading DevOps adoption.
In addition, when an organization is geographically dispersed, cross-team collaboration can be even more challenging. Whilst DevOps and agile models encourage co-location, this frequently isn’t practical or even possible. Additionally, many organizations outsource work such as testing or IT operations, potentially to significantly different geographical regions exacerbating the challenge due to time-zone and language complications.
5. Environments are not Standardized
Dealing with multiple applications or service versions within the DevOps environment can result in slower production releases and increase the incidence of bugs and issues in our products. Not having standard environments, or production-like test environments frequently results in incidents as inconsistency leads to unpredictability. Having insufficient application environments can cause additional pain and delays in the release of new value to customers as the teams may be waiting for access to shared test environments for example.
6. Toolsets are in Contention
Development and IT operation teams frequently use different toolsets, but often they are trying to do the same thing, or manage the same piece of work. The challenge is to make sure the right tool is being implemented and that it is aligned with all teams’ goals and the company goals.
Tool selection is a contentious area as people have (often emotional) preferences. Once a tool is chosen, people have learned to use it and it contains significant amounts of data or customized workflows so it’s hard to change a tool — even when it’s identified that there’s a different one that now suits the teams’ and company goals better.
7. Release Management Causes Delays
Traditionally, organizations have released large batches of features using a project-driven approach. These releases are frequently coordinated via a centralized release team using a release calendar where teams book slots (often requiring work at weekends). These releases are often done manually, or with a bunch of scripts, only the release manager understands since they are the ones that built them. All of this means that releases happen infrequently and are at a high risk of having problems that need to be remediated. Teams are often also more focused on getting problems fixed than learning from why the problem happened and ensuring the learning is embedded back in the organization. Much like project teams are frequently disbanded after a go-live date and no post-implementation review inspects whether the effort resulted in the intended outcomes.
8. Manual Testing is Onerous and Time-Consuming
Testing manually is very time-consuming and is frequently performed by separate teams in separate phases creating delays in the flow of value to the customer. Additionally, it’s impossible to do true continuous integration without automating at minimum the unit test — ideally the integration and user acceptance tests will;l be automated too. Automating testing can appear to be a huge and overwhelming task, particularly when there are few resources capable of doing this work in an organization. People frequently perceive testing to be expensive when it requires a good deal of manual work and try to restrict investment — which leads to poor quality and downtime later down the line.
Conclusion
DevOps adoption is a journey that takes significant time. It requires organizations to embrace dynamic and continuous learning. Awareness of these eight key challenges at a very early stage will help anticipate issues and prioritize efforts. In part 2 of this blog series.I’ll explore how to overcome these challenges in Part 2.
Oldest comments (0)