Flux7 DevOps Blog

DevOps Adoption: 7 Lessons for a Successful DevOps Pilot

May 17, 2018 1:38:00 PM Flux7 Labs DevOps, Migration, Developer Tools and Processes, Management Tools and Processes

DevOps Adoption Seven Lessons for a successful pilotFor organizations facing competitive pressures that drive them to DevOps adoption, it is critical that they correctly choose, scope and evangelize a ‘right-sized’ pilot project to start their IT transformation. As sherpas for many organizations who travel this path, at Flux7 we’ve learned many DevOps best practices -- as well as things to avoid along the way. As you look to create a successful DevOps pilot with sustaining impact, please join us as we share seven important lessons learned.

Lesson 1: Start with a Use Case

With palpable excitement, many organizations dive in head first without first having a clear understanding of their starting point. However, to get started, it’s important to take a step back and examine which DevOps project ideas could potentially have a strong business impact. Starting with the use case (rather than an umbrella-sized business motivator) allows you to choose a pilot that will meet a predefined business need.

For example, you can start by either saying “we need better security” or by saying “here is an application that needs to be launched with PCI compliance in record time.” The latter is a better pilot project because there is a defined goal and a clear business-level motivator. If you have multiple such choices in your backlog, pick the one that has the largest business impact associated with it, e.g., accelerating a new product/feature launch is often more valuable than accelerating release frequency of an already running product undergoing refinement. The former will have more visible impact, and very importantly, will require less effort because there will be less legacy to deal with. Spending some time on picking the right pilot is thus critical.

Lesson 2: Think Cross-Departmental

The most successful DevOps pilots are staffed by cross-departmental teams. Consider creating a small team of hand-picked individuals that span Development, Operations and Security. In our experience, cross-functional DevOps teams are more effective because they are likely to realize the risks of a poor implementation sooner and importantly do not declare success as easily. For example, an AWS pilot team built of network engineers might focus exclusively on VPCs, VPN tunnels and DirectConnect, excluding important development components, resulting in an incomplete solution that will ultimately not add business value. For example, we have worked with customers who choose VPC deployment and integration as a pilot. This is a poor choice because even the best VPC design does not have realizable business value until an app is deployed.

Learning agile methodology is also important for this team. With advance agile training, the team looks more like software development than IT operations, moving swiftly and powerfully through project sprints, and any obstacles they might encounter along the way. Last, choosing a team that feels empowered and is sold on the new approach helps ensure that the team won’t revert to ‘business as usual’.

Lesson 3: To Create Impact, Start Small

While you likely have many grand visions of how your company will ultimately benefit from DevOps adoption, don’t look to your pilot project to boil the ocean. To create a successful pilot, the first steps should be small and impactful. By impactful, we mean a project that creates specific business value and as a result gets the attention you want this first project to have.

For example, while staff may be eager to dive in and get their hands dirty building a complete, scalable, landing zone, it is more important to do an minimum-viable landing zone and launch the first app. Small projects create quick wins that lead to the buildup of internal momentum. Large, complex or unwieldy pilots face more resistance, can cause the initiative to lose momentum, and/or can fail under their own weight. If a pilot takes too long to execute, it risks being forgotten about and the business will return to the status quo.

Lesson 4: Ten Weeks is a Good Rule of Thumb

To help identify a set of DevOps project ideas, think about what can be attainable in a short period of time. That is, which project offers the opportunity to present results in the near-term, ideally between 8 to 12 weeks. Note that while DevOps has many elements, it is not necessary to implement all of them in the pilot. In fact, our experience is that it is best not to implement more than three or four concepts in a pilot.

Setting the project scope to small -- or if necessary with clearly defined milestones that are no more than a few weeks apart -- avoids management declaring the project a failure before it concludes. Targeting early, demonstrable success is imperative.

Lesson 5: Blueprint the Plan

Following the selection of your pilot, you’ll want to blueprint the desired state out of which you should create a detailed backlog for execution. With a blueprint and sprint plan in hand, teams can begin building their pilot DevOps architecture. At Flux7 we have built a DevOps model, or Enterprise DevOps Framework (EDF), which calls out the technology that should be included in every DevOps blueprint. Think of it as building an execution engine to operationalize your pilot -- and future infrastructure.

Lesson 6: Declare Success When You Achieve It

At Flux7, we see organizations make the wrong conclusion from their pilot project in several directions:

  1. They incorrectly determine that the new technology is unable to serve their needs. This determination leads to the project being labeled a failure even though it is often-times due to a perceived need that may not be a true need at all. This conclusion is often brought about by a lack of knowledge or skills and can be solved with tech-savvy leadership, consultants with expert knowledge, and/or improved coaching.

  2. The project is met with a lukewarm reception. In this case, we often see that the project works but that it is perceived to be too similar to old technology, only meets a subset of the goals, or only helps a subset of the stakeholders. For example, InfoSec may give a milquetoast response to an application migration that has glaring security issues. While this can be mitigated by ensuring security is part of the pilot team, it can also be avoided through the right coaching and resources, including consultants who can provide guidance on good execution.

  3. Declaring success too early. This often happens (especially in smaller, more nimble organizations) when all the goals of the pilot are hit. Excited by the change they see, these organizations give the go-ahead for future projects too early. For example, an enthusiastic engineer demos for excited leadership a successfully containerized application. However, the excitement overruns the fact that this in and of itself is not enough to prove project success and will result in failures and greater expense down the road.

Real success happens when balance is achieved across necessary disciplines. While rare, it often comes when an outside, experienced consultant shepherds the process. Without it, many organizations take several runs at pilot projects before they make this realization and find true success.

Lesson 7: Evangelize Success

Once success has been achieved, it’s important to evangelize it. Consider turning your pilot DevOps team into a Center of Excellence that shares with relevant technology teams key concepts and skills needed for future projects and ongoing success. One DevOps best practice that many successful organizations implement is to hold a CoE Summit where they evangelize the importance of and make sure to pass along the important skills needed to support the new DevOps infrastructure, applications and culture.

The risk organizations run is that success is briefly celebrated and teams return to tactical work. However, with an active CoE, there is a small team in charge of capitalizing on success and actively planning next steps. This team may choose to engage with consultants at this stage to help scale the operation, providing needed bandwidth and additional skills. For continued momentum, it’s important that the CoE evangelize up to leadership and across to peers to ensure that the conversation continues at all levels of the organization.

Success of your DevOps pilot is critical to future growth and velocity. By following these lessons learned, you can select and scope a right sized project that will achieve quick business impact and as a result create internal momentum for future wins. Should you be interested in a professional assessment for which DevOps pilot project is right for you, schedule a call today.

And, stay tuned for the rest of our series on motivating DevOps adoption and IT transformation by subscribing to our blog below.

Sign Me Up!

Flux7 Labs

Written by Flux7 Labs

Flux7 is the only Sherpa on the DevOps journey that assesses, designs, and teaches while implementing a holistic solution for its enterprise customers, thus giving its clients the skills needed to manage and expand on the technology moving forward. Not a reseller or an MSP, Flux7 recommendations are 100% focused on customer requirements and creating the most efficient infrastructure possible that automates operations, streamlines and enhances development, and supports specific business goals.

Subscribe to Flux7's Blog

Posts by Topic

see all

Recent Posts