Cloud

Rethinking big business organisation with DevOps

21 February 2019

Rethinking big business organisation with DevOps

For the leaders of digital innovation Amazon, Facebook and Netflix, what lies at the heart of their success? One word: DevOps. Away from the clichés of start-up operating methods, DevOps has raised these new models amongst the ranks of the big multinationals and continues to foster their competitivity whilst they grapple with the logistic and managerial challenges slowing down their competitors.

Well-established big businesses would be wrong to tarry behind their digital native equivalents. DevOps is so well adapted to complex organisations that it was designed to avoid some of their regular malfunctions. It can revolutionise the production of digital solutions for any company. Beyond IT projects, DevOps offers a new way of collective thinking. By adapting DevOps to big businesses, it opens them up to whole new perspectives for staying competitive, going far beyond the realm of IT tools.

The principles and methods of DevOps are there for any digital professional to take advantage of. The real challenge consists in effecting changes at employee level, playing down the restrictions associated with deploying such changes. Bringing about changes as quickly as possible to further develop or correct a situation has become a must. Organisations going through the transformation process will have to bring forth innovative solutions so as to adapt the new operating principles to their existing weaknesses.

1. Standardise production to refocus on employees

Native DevOps companies will benefit from their position as “second movers”. DevOps aims to either avoid or resolve the traditional conflicts that tend to arise when building software. It automates production so that more resources can be given to the company’s specific issues relating to employees.

First of all, it tackles the persistent issue of the siloed working between development teams (the “Dev” part) and software engineers (“Ops”, for operations). These are too often trapped by a conflict of interest that seems unresolvable. Developers are looking to reduce the time to market whereas operations have to guarantee the stability of the IS. Operations control the evolution of the applications and blame any production incidents on bad coding. As for the developers, they blame operations for any production hold-ups.

As its name indicates, DevOps helps to overcome this opposition. It aligns the short-term targets of both teams over a long-term objective: creating value for the company. To achieve this, it sets into motion 3 principles of action:

  • Building a culture of collaboration between developers, operations, and all IT project stakeholders with the support of shared tools. Working closely together in this way will reinforce collective performance. For example, operations will report their errors more efficiently as they will have a better understanding of the needs of developers.
  • Accountable and collective governance, shared between developers and operations. Each team is responsible for their product whatever their role in the building stage: you build it, you run it. This interactivity between skillsets will run across the product’s life cycle on account of a horizontal management strategy and dedicated leadership roles. In addition to the Product Owner and the Scrum Master introduced through agile methods, there is also:
  • An Ops Master, who communicates to the Ops teams;A DevOps Squad, which mediates decisions from product development to delivery.

In addition, agile meetings are joined by weekly, 20-minute Run Flash Info meetings, during which developers and operations resolve any Run malfunctions (incidentology, lateness, etc.).

  • Automated software development and production supported by shared toolkits. This happens through a change in perspective: teams will stop thinking in terms of portfolio but rather in terms of the product they are responsible for. The objective is continuous deployment: the application must be able to be sent to production at any time. Coding methods, delivery, tests, and even quality control are standardised and automated. Iterations become more regular, lighter, more in line with customer expectations, and less risky than huge updates. Of course, some might turn out to be defective, but being quick to adapt will help manage failure in a quicker, more pragmatic way.

Without results, it is impossible to understand the cause for failure or to measure how successful the new methodologies have been. Targeted KPIs control how these principles of action will be put into place using 5 performance-based approaches:

  • Product security: risk assessment, intrusion tests, etc.
  • Velocity: time to market
  • Productivity: number of applications in automated deployment, deployment success rate…
  • Quality: requirement coverage ratio, number of incidents…
  • Collaboration: satisfaction surveys.

The DevOps dashboard manages and contributes to this transformation at team level: project teams are collectively accountable for their performances.

2. DevOps: just a fad or here to stay?

In just a few common-sense operating principles, DevOps has declared a revolution in software building. Who would have thought it was so simple to overcome the technical and collaborative hurdles standing in the way of big business agility?

The reality is obviously far more complicated. Several Fortune 500 companies have agreed to heavy investments to automate their software production without achieving the desired results. Others have shown some successes but have been limited to pilot projects without a wider roll-out. An even larger number are said to be disappointed by digital transformation. For these companies, DevOps seems like a new set of doctrines in which they have invested and lost. If agile methods, Lean, or even Kanban have not made them more competitive, then why would DevOps be any different?

The explanation for these failures is as simple as its implications are subtle. Deploying DevOps seems to be limited to a set of poorly adopted buzzwords.

The successes of the “unicorns” such as Google or Netflix stem from their organisational models. They both have a flat organisation, made up of small, multi-skilled and semi-autonomous teams that are responsible for their tasks from A to Z. In other words, they apply the DevOps principles and culture across their operations, as large as they might be. Managers are fully committed to transforming their working methods. But to bear its fruit, it must go hand in hand with transforming the organisation and company culture.

Such is the challenge for long-standing, large companies: they cannot be traditional and agile at the same time. To stay competitive, they need to evolve the culture and organisation that made them successful in the first place. They need to stop seeing themselves as, for instance, “a bank using agile methods” but rather “a tech company in the banking sector”.

3. Collective decisions: the key to transformation at team level

Once the reality of things has sunk in, the main obstacle standing in the way of large businesses and their transformation is the maturity of their company.

Companies which have already managed to make their organisation more agile are already one step ahead of the game. DevOps further develops the vision and techniques of agile methods and is inspired by Lean in its best governance practices and logistic organisation. Creating value for the company – the shared principle for all DevOps teams – goes through the continuous implementation of improvement cycles and the removal of repetitive tasks. A large business having gained experience and flexibility on account of implementing previous changes just needs to stay on course.

Digital transformation is a continuous process. But despite their best efforts, most well-established large businesses often present one or several of the following problems:

  • “Customised” production and management methods for each tool;
  • Inadequate KPI monitoring due to poor information relay, an issue with the definition or relevance of the indicator;
  • Working in rigid silos or sub-silos;
  • And, of course, reluctance to change.

These difficulties require targeted responses depending on each company’s specific situation. However, experts in agile transformation have identified a lever which impacts every company: collective governance. So that transformation goes beyond a simple, informal coming together of colleagues, self-organisation must benefit from decision-making power.  

It is, then, the Core Teams that truly manage the DevOps process within the business. These strategic planning teams, supported by DevOps coaches, are made up of approximately 10 representatives from various different teams within the company and together lead an internal think tank on the transformation of the company model. Their aim is to focus on the following subject areas in particular:

  • The agility deployment strategy and raising colleague awareness;
  • The transformation of governance and existing processes;
  • Identifying the tools required for transformation;
  • Assisting colleagues with the changes.

However, these subjects sometimes differ from the managerial vision. But it is essential for the company’s senior management to take decisions on the Core Team’s conclusions as well as put them into practice. Bottom-up innovation will pave the way for a flatter, more agile organisation.

DevOps is getting big businesses ready the working methods of the 21st century: production automation, horizontal organisations, culture flexibility, collective management, etc. The good news is that big businesses do not have to face this enormous challenge alone. Experts in agile transformation are close at hand and ready to guide them in adapting their organisation and culture.  

Gauthier Deschamps, consulting Director ,has gained various expertise through projects led in customs care and biling System, outsourcing contracts and strategic consulting engagement. He worked for major leader of it companies ( Alcatel , HP, Gartner, TNP, Sopra Steria ) Since 2 years, He is in charge to develop the devops practice for Sopra Steria Consulting. Specialist of the change management , he has especially developped with his team an adapted and innovative approach to support organisation to lead devops transformation
Leave a comment

Your email address will not be published. Required fields are marked *