DevOps - An infinite mindset

With the digitization megatrend now affecting every industry, DevOps plays a crucial role in the  implementation of software and services. Software is now an inseparable part of business, so agile development processes and technologies make a big difference when you are facing unforeseen and sudden changes in your day-to-day business operations.   

From my perspective, there are huge differences between DevOps versus “normal” project-oriented agile software development. In terms of Sinek’s infinite mindset, DevOps is the only way to develop software. In this post I will explain why.

What is a software project?

A software project has a start, but they very seldom have an end, even if there’s an agreement to limit the scope. Your software and end-user needs don’t disappear when your project finishes. To succeed even partly, one of the waterfall end-points has to give: delivery date, scope, or budget. In my experience, this is not a good way to develop software because you cannot constrain and scope something that has not been realized yet.  

W.W. Royce states in his infamous “waterfall paper” that pure waterfall is an anti-pattern. And look where we are 50 years later! We’re still working according to the picture on the left, even though we can see the correct iterative, infinite, and never-ending approach described on the following pages. This waterfall development anti-pattern is the most finite way to do software, as described below.

Source: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf 

But what if we add the term “Agile” in front. What does “Agile Software Project” mean? Is this enough? Does it fix the contractual constraints that waterfall brings? Usually, it does. But it is still a project. It has a start and an end, so everything from the delivery point of view is ok. Or is it?

What comes after the deployment when every feature has been delivered? What if some new ideas are thought of and new development iteration needs to start? Do you start a new project from scratch with another finite target? Maybe the people and resources behind the solution have left the project. Usually businesses will continue to demand new features, bug fixes, etc. How do we handle future development with these real-world uncertainties?

Do we rely solely on the competence transfer document? Is that enough or should we just trust self-explanatory code? Where is our “safety net?” Which DevOps automation practices concerning e.g. test and infrastructure need to come into play? If people unfamiliar with the system start developing, how do you make sure that everything will be ok? These situations are very familiar in finite project-driven software development.

Fundamentally, no system will ever be as it was intended at the start. Because of this everyone will always face future changes to their software systems. Innovation, competition (rivalry), internal stakeholders, technical debt, and more importantly customer feedback, all create changing needs for the system. The question is how to manage and deliver these new requirements. 

The only way to be ready for this constant change is to think about development and operations with an infinite mindset and realize that DevOps practices can help you to prepare. 

Two systems to rule them all

Let’s look at this scenario through W. Edwards Deming’s System Thinking “goggles.” Let’s think about the software development process as two different subsystems.

First, we have subsystem 1 (pic. 1). It contains the organization (read: the people) which is used to build the end-customer value with selected processes. Here we also have the tools that are used in your processes to actually build the software. Those tools and infrastructure (i.e. development and Continuous Delivery) need to be as self-service driven as possible in order to get the most agility out of your team.   

Pic 1. Organization and tools and infrastructure

Then we have a subsystem 2 (pic. 2) which is actually the software that we are developing. A critical part of this subsystem is that the platform that we are using to make our software should also be as agile as possible. 

From a technical point of view the platform needs to support rapidly changing needs and it also needs to have good monitoring and agile deployment capabilities in order to drive the operations as efficiently as possible. Usually, the more abstraction on the “as a Service” use cases you have, the better (IaaS < PaaS < SaaS < FaaS), but there is always a constant juggling between platform capabilities and customizable flexibility.       

Pic 2. The system under development and the platform for it

Combined, these two subsystems are your whole system which you use to create your software development value streams (pic. 3). 

Pic. 3  the whole system

In other words, the two subsystems represent your software development and deployment pipeline. They define your release processes, your quality assurance capabilities and, in the end, your Time To Market (TTM). As a result, your DevOps capabilities define your delivery capabilities for the whole system!

When you’re signing a contract with a vendor, or fighting over the internal development budget, do you take these DevOps capability characteristics into account? Studies, such as the State of DevOps report and Adoption of DevOps Practices in the Finnish Software Industry show that how software is actually delivered is a significant cost generator. 

When you take DevOps practices into use the direct and indirect benefits are massive. Direct savings are usually pure OPEX saved on human and technical resources by removing repetitive work. Indirect benefits include better visibility, collaboration, and traceability which leads to better work motivation and productivity.    

The properties of the whole system define your capabilities to deliver software, regardless of your software lifecycle situation. It should not matter whether you are developing completely new software or software under development already at the end of its life. When you have DevOps practices implemented, like Acceptance Test Driven Development (ATDD), the actual importance of the code itself becomes less relevant because you can always modernize your underlying technology safely.    

Basically, what DevOps brings to the table is the capability to continuously adapt to your end-user needs with the certainty that changes will not bring your software operations to a halt. This relates very much to the Zero Day Delivery concept that our CTO Marko wrote about in a blog. 

Infinite mindset in software development = DevOps capabilities

Think about how a newspaper company releases a newspaper every day. In such a company every process and practice is designed so that every morning subscribers have something new to read with their morning coffee. Having mature DevOps capabilities in your two subsystems means that you can quickly adapt your initiatives and features as soon as you notice a change in your end-user value needs and input. Technical representation of these capabilities is your continuous delivery pipeline (pic. 4). It is about building the release machinery from the ground up on top of these CD pipelines.  

 Pic. 4 Continuous Delivery pipeline

This capability should be your organization’s infinite goal. Having an infinite mindset on how to bring new value to end-users makes software changes and operations much easier. Embracing DevOps practices and believing that these practices are the best way to develop software will give you true business agility, regardless of the industry you work in. 

As Simon says in his book, you need to invest in your company’s people as much as you take care of your customers and stockholders. You need to think about your software in the same way and investing in it should be about more than just building features. You need to think about your software with an infinite mindset.

It’s not about developing features quickly with the lowest effort and cost. It is about maintaining an entire development and operation (DevOps) ecosystem that thinks of software vendors as partners that can help you to build these capabilities.

I work at Eficode, because infinite minded software development is what we are all about!