In the Micro Focus blog series on DevOps, Derek Britton looked the bottlenecks of low collaboration, inefficient development and lengthy testing cycles and how they can be overcome with a pragmatic, technological solution. Here, he turns his attention to that most indiscernible of obstacles: corporate culture.
Letting it breathe
In the Micro Focus blog series on DevOps, I looked the bottlenecks of low collaboration, inefficient development and lengthy testing cycles and how a pragmatic technological solution can overcome them. Here my attention turns to that most indiscernible of obstacles: corporate culture.
Introduction
It has been said that 2016 could be the year DevOps came of age. It continues to gain mindshare including large enterprise accounts. Gartner projects a quarter of the Global 2,000 will have adopted DevOps this year, growing by 21%. Reflecting growing popularity, SHARE in March 2016 has its own DevOps track: “DevOps in the Enterprise”. SHARE has also added a DevOps discussion to its “EXECUforum” agenda, entitled “DevOps: Cultural Mindset”. (We are delighted to join luminaries from IBM, Compuware and CA on the panel).
DevOps, as the name suggests, is a technical approach to a necessary business change, namely building new services faster for the business. Put another way, DevOps is a process change, a means to an end. Changing to embrace DevOps affects a number of disparate organizational elements, from IT groups to business, user and customer communities. Clearly, there are important cultural questions in terms of how the organization is ready to embrace DevOps. Culture is widely recognized as being at least as important as strategy. As one report observed, “Changing the culture and mind-set of people is not easy.”
Cultural Barriers to Adoption
Adopting DevOps may flounder for a variety of cultural reasons.
Why are we doing this? While establishing an agile-based methodology in the IT organization makes a lot of sense and, according to history, yielded impressive early results, the parent organization may often be ignorant of the new process. In fact, the business may still expect product roadmap milestones to be planned and met on an annualised basis as part of a traditional regimented plan-build-deliver cycle, unaware of the new dynamic. For IT, breaking down Portfolio and Product plans into Epic and then Iterations is -with a group of trained professionals working together –both viable and valuable. However, ensuring such plans are agreed and acted upon by the consumers of the technology (whether internal users or sales/marketing/customer representatives) is much, much harder, especially when the reason for the change is not clear outside IT. So while like-minded technicians might flock towards DevOps, end-users won’t subscribe to what is probably perceived as extra work for them. They just want results, working apps, not more work. They can’t see the benefit of change.
Moving from big to small. DevOps espouses more rapid, incremental deliveries and a tighter feedback cycle to resolve difficulties and achieve customer satisfaction more quickly. That switch requires the shift from large-scale orchestrated deliveries to more frequent, smaller-scale incremental efforts. The change in dynamics mean there will be greater coordination required by more people on a more regular basis, and a certain level of disentanglement of both application sets and job functions. As one observer put it, successful adoption will require teams to “Embrace the Chaos”. But chaotic it will be, and for larger, more-established, more hierarchical organizations, or those who preside over larger (sometimes referred to as monolithic) systems, that chaos will be most keenly felt.
We don’t have the bandwidth. Restricted infrastructure resources, a problem sometimes faced in large organizations with many parallel work streams is another genuine concern. In some organisations, the change from one model to another might just feel too big. One of the most common bottlenecks is the inability to undertake rapid test cycles as part of a process of continuous integration. With autonomous teams and no restrictions on test environments, as DevOps will need, rapid testing sounds viable. However in a more traditional, regimented IT world, where resources are allocated as part of a planned-for, charged-for system, “just running some tests” is not as simple as that. It might take days, if not longer, to commission a test environment and a very real budget to manage.
Cultural Change – Practicality and Transparency
DevOps is a major upheaval, a major change program. Such change programs need to be clearly outlined, understood, and measurable. So how might DevOps promote wider cultural acceptance?
Get Out There. Failure to involve all stakeholders in a major change program will result in inevitable resistance. Ignorance of why the change is being made will hamper progress. Establishing a clear vision across the organization of why there is a new approach to software deliveries is the fundamental cornerstone of its adoption. To that end, stakeholders need to hear that the reason for the new approach is that the organization is trying to improve the quality of the technology service, and is therefore aiming to deliver more frequently to determine faster feedback, and course-correct. Such a vision is predicated by a top-down C-level sponsorship. After all, the “end game” is new services and customer satisfaction or some other tangible strategic business benefit: DevOps is merely a vehicle to achieve that. Explained this way, especially in the always-on digital age, it is wholly appropriate and acceptable for the supplier to seek to engage more frequently with their users. In a business context in vision, the purpose of DevOps becomes far more tangible and sensible to non-IT stakeholders.
Get Amongst IT. Similarly, for teams responsible for delivering software, from the development, QA and operations functions, previous functional silos and hierarchy no longer apply so readily. But transitioning to a team-oriented structure may take time. Some organizations are borrowing ideas from Agile by establishing functional teams which are temporary for the duration of a major release, or epic, etc. Additionally, many IT organizations are driving internal change with the help of a senior DevOps champion. One organization I know has chosen their new CIO specifically because of their DevOps experience and vision.
Build Bridges. There may appear to be no straightforward resolution to incumbent resource availability (be it related to people, hardware or software), and this is where pragmatism and practicality comes to the fore. Previously accepted practices and platforms may not be as fixed as might first appear. There are a variety of technical solutions available to improving development, testing and efficiency of collaboration for mainframe teams. They can realistically achieve far greater frequency and reach a wider variety of users by exploiting new technical solutions. (One example is Micro Focus’ solution, here).
Conclusion
Larger organizations have every opportunity to embrace DevOps by taking the cultural aspect of change as seriously as the underlying technical and operational approach they are aiming to use. Practical and pragmatic solutions exist to overcome fundamental operational roadblocks; a comprehensive and transparent cultural change program will also be needed to promote widespread adoption. As a recent ComputerWorld headline put it “Culture is Key to DevOps Success”.
Find Micro Focus at booth #525 at SHARE or visit our dedicated DevOps resources if you can’t attend the event in person.
