As we discussed at length in previous posts in this series, the challenges to a DevOps transformation within any company can be formidable in terms of cultural shift, skillset development, tool acquisition and process changes. Some businesses already have a highly collaborative organizational structure that puts them only a few steps away from full DevOps adoption, whereas others may have a wider gap to traverse.

Regardless of the distance to your DevOps goals, continuing the journey with a DevOps proof-of-concept trial is a wise approach. Selecting your PoC team, best-fit project goals and following best practices for communicating results will be important aspects to achieving a successful PoC in your organization.

Team Composition

The single most important contributor to success of your DevOps PoC is the composition of the team in charge. First and foremost, select team members with requisite technical skills and positive attitudes regarding the benefits of DevOps. Self-selection from development, QA and Ops teams often works out well. Though most PoCs have a technical focus, business analysts may contribute valuable insights also.

Team members who have taken on “fire-fighting” roles or have experience using agile methodologies, metrics, analytics, automation, program management and version control systems will enhance the POC’s chance of success. Designate one team member with clear ownership of the trial who is empowered to make timely decisions.

In Trinimbus’ experience, we find that virtual teams of three to five people who can dedicate at least 50 percent of their time to a trial are most effective, especially if augmented with our consulting and hands-on contributions. Properly scoped, the amount of time to complete the trial is roughly proportional to the organization’s current experience with related methodologies such as Agile, continuous delivery and integration. A typical trial lasts two to four months.

Setting PoC Goals and Metrics

Given the breadth of DevOps, it is realistic to limit a PoC to a single, well-defined area that provides meaningful metrics. Greenfield projects with a stable feature set and a working CI process are often ideal candidates. However, a DevOps PoC can be applied to products in production as well, which might be a service within one application or a standalone app within a larger software suite.

Choosing relevant metrics is critical to measuring PoC results. These might include delivery speed improvements that enhance TTM or measuring the reduction in Ops’ costs due to reduced infrastructure hours expended.

PoC Examples

Naturally, PoCs can be applied to other areas as well:

• End-to-end automation – This PoC identifies, acquires and shakes-out a complete DevOps toolchain.
• Aligning development, testing and operations assets – Such a PoC synchronizes end-to-end software, testing and operational infrastructure and other assets within a single version control system.
• Shared services – The PoC team develops cross-department, IT services that alleviate pain points and friction between development, QA and Ops. This might encompass development of a system empowering developers to allocate, configure and provision their own platforms.

Communicating Results

Regardless of the style or number of PoCs you deploy, always ensure that the results are measurable and shared in detail during and after the trial.

Practice absolute transparency starting with the first discussions about a DevOps PoC in order to calibrate expectations, relieve concerns and to educate. Set up an internal blog dedicated to the PoC and plan frequent stand-up presentations. These should communicate goals, progress and difficulties. Weekly free-pizza lunch gatherings are ideal for this purpose.

Less frequent, but more detailed presentations to business development groups or management are a wise idea also. Plan for a lengthy wrap-up session open to everyone at the end of the trial.

At any presentation before, during and after the PoC, strive for a diverse audience and be open to questions and suggestions because these provide a perfect opportunity for DevOps education and the generation of new ideas.

Working with a Partner

When considering DevOps PoCs, consider the advantages of working with Trinimbus to accelerate the process and keep it on track. Our experience aids you in avoiding common pitfalls, speeds up tool integration and increases engagement with management and planning processes.

The only potential downside to employing a partner as part of your PoC virtual team is the temptation to create a trial that is too large. This may create a drag on quick adoption within the company and over-reliance on the partner, which partially negates the internal learning needed for a full embrace of DevOps.

Conclusion

Especially for enterprises still becoming familiar with DevOps and related methodologies, an internal trial project is often the optimal way to increase knowledge and reveal unforeseen obstacles to DevOps adoption.