While 59% feel that their businesses appreciate their efforts (59%), that still means at least 40% aren’t achieving worthwhile collaboration. “Plus, only 42% fully agree when asked whether IT and the business speak the same language,” the survey’s authors point out. “The software development process can seem abstract and almost incomprehensible to some outside the IT or engineering departments. This leads to a mutual lack of understanding and frustration on both sides.” The lack of information or understanding also extends to relationships between developers and customers. The survey shows that developer teams have little insight into how customers use the software they create. The majority of respondents (70%) turn to support tickets as their chief metric. “While this metric is easily accessible, it does not always produce a lot of useful insight,” the survey’s authors report. In addition, two-thirds also track the monthly number of active users, “a number with no real relationship to the software delivered and its value to customers.” Fewer than half employ other metrics such as feature adoption, churn, return on investment or net promoter score for insight into customer satisfaction. 5% of respondents don’t measure any customer metrics at all. “Development teams, in general, have hardly any insight into how customers benefit from their work, and few are able to discuss these benefits with the business,” the authors report. “Having such insights ready at hand would improve collaboration between IT and the business. The more customer value metrics a development team tracks, the more positive that team views their working relationship with the business. Without knowing whether the intended value for the customer is being achieved or not, development teams are effectively flying blind.” The LeanIX authors calculate that 53% work on a team with a ’low level’ of DevOps based on maturity factors. Still, nearly 60% said that they are flexible in adapting to changing customer needs and have CI/CD pipelines set up. At the same time, less than half of engineers build, ship, or own their code or work on teams based on team topologies, indicating a lack of DevOps maturity. Fewer than 20% of respondents said that their development team was able to choose its own tech stack; 44% said they are partly able to, and 38% they are not able to at all. “Flexibility around choice of tools is a central component of DevOps culture because it enables organizations to react more quickly to changing customer and business needs.” Interestingly, there is a clear correlation between DevOps maturity and organization size: The bigger the organization, the lower the maturity level of the development team. “In other words, teams working in larger organizations have adopted fewer DevOps working methods,” according to the authors. ‘That organizations with more than 10,000 employers have a harder time when it comes to DevOps implementation stems from the fact that the DevOps concept itself requires a fundamental cultural shift," they surmise. “Large, complex organizations need more time than small, agile organizations to bring about this shift and navigate the changes it involves. Additionally, large organizations often depend on numerous legacy systems whose role in the future of the organization is not always clear.” The survey also shows that reducing manual efforts through automation sits at the top of the list of obstacles to DevOps initiatives. “A majority also find breaking down silos (which signal the absence of a common knowledge base) and focusing on tasks (due to context switching) to be somewhat challenging.” “A little bit of DevOps is not enough,” the survey’s authors conclude. “Agile working methods and DevOps initiatives have decisively changed software development. This does not mean, however, that DevOps culture is already a living reality in most organizations. It is far from the case that companies have fully implemented the working methods associated with DevOps. For this reason, it is not surprising that teams regularly encounter challenges in their daily work that get in the way of effective software development.”
