Ranger4 DevOps Blog

DevOps Patterns: Part 1 - Organisational

Posted by Helen Beal on Thu, Jan 28, 2016 @ 15:01 pm

Welcome to the first of a three part blog series addressing DevOps Patterns. In the first, I'll tackle patterns we observe from an organisational point of view. At Ranger4, when we study DevOps in the field, we do it from three perspectives:

  1. Organisational
  2. Interactions
  3. Automation

The next two blog posts in the series then will address interaction and then automation patterns. You may recognise this as an evolution of the People > Process > Tools mantra widely recognised when considering the SDLC (Software Development Life Cycle) for many years.

If you're very new to DevOps, you might want to start by reading my previous blog post "What's Different About DevOps" where I consider why the term has gained such currency in today's market.

DevOps is a Grassroots Movement

Most organisations we work with are not DevOps 'unicorns' - they are enterprises with decades of operational, organisational and infrastructure heritage. And there is a common organisational pattern in traditional IT as you can see in the diagram below; two main silos of development and operations and then within each team additional silos - particularly when development are developing in a waterfall manner. Hand-offs are required between each silo and there is often what is referred to as a 'wall of confusion' between the development and operations departments. They have separate reporting lines and are often physically separated too. The CIO may or may not sit on the board - we have seen, along with the increasing strategic importance of IT over the years, a decrease in the number of IT Directors reporting into the FD and an increase in CIOs overall and an increase of them sitting on the board. Separating these teams in this way is the root of the conflict that we have seen, and often means that the teams are given goals and objectives that do not align.

Slide05.jpg

This separation is the root cause of the conflict that causes the pain that makes some people think: "there must be another way?" - dissatisfaction with time to provision environments, developers asking for access to production environments, release weekends and war-rooms are all typical examples of how this confict manifests itself as dysfunction. The people that recognise this pain, can conceive of change and have the appetite to make it happen are often referred to as 'change agents.' Change agents are rare and, in traditional bureaucratic, hierachical organisations, if they do not have authority enacting change can be tough.

Slide05-1.jpg

But often these change agents are deep in the 'doing' part of the organisation - DevOps is very much a grassroots movement. It all started as a Twitter hashtag from Patrick Debois after all. In the picture above, we show the initial DevOps light going on in the testing silo in the development silo - and this is common. Those initial change agents pop up anywhere and often in multiple places in larger enterprises. But, in traditional hierarchical organisations they will need support from those who have power, authority and budget.

Most software development teams are now using Agile methodologies to move to iterative delivery to varying degrees. This drives a common organisational change where smaller development teams are created around a product owner. Having the BAs, devs, DBAs and testers working together on short sprints certainly improves flow and shortens and amplifies feedback loops, but it needs to be managed carefully as some problems can arise:

  1. Best practice on shared skill sets break down as the testers for example no longer talk on a regular basis: encourage a regular meeting to discuss best practice
  2. The product owners often come from the business side and don't fully comprehend the advantages of an iterative development approach resulting in the development happening iteratively, but a release schedule that is inconsistent with this and batched in longer timeframes, fewer release windows: workshop and simulate development scenarios with these people to help them gain a deeper understanding of Agile
  3. Teams choose their own tools leading to fragmentation: Set up a tools advisory that can be consulted on best practice and current organisational investments, skills and resources.

Here's what this organisational set up looks like:

Slide08.jpg

So now the development teams are acting in an Agile manner, they are probably asking the Ops teams to help them more frequently too. And the Ops team are probably wondering how they can support the increased pace of change and build quality and security in early, communicate non-functional requirements and have early sight of new infrastructure requirements coming through. Some organisations build a DevOps team at this point. This is often seen as an antipattern: you have just created another silo, after all, which is what you were trying to move away from. But for some, this does work as an effective migration or transitional strategy as the DevOps word and way spreads.

Slide14.jpg

So Agile and DevOps are driving some organisational change, but does organisational change equal cultural change? Peter Drucker famously said: "Culture eats strategy for breakfast," but what is culture? We start by asking:

"What is your organisation's evolutionary purpose?"

At Ranger4, our evolutionary purpose is to be fanatical about making life on earth fantastic - we use DevOps to improve people's experiences at work - including our own! When we are transforming cultures to be DevOps-like look through a number of lenses, for example:

  • The attitude towards blame
  • How failure is viewed
  • How ideas are received and acted upon

Slide33.jpg

A DevOps cultural transformation requires that organisational change happens that supports:

  • Self-organising teams
  • The promotion of autonomy, mastery and purpose
  • Simplified project and budget management
  • Continual experimentation and learning
  • Decentralised decision making

This is all tough to do - much tougher than building a toolchain. But a toolchain can never be fully optimised without the culture and interactions being ready first.

If you want to change your culture but aren't sure where to start, we recommend you baseline your current state first and build your roadmap. If you want or need help doing this, we've done it many times before and would be very happy to support you on your DevOps journey too. Get in touch. Stay DevOpstastic.

Topics: DevOps Cultures, devops organisational change, DevOps Transformation