Can you Deliver Software Faster and Decrease Risk at the Same Time?

Many of us have the preconceived idea that speed and accuracy cannot co-exist. We assume that as we increase the speed of tasks and processes, we may be sacrificing precision, quality or security. How many times have we heard the proverb, “slow and steady wins the race?”

Recent innovations in software delivery challenge this thinking.

In fact, when it comes to software delivery, focusing on speed inherently provides more security and less risk.

When you look at the delivery process as a whole — and you start to understand all of the work that has to go into moving software to end users — you’ll understand that you can make software move from concept to cash in both a faster and more reliable method. Not only will the speed help us resolve our issues faster, but the teams that use this method will be empowered to do more from a process and automation perspective.

How is this possible?

By combining the DevOps methodology with a Value Stream Management (VSM) approach, organizations can begin releasing software faster and at the same time increasing the business value of products. In this blog, I’ll explain how to get started with these two solutions and why they are important. You can also watch my recent webinar, “De-Risk Faster Software Delivery with DevOps and Focus on Value Delivery,” to learn more.

Defining DevOps

First, let’s start by defining DevOps. One of my favorite definitions comes from The DevOps Handbook, by Gene Kim:

“DevOps is the emerging professional movement that advocates a collaborative working relationship between development and IT operation resulting in the fast flow of planned work, for example high deploy rates, while simultaneously increasing the reliability, stability, resilience, and security of the production environment.”

I like this definition because the intent of using DevOps is to make sure that we can build some safety and security around moving at speed and delivering our software.

You can’t practice Agile or DevOps in a silo though. In order to start on good footing with either initiative, it’s necessary to set the focus on value being delivered. In other words we must start with the end in mind.

How can you practically focus on value delivered? Let’s take Gene Kim’s definition of DevOps and apply it to a more holistic approach and look at a value stream.

Understanding Value Streams in Software Delivery

Each software value stream is a unique entity or asset to your organization. The reason value streams are relevant in software delivery is because building software is much like a manufacturing line. The key differences are of course when we think about physical manufacturing versus manufacturing software. We can actually see what’s going on in a physical manufacturing plant. It’s very difficult to understand or be able to see progress being made from a software perspective.

So, how do we begin to provide that critical visibility into software assembly? That’s where Value Stream Management (VSM) comes in. Value Stream Management is the discipline of taking assembly practices from Lean manufacturing and making the assembly of software more visible and efficient so that you understand exactly what stories and defects from your backlog are moving through your continuous delivery pipeline.

Here are four significant impediments to businesses successfully practicing Value Stream Management:

1. There is no standard measure of a business value unit at an enterprise.

It’s critical to define business value. I recommend a book by Mark Schwartz called The Art of Business Value. In this book, the author says there’s no discreet unit of business value that you can define once and forever be done with that definition. It’s a hypothesis that can change continuously based on what you’re delivering to your end users and your customers. Of course, it’s important to understand what will best accomplish the organization’s goals or desired outcomes and this decision is unique to each organization. Companies must ask, “what is our business value so that we know how to deliver that value to our end user?”

2. Lack of visibility and traceability throughout the organization.

One of the things that DevOps and Agile, and our scaling Agile frameworks, really try to do is to provide more visibility and traceability organizations in order to see how work is being moved from concept to cash. As mentioned previously, unlike in an auto manufacturing line, organizations cannot necessarily view work or progress throughout the software delivery pipeline and beyond.

3. Most organizations subscribe to high batch size releases, rather than small ones.

There have been substantial studies done by the DevOps Research and Assessment Organization proving that high performers in software delivery are making and delivering small changes as opposed to large ones. This allows organizations to pivot from small changes if they need to.

4. Most organizations fund projects versus products.

When we fund projects versus products, we have what’s called a very high collaboration cost, because from a project perspective, we typically fund a project team to work on said project for a specific time frame. And when that time frame is over and the funding ends, that team may get new funding for a new project that is not be related to the previous project. And so it’s very hard to maintain and support that project that they were working on, which comes down to high collaboration cost.

Moving Faster and in Smaller Batch Sizes is the Best Approach

We emphasize faster delivery because it has been proven to help organizations reduce risk. This for a few reasons:

1. We can collect customer feedback on changes, which help to determine customer value quicker.
2. Making and releasing smaller changes are easier to test, secure, fix or rollback.
3. Less work in progress is proven to decrease risk according to Making Work Visible, by Dominica Degrandis.

By reducing the transactional cost associated with high batch size releases we start to understand this notion of change pooling. We can then start to look at how we will decrease batch size for smaller changes, in smaller pools for a better outcome.

Begin with Value Stream Mapping to Capture all Relevant Information

Practicing DevOps and leveraging Value Stream Management certainly take time to implement and scale, however, the easiest way to get started is by using a Value Stream Map.

Value Stream Mapping helps you see the phases of delivery and the maturity of your software. If helps an organization get a bird’s eye view into what’s automated and what tasks are manual. By more fully understanding how work items impact the process and how the process impacts the overall value stream, you’re well on your way toward Value Stream Management.

In my webinar, “De-Risk Faster Software Delivery with DevOps and Focus on Value Delivery,” I walk through a demonstration of a value map used by a CollabNet VersionOne customer and explain how this exercise helps compliment DevOps and Agile efforts.

The Overall Goal is Confidence

Keep in mind, the primary goal here is increased confidence in the software products your organization is delivering. This means greater confidence for project managers, QA and developers as well as confidence from the executive team in the work being done. Of course, by understanding where business value is at, key stakeholders have increased confidence in the efforts of the organization and teams are able to plan more effectively.

And of course, there’s nothing like having the precious confidence of your customer, which develops from consistently secure and reliable innovations.