Are you doing DevOps right?

One of the most common mistakes in any DevOps transformation is to see it solely as a technological exercise. When the focus is this narrow it can lead to developing capabilities designed to simply churn out deployments as quickly as possible. Unfortunately, high deployment rate does not automatically mean that you are driving strategy or creating value to the stakeholders. Sometimes, all you’re actually doing is going faster and more efficiently towards nowhere. 

What does it take to make quality software?

How do we know if the software we’re releasing is actually creating value for customers? Design thinking’s Desirability, Feasibility & Viability model provides a very good basis for assessing if you are likely to create value. And the greatest thing about this model is that it’s really simple.

The three typical points of failure are:

• The service does not address the user’s pain points or it is too cumbersome to use which leads to low end-user adaptation – failed desirability
• The service would meet all the needs, but it is not feasible to implement because development effort is unrealistic or it’s not possible to implement process changes - failed feasibility
• The service meets user needs and is implementable, but it would not create enough business value to the organization - failed viability

Rushing forward is not lean enough

The last decade popularized lean product development as an infinite “build – measure – learn” cycle. This approach can lead to a culture where concepts are not validated before being pushed to development. That can lead to the development effort being spent on work from which the only validated learning is that the concept didn’t work. In the worst cases, most of the development effort is spent on waste, the antithesis of what it means to be lean.

Software development is often the bottleneck which defines how quickly the organization can develop its services. It is important to develop capabilities for releasing often, but it is just as important to develop the ways in which the services are conceptualized and the requirements are defined. The good news is you don’t have to implement an organization-wide agile framework to get started. In fact, you can make a huge difference by following these three practices.

Continuous validation has a huge payoff

Firstly, validate before development. Period. Typically, it does not take many fingers to count the number of working days required for validation. The potential for saved effort is months at the feature level, but for concepts it is years.

You will end up saving a lot of wasted effort and pain if you have a culture where validating service concepts before proceeding is an obvious first step. You should also continuously validate features before they end up in development sprints. 

In its simplest form continuous validation can be:

• Viability: Do key stakeholders (including partners and channels) see the feature creating value and is the required change manageable?
• Desirability: What’s the verdict from the prototype’s user testing? Is it delightful, functional and relevant to the users? In other words did we get a “wow” or “huh?”
• Feasibility: Do the critical points in the architecture plan pass technical proof of concept and is the service implementable with reasonable effort? 

How thoroughly you should validate features requires balance and takes a bit of practice. For example, how thoroughly do you need to validate the different variations of user flow for minor features? It will take some experimentation because the validation principles that work for somebody else are not always applicable to you.

Cross-functional ways of working

The easiest way to ensure desirability, viability, and feasibility is to get the design, business and development working together. For example, the best way to start the design of a feature is to get the product owner, designer, and developer in front of a whiteboard or on a remote workshop. 

Everyone working on the service should understand how his/her work connects to what others are doing. Methodologies and tools that make co-working efficient e.g. a design sprint should be used wherever necessary. Co-working not only reduces the amount of waste but also improves the quality of your ideas- because you can get instant feedback on desirability, viability and feasibility. 

Remembering to involve design, business & development in every phase of your project gives you the best chance of success. Getting started on improving your process and how you work is not that hard either (read more about our Digital Product Building Toolkit). 

IT has to go left

Shift left is the practice of preventing problems and improving quality with doing more tasks in the beginning of the value chain. In DevOps that has traditionally meant focusing on the quality of acceptance tests or enabling continuous deployment. These are very important but IT has to go further left. 

It is essential that designers, business and developers work together effectively throughout the value chain and the lifecycle of a requirement. It’s not enough that IT concentrates only on “managing requirements”, it has to join the conceptual exploration and design of features.

When you start to validate continuously and improve cross-functional ways of working on concept exploration, design and development, you are well on the way to creating more value while reducing waste & pain. You are also more able to refocus your design and development efforts, or even pivot the whole roadmap. 

Are you doing DevOps right?

So, are you really doing DevOps right, or are you simply automating processes that are wasteful by design? If you’re still trying to evaluate your DevOps performance here are four indicators that you are heading in a good direction. If you recognize these signs you’re probably in a good place. If not, you probably need the Design Thinking approach. 

• You don’t treat business development, design & development as separate processes but focus on making the whole value chain work.
• Everybody understands how his/her work connects to what others do and co-working is reducing the number of handovers.
• You don’t concentrate only on the validated learnings from “build – measure – learn” but also validate continuously before development.
• Your culture encourages experimentation and the cost of failures is reduced because continuous validation enables you to fail fast.