Everyone's talking about the benefits of DevOps, but moving to a DevOps model can be a big challenge for traditional IT departments. How do you break down traditional silos and ingrained ways of doing things? The American Productivity & Quality Center (APQC), a nonprofit focused on business benchmarking and best practices, is completing just such a transition.
Who better to share best practices for moving to DevOps than Ron Webb, APQC's executive director of Open Standards Benchmarking, Stats Hub, and Information Systems? In an interview with The Enterprisers Project, he shares what APQC has learned so far.
The Enterprisers Project (TEP): Where are you in your transition to DevOps?
Webb: We are toward the tail end of this transition from a traditional approach to developing, delivering, and maintaining and supporting technical solutions for our customers. A lot of people describe this as moving from a 'waterfall' methodology of delivering projects to a DevOps methodology.
TEP: What inspired the change?
Webb: We are making this transition because our world moves too fast, and it is way too risky to expect that you can gather your customer requirements completely, then deliver a project over a 4-6 month timeframe. To do that, you have to assume that either you can get all those requirements correct that far in advance, or that the customers' requirements won't change because their world changes. This approach resulted in a lot of projects that were slow, and if delivered, not what the customer really needed once delivered. And, to get projects updated meant repeating that same process over again, coordinating way too many people across too many silos, just to wash, rinse, and repeat it all again.
We found the biggest disconnects happened around coordination of all the silos that need to be involved in a project. The subject matter expert, customer, developer, business analyst, project manager, and infrastructure team had to be coordinated. You have to have an infrastructure in place just to manage the project. Worse, was the disconnect between the IT team and the customer. Things are in too much flux to expect you can gather all the requirements in a few meetings with a very busy customer like a sales director. Connection with the customer is key.
We wanted to work in small, quick groups that almost integrated with the customer throughout the life cycle of the technical solution. Requirements are gathered, developed, confirmed, tested, and rolled out to the customer in quick bursts. Adjustments can be made on the fly and everyone always knows what is going on; communication happens as part of the flow of the project, not as a separate work stream that a project manager executes for the team of developers and system administrators. We're seeing everyone engaged in the project from the first day to the last tweak.
TEP: What are the biggest challenges in transitioning to DevOps?
Webb: The hardest transition has been around project management activities. It's pretty easy for someone who develops a client solution to slide into the role of also maintaining and supporting that solution. But traditionally, IT folks haven't had to be real project managers. They aren't well versed in tracking time, statuses, raising issues, managing customers and stakeholders, or general interpersonal skills. The IT staffer who has experience and skills in this area is in the minority for sure.
This results in potential stalls and potentially frustrated customers who feel their project isn't being run well regardless of the solution delivered. Even with a ramped up pace of delivering outcomes to the customer, they gauge the project's success initially by how well they think it is managed and the communication they get from the team. Those things can derail it early and give the project a huge barrier around perception to overcome that doesn't need to be there in the first place.
TEP: Any lessons learned from moving from a more siloed approach to DevOps?
Webb: The transition, I've found, is hardest on the IT team. I haven't run into a customer yet that has asked us to deliver things more slowly and communicate with me less.
For the IT team, though, it is about pace. Keep the pace moving during the transition. You need a strong, well-respected driver for this transition. They have to know IT, understand process change, and also be well versed in change management. Not a lot of CIOs or COOs have this skill set, so some outside support from an internal or external consultant may help.
We are also a process-focused organization, so the transition was a bit easier for us. It is the same methodology within the IT group as it is with our customers. Treat it like a project. Deliver changes quickly, communicate well, stay connected with the requirements of both the team and the organization, and move. Stagnation kills this transition.
TEP: What advice would you pass along to other CIOs or COOs thinking about moving to a DevOps approach?
Webb: Do your research and understand if DevOps is for you. It may not be for every organization, and there is plenty of great stuff out there to read. Don't focus on tools, as IT is prone to do. Focus on process, change, and the customer needs. The rest of the benefits will follow.
ALSO READ
Ron Webb works directly with the Open Standards Benchmarking® team to help match the right data-intensive products and services with the APQC members that need them. He also works with the Stats Hub, applying statistical methods and analysis to help members identify new improvement opportunities using data. Ron is a self-proclaimed “benchmarking geek” who is fascinated with numbers and how the numbers, combined with a strong analytical approach, provide a roadmap for improvement.
Webb also leads the Information System team and department, ensuring that APQC uses technical resources appropriately to deliver services to members. The focus is to use technology to solve business problems and spans strategic technology planning, technology selection, project management, and implementation of systems. He also oversees the team providing day-to-day technology and user management as well as disaster recovery planning.
Webb is an APQC “lifer” who has worked in multiple capacities since joining the center in 1996. He has managed and executed numerous benchmarking projects for APQC members, led the planning and development of the first APQCKnowledge Base website, led the sales and marketing teams, and directed APQC’s membership product team. He has also led many benchmarking research projects and presented training and conference sessions on benchmarking techniques and best practices. One of his more popular presentations was on Best Practices for Managing Corporate Quality.
