Horses and carts

DevOps is often seen as a goal, The Next Big Thing, something we 'need'. I see this as putting the cart before the horse. What we actually want is to get features to market as quickly as possible, achieve ROI, respond quickly to market and shape new investment through fast customer feedback. Why? To be competitive, responsive and agile. No change there then.

So what has changed? Technology and delivery culture are always evolving. In DevOps, these have converged as a set of practices, techniques and technology working together to provide a step-change in responding to these business pressures. To be successful, you need to put in place the people change and the enabling technology led by business outcomes.

Technology is the easy(er) part. The ability to virtualise, to automate, to use IaaS or PaaS is widely available for internal data centers or from cloud-based providers.

Which leaves the people part.

Before looking into how we can guide change, here are some widely identified aspects of DevOps culture:

• Learning and innovation, creating space and making it safe-to-fail
• Continuous delivery and continuous improvement
• Ruthless drive for end-to-end efficiency, avoiding local optimisations
• Iterative development and incremental releasing
• Building in end-to-end quality
• Having great information for timely and effective decision making

Some people aspects – like team structures – can be changed (quite) quickly and safely. Some changes – like behaviours driven by beliefs and values – go deeper and take longer. To effect long-term change, we need to set up an environment which encourages the desired behaviours and thinking, while leaving behind less useful baggage. This is a systems-thinking approach.

Power to the people

I believe empowerment sits at the heart of DevOps culture – a DevOps flavour of empowerment that rests on four supporting pillars:

• Putting in place policies and mechanisms for open information and feedback
• Creating autonomy through boundaries defined with clear responsibilities and authority to act
• Replacing old management and team hierarchies with self-managing and self-sufficient teams
• Providing guidance and education, and encouraging learning and innovation

A first step in sharing information and leading from the front is for management to give clear messaging to new teams about their business goals, responsibilities and authority.

We want our team to build their behaviour around their business offering. We need to pivot the team delivery away from IT projects or services to business products or services. This Integrated Service Model is orthogonal to traditional IT delivery.

To increase efficiency and self-sufficiency, we need all the right people in the room. This means building Cross-Functional Teams that represent all areas for delivery, such as product owners (business), testers, BAs, service designers, Devs, Ops, security and UX.

We give the team responsibility and authority to do what's needed to deliver the business value. We also give them responsibility and authority over production, deployment, delivery process and tools, technology and techniques.

New teams will benefit from being exposed to what's possible through training, conferences or visits to successful teams. Providing experience on the ground can go a long way in shepherding a fledgling team around a heap of painful and expensive detours.

Delivery practices are another positive mechanism to build cultural change. Short delivery iterations and team retrospectives with the team that's empowered to make improvements promote learning, smaller, lower-risk changes and valuing incremental delivery to live.

Management support is also very important as existing IT structures need help in understanding and respecting newly formed team's responsibilities and authority to deliver.

With these starting conditions laid out, how does the rest of the journey pan out?

Be careful what you measure

So how do we socially engineer an environment and system over time that encourages the outcome we value and what does it look like?

• Liberate the team to be more ‘devopsy' by breaking old habits/ways of thinking
• Put in place or take advantage of existing feedback, amplifiers and dampeners
• Create attractors which the team want to move towards

Metrics and team measurement are powerful tools and we know what comes with great power… so we need to choose carefully to shape the culture and results we value and discourage negative behaviours. Metrics need to be gathered, shared, made visible and, most importantly, graphed over time. If DevOps is about continuous improvement, being able to easily see trends amplifies the feedback and focuses the team.

Our primary measures come from business outcomes. They are domain specific, e.g. conversion rates, sales/hour or speed of customer issue resolution, followed by more general delivery-oriented ones such as speed of delivery and feature cost.

Quality is next – success of releases, user engagement, defect numbers, defect resolution time and Mean Time To Recover.

Finally come the operational nuts and bolts, highlighting maintainability and technical service delivery, increasing uptime, improving issue resolution AND proactive fault prevention. These also open the door to automation that dynamically responds to operating conditions.

Further examples of behaviour-shaping factors for investigation include:

• Responsibility for deployment promotes Automation and Manageability
• Geek factor promotes towards ‘shiny' tools and technologies (innovation) AND
• Team ownership of business delivery moderates new-technology-overenthusiasm
• Visual team management, information radiators and dashboards act as attractors

It's all about the Business

So how do you get DevOps? You don't! Instead you focus on the business outcomes you want and then build and empower a team around the delivery of those outcomes. You set them up to succeed by making sure they have everyone and everything they need to deliver on those outcomes. Then you add in a dash of culture and direction by building in overt goals and more subtle visible metrics which promote great values and beliefs. But, from beginning to end, you do everything you can to support and protect this new team and their way of working. 

Article by Chris Pollard, principal consultant DevOps at Assurity Consulting