Understanding Your Current Pain Points

In Chapter 1, The Evolution of Software Delivery, you were introduced to ACME systems and given an insight into how it realized that there were problems with its software delivery process (severely impacting its ability to meet the expectations of its customers and deliver value to them), how it identified and addressed these problems, evolved, and after some hard work, determination, and time, adopted CD and DevOps ways of working to overcome them.

The story based upon a fictional business is pretty simplistic and linear to make it easier for you the reader to follow. Real life is never that simple, but there are a number of key points that were raised during the storytelling that do apply to real-life businesses. The most important of these for any business considering—or actively pursuing—the adoption of CD and/or DevOps is that there has to be a reason for said adoption. CD and DevOps, like any solution, can help you solve a problem—or set of problems—but you need to truly understand and quantify the problem(s) beforehand; otherwise, you'll never know for sure whether the solution has helped.

Just as ACME systems did, you need to take the time and make the effort to, as the well-used agile term states, inspect before you can adapt.

Your first reaction to this may be that you don't have any problems and that everything is working well and everyone involved with your software delivery process is highly effective, engaged, and motivated. If that is indeed true, then one of the following has happened:

• You have achieved software delivery utopia and as such don't need to read any further beyond this point
• You are in denial
• You do not fully understand how efficient and streamlined software delivery can (should) actually be

It's more likely that you have a workable process for delivering software but there are certain areas within the overall process—maybe certain teams or individuals—that slow things down. This is most probably not intentional; maybe there are certain rules and regulations that need to be adhered to, maybe there are certain quality gates that are needed, maybe no one has ever questioned why certain things have to be done in a certain way and everyone carries on regardless, or maybe no one has highlighted how important releasing software actually is.

Something else to take into account is the fact that different people within your organization will see (or not see) a given problem in different ways. Let's go back to ACME for a moment and examine the views of three personas (Stan the manager, Devina the developer, and Oscar the ops guy) in relation to having the software releases wholly controlled by the operations team:

As you can see, different people will have wildly different views depending on what part they play in the overall process. Again, for ease of understanding, this example only features three personas—in reality there will be many more people who will all have their own slightly different viewpoint; consider how a project manager, release manager, tech writer, SecOps, or even a CEO would see this specific scenario.

For the sake of argument, let's assume that you do indeed have some problems releasing your software with ease and want to understand what the root cause is—or most likely the root causes are—so that you can make the overall process more efficient, effective, and streamlined. As stated, before you can adapt you need to inspect—this is the fundamental premise of most agile methodologies. The following chapter will surface some of the approaches and techniques that will help in this.

Throughout this chapter we will explore the following topics:

• How to identify potential issues and problems within your software delivery process
• How to surface them without resorting to the blame-game
• How it can sometimes be tough to be honest and open, but that doing so provides the best results
• How different people within your organization will see the same problem(s) in different ways

Before we start looking into how to inspect, I would like to go off on a slight tangent and talk about a large (normally) gray mammal.