DevOps is not a new term in the IT industry anymore. The birth of DevOps was a decade ago and the reason behind its birth was the need for “connected teams.” Organizations are investing in this buzzword but mostly miss the fundamental element, i.e, people. There are new tools, streamlined processes, a lot is spoken on robotic process automation, artificial intelligence, customer bots, analytics and interestingly we have new designations as well. Everything sounds good, but the question is “have we truly transformed ourselves on the DevOps journey? Are our teams equipped with the changing dynamics – of failing fast, collaboration between distributed teams, shared vision?”
When large enterprise software had to be built, the requirements (mostly called as user stories) were broken down and categorized into components or modules. Remember component-based architecture? Teams were setup to work on these different components or modules, operating in different geographical locations, with multiple tools and still struggling with integration and delays. This was the development side of the story. Later, comes the operational part. Dedicated Ops team-supported applications going live on production. This scenario is prevalent in most organizations today. And there are multiple reasons for continuing such ways of working and not being able to adapt to the DevOps automation culture, few of them are-
- Traditional delivery methods resisting change to agility
- Cultural differences preferring own siloed ways of working
- Complex release plans like working on weekends and manual dependencies
- Two- to three-week delay in setting up environment
- Different teams unable to communicate and understand the product vision and needs
DevOps tools aimed at connected teams who would collaborate and share a common vision, lookout for customer feedback, and enable faster time to market. As this evolution continues, new concepts have come to limelight– continuous delivery, infrastructure as a code, agile deployments, continuous testing, and what not has been added to this list. Tools prove to be the easiest win to adopt and showcase faster time to delivery. Team structures are revisited in some cases, while in some a new team called DevOps methodology team is setup. The expectation is toward quick deliveries, which could be done when processes are simplified and introduced in tools. A big win!! But what about people and teams? Are they a part of this fast route to success? The answer to these questions might be unclear. Developers and testers look out for quick environment setups but they fail to understand and replicate a mirror-like production environment. They rarely involve Ops architect in their discussions who can guide them on the basic environment setup. On the other hand, the Ops experts ensure that the servers are up and running but miss understanding the application behavior running on them. This is the gap observed in teams, hence, various tools and techniques are adopted to bridge this gap.
Thus, the mere adoption of tools makes organizations comfortable in calling themselves as DevOps compliant but the cultural aspect gets suppressed somewhere in this journey. The key focus should be on people, define new goals, derive new metrics, align and mentor teams on agile practices, and set up governance that includes different teams and their respective owners. Such a revolution is needed in every such organization that seeks to be DevOps compliant.
The revolution has begun, some organizations are adopting newer ways of working, upskilling their people, while there are organizations who are still struggling to fill the gap between siloed teams. The irony is that everyone defines DevOps tools as automation empowerment but the fact lies in how well do we empower our teams and our people to work in the new world of agility and responsiveness!!
Do share in your thoughts and experiences on this new charm called “DevOps”