Nowadays, DevOps is a widely accepted term to increase agility of organizations, and it usually plays a key part in IT transformation programmes for many companies. But many organizations will encounter various challenges in adopting patterns and processes attributed as DevOps. As IT leaders, it is valuable to be aware of these common problems and thereby preemptively, take measures to avoid them. This blog post aims to detail five of the most common problems we find when helping organizations that struggle with successfully becoming more agile through the adoption of DevOps services.
DevOps has over the course of the last 10 years, become a comprehensive framework of culture, methodologies, technologies and practices. As a result of this, there are many definitions of what DevOps means. Typically, it is expected that by using DevOps an organization can build Agile-based core values, follow best principles and practices, leverage cutting-edge technologies and automate build and testing pipelines to deliver valuable products to the customers continuously and in an iterative manner. To get started, organizations should create one or several cross-functional DevOps teams as starting points to try their DevOps ideas. Teams decide tools, technology stacks, scripted processes, agile development process etc.
In doing this, the following typical problems can then be observed:
1. Doing DevOps for the sake of DevOps
After DevOps has been adopted successfully by many tech-giants like Google, Facebook, Netflix and etc., this passion has truly affected many companies. Being fashionable is part of the goal. Therefore, traditional organizations start internal transformation as fast as they wish to. Typically, the IT groups begin with well-known CI/CD tools and a Scrum team setup, taking notes from DevOps best practices. A lot of DevOps related buzzwords such as “Fail-fast”, “Test Automation”, “Staging” are introduced and heavily used. Sprints, Iterations and retrospectives are being used to organize the work and the teams are very happy to build more tools. After some months however, many team leaders will start to ask themselves: what are they trying to achieve? Everyone is busy, but not much is getting done! In making the development cycle more flexible, the end-goal slips further and further away.
One reason why an organization should adopt a DevOps model is to deliver the value of products to the customer faster and being adaptable to ensure the development roadmap can adapt to the change of what constitutes “value”. This is why software development with a DevOps mindset advocates products over projects, the goal can not be to finish the project, but to continuously evolve a product based on an ever-changing idea of what is value according to the end-customer.
The goal and vision shall be created at the very beginning, but also reviewed regularly to ensure transformational activities are still on the track.
One challenge of DevOps adoption often comes from organizational units divided up in teams working in silos. When a transformational initiative starts, an enterprise wide consensus about breaking silos is normally not yet made. As few business stakeholders are informed or involved, the project core team can progress quickly. Then, after successful experimentation, organizations decide to kick off the journey and scale out the transformation. Soon they will see the progress slow down, because many unanticipated and disconcerting dependencies show up.
In fact, this is just due to the conflict with the existing delivery model within the organizations. The traditional IT always serves customers by using predefined processes in application deployment, IT security, data compliance and cost control. Fast delivery is not the first priority. Therefore, adopting DevOps ultimately means vetoing this model. Companies struggle with “DepOps” to resolve numberless dependencies.
To solve such issues, a wider range of commitment can play a key role. If business stakeholders are involved early in the teams, teams can make sure they track with value. The transformation is not just about technology but beyond IT organization. It is exceedingly helpful if the senior management can offer strong support to break chains.
Furthermore, initiating DevOps teams from scratch and building a new delivery model is always encouraged. Teams should be free from the burden of countless processes to ensure they can productively deliver the value. By collecting good DevOps experience, companies can establish such a new model which focuses on delivering values in a changing environment.
3. Always busy but few deliverables
When adopting DevOps methodologies, DevOps teams are built with agile processes like Scrum or Kanban. For the team members, they strictly follow agile events, join daily stand-up, prepare planning meetings, design continuous integration pipelines etc. The members attend the technical discussions and actively exchange their ideas and thoughts about the tools and concepts. However, if you take a deeper look at their team sprint outcome, you will see few demonstrable features or deliverable artefacts. Some tasks stay in the backlog for several sprints. And yet, they still commit new tasks for the upcoming sprint.
The root cause for such issues could vary. Team sizing is an important reason. The goal of DevOps is not just introducing an agile process but rather weaving a delivery team as a whole to behave tactically. Some DevOps teams are built larger than needed. Each sprint event would take longer to finish. Even daily stand-up is painful to the members. In such a team, debates happen more often than working. Like Jeff Bezos already instituted the rule: every internal team should be small enough that it can be fed with two pizzas. Smaller sized teams can produce features more effectively.
4. Too many wheels
To many traditional IT organisations, planning and implementing a comprehensive DevOps model within an IT transformation program is an attractive option. We can see organizations hire skilled developers and add some operations staff to build new DevOps teams. For the new DevOps teams, using new tools is the immediate first step. We can see the teams spend sprints rewriting code, re-building components or re-inventing wheels. As each team will focus on different business domains, apply architecture patterns, establish different technology stacks, they tend to have different toolchains with different automated processes to ensure their work.
Spending quite a bit of time on assessing technologies and maintaining these tools shall not be underestimated as cost is exponentially growing with the number of teams. For large organizations, this would become a visible problem if numberless tools are introduced with unknown security risks. Governance would be quite expensive and, on the other hand, it is difficult to decide which tools shall be eliminated in time.
Standardization of the DevOps tools and processes is the solution to alleviate this problem. Introducing standardized environments with pre-configured tools shall be the job for the governance team. Furthermore, building an internal platform is a better choice for large organizations to allow knowledge sharing, tool reuse, risk mitigation etc.
5. High expectations, low performance
DevOps is seen as a turbo boosted engine for many organizations, to accelerate delivery and bring more business value. Additionally, they expect that leveraging DevOps can lower the costs thanks to automation and open source. However, the real deliverables could get adrift with the management expectations. Customers could be disappointed about the delivery quality, number of features etc.
In reality, DevOps is not a one-time job, but an iterative approach which requires organizations to define clear but smaller goals continuously. Sometimes organizations have to conduct more changes or explore differently to identify the next step. Important is that each iteration shall deliver agreed value to the customers.
Secondly, to align customers’ expectations with performance, quantifiable metrics shall be defined prior to delivery. Typically we can have metrics from the following areas, e.g.
- Business: number of users, number of products
- Delivery: lead time, effective deployment frequency
- Change management: change fail percentage, mean time to recovery (MTTR)
With such metrics, organizations can ensure more transparent delivery covering value, cost and risk, to create more realistic business expectations.
Finally, it is also recommended to develop a maturity model for DevOps. The maturity model can assess the organizational DevOps state and guide further improvement activities.
Adopting DevOps is a challenging topic for many companies. There are other known issues or problems that are not described here. For the organizations, selecting appropriate products, breaking silos, standardizing processes and tools, managing expectations and leveraging incremental methods can solidify fundamentals and further enable scaled DevOps adoption to achieve agility for business.
If you are looking for help with your transformation efforts, get in touch with our Cloud Application Development team.