DevOps: We all need to shape our common culture

Published: 03 August 2020

Software Engineer Jay Bothra says organisations can’t properly deliver DevOps and Agile unless everyone embraces the cultural changes required.

DevOps is not just about tools, architecture, principles, design, processes and customer experiences – above all it is about the culture you develop across your organisation.

I work in the IT team that supports our investment banking arm, or the 'business' as we refer to it internally. In any organisation the business is one of the most important players in the DevOps process and yet it is often overlooked. Companies try to transform their IT arm with DevOps and Agile methodologies but these new ways of working often don't reach into the business.

So whatever successes DevOps might produce upstream in IT, those benefits are not going to be realised if the mind-set of the business is that IT is delivered via a waterfall model – a linear form of delivery that doesn't allow you to return to a previous phase to make amendments to your product.

It is a common misperception that complex organisations that have been functioning over a long period of time cannot adapt to DevOps and Agile concepts.

This view exists because sometimes organisations that want to transform don't redesign processes. Instead, they just try to put new ones in with the old. This leads to more complexity and prevents people from reaping the benefits of Agile and DevOps culture.

It is tough to change set ways of thinking and working that – let's face it – seem okay because nothing is actually broken. And it can be equally difficult to conceive just how big a transformation you can achieve through a cultural quantum leap.

We overcame these challenges by bringing the business along with us through the change. We tried to sensitise our stakeholders to DevOps ways of working, setting out what we expected from them and what they could expect from us.

We asked the business to be with us at every step of the development process from design, technical as well as UI/UX, to security and deployment into production.

And since each stage is iterative, we had multiple discussions at different stages, getting constant feedback from business users and the clients they face off to.

Product owners in the business who acted as a bridge with IT worked day in and day out with the development teams to prioritise and deliver the business' requirements.

To help us, we agreed a number of steps to make our ways of working more effective:

  1. We design our build and release pipeline to enable us to go fast.
  2. We shape the risk and governance policy around release management to allow certain small intra-day releases in a controlled environment.
  3. We break tasks into the most logically possible small chunks so if we fail, we can quickly respond and fix it. That's not possible with large monthly, quarterly or sometimes even half-yearly releases. It means we can quickly respond to changing business requirements based on shifts in our customers' needs.

We are not just trying to digitise processes but rethink them digitally, removing all the redundant and complex steps.

I envision an organisation where business and IT work as one, sharing the same culture of innovation and focus on delivery. This won't happen immediately, but I am confident that we can get there over time.

Join us