DevOps is a buzzed-about industry term, yet many companies are still trying to figure out how to start the journey to a DevOps transformation. Each organization’s journey will be different, but planning and starting the journey always should include assessing the current state of a company’s software delivery process, quantifying the objectives and plotting the “route.” This begins with a discovery process.

This multipart series will review questions commonly asked during the DevOps discovery process, highlight common answers and provide examples of the resulting guidance. It will show that DevOps is really about optimizing software development and delivery on the planes of process, tools and technology, across multiple stakeholders. Based on experience with a broad cross-section of real-world organizations, the series draws on actual interactions that have led to successful DevOps transformations.

Starting the Discovery

Often, organizations embarking on a DevOps transformation want to “pass go” and get straight to, “Tell us how to do it!”  Some initial statements frequently heard are:

• “We already do and understand [CI, CD, etc.], don’t waste time reviewing that.”
• “We are practicing [Scrum, ITIL, Six Sigma…]; we are just like everyone else, so there is no need for interview or discovery.”
• “We don’t need to discuss [process, culture, or technology], just tell us what tools we need.”

The eagerness to “just go” helps fuel excitement for the transformation; however, it is important to slow the rush to a solution and start with the basics. This includes:

• Setting a baseline definition of practices: Agile, continuous integration, continuous delivery and DevOps are highly talked-about industry practices that often have multiple definitions and are misunderstood, which fosters resistance or ends up being implemented poorly.
• Starting with foundational discovery: Ask the most fundamental questions about the current state of the organization’s delivery process and the objectives of the DevOps transformation. These questions must be asked of each stakeholder, including the Business, Development, Quality Assurance (QA), Change Management and Operations.

Taking these initial steps can be like pulling teeth, yet they spawn insightful discussion, surface key differences in perspective and begin the process of gaining alignment between stakeholders. With alignment among the stakeholders, shared priorities become clear and actionable.

Once stakeholders align on both the current state and objectives and identify shared priorities, only then is it possible to plot a “route” for the DevOps transformation. At this point a mission statement can be formed, which will act as the North Star or guiding light for the journey. For example, a resulting mission statement may be one of the following:

• We will increase the stability of our releases while increasing Developer, QA and Operations productivity and job satisfaction. This will improve our ability to retain employees, satisfy customers and be more competitive.
• We will do this for our existing and new mobile and web products through the use of iterative development, continuous integration, test automation and continuous delivering applications to a production-like environment.
• We, as Development, QA and Operations, will work as one toward this common objective.
• We will transform incrementally, empirically establishing best practices and expertise within teams and sharing them across the organization.

The mission statement may seem like a trivial part of the process, but in reality it is absolutely vital to achieving the cross-fictional buy-in necessary for DevOps. It works to not only outline the strategy, but also gives the teams something to refer back to during the transformation process.

The other key step to starting the transformation, defining DevOps and related terms, will be discussed in the next post.

About the Author/Brian Dawson

Brian is currently a DevOps evangelist and practitioner at CloudBees, where he helps the community and customers in implementation of Agile, CI, CD and DevOps practices. Prior to CloudBees Brian spent 22-plus years as a software professional in multiple domains including QA, Engineering and Management. Most recently he led an Agile Transformation Consulting practice helping organizations small and large implement CI, CD and DevOps.

Prior to CloudBees, Brian worked at CollabNet, VA Software, Sony Computer Entertainment, Sega, Namco and Apple. His roots are as a C/C++ developer, but his primary job has always been gathering and distributing knowledge and using shared solutions to solve unique problems.