Variable-speed DevOps helps fix two-speed IT challenge

Two-speed IT is like taking a walk with a child. It’s simply a fact that the child’s legs are smaller. You can’t just walk at your speed and let the child walk at his or her speed. You’ll end up 100 yards ahead of the child and have to stop and wait for him or her to catch up every few minutes.

Variable-speed DevOps is like finding the balance between you taking shorter strides and the child taking faster steps so you can keep pace with each other and enjoy the walk. Even after an organization has done everything possible to automate processes and function more efficiently, there will still be some teams or processes that take longer to reach a milestone than others. Variable-speed DevOps is about finding ways to continue being productive and move forward rather than sitting idle waiting for others to catch up.

I wrote about a panel discussion from IBM InterConnect 2015 where the discussion revolved around the concepts of two-speed IT and variable-speed DevOps:

IBM InterConnect 2015 took over the Mandalay Bay and MGM Grand conference centers this week with an estimated audience of more than 20,000 attendees. The event is filled with DevOps evangelists, hybrid cloud experts, and IBM customers converging to share information in presentations and panel discussions.

On Monday I had an opportunity to attend one such panel discussion titled Mobile to Mainframe Experts: DevOps Best Practices for Systems of Engagement and Systems of Record. Yeah, the title doesn’t exactly “pop” but I didn’t let that dissuade me. The panel included a number of respected names in DevOps such as Carmen DeArdo from Nationwide Insurance, and Rosalind Radcliffe and Sanjeev Sharma from IBM.

In spite of the title of the panel discussion most of the conversation revolved around the concept of two-speed IT. In any organization—no matter how streamlined—there are going to be different processes or teams that function at different speeds. Applying the Pareto Principle, even if the organization figured out a way to operate more efficiently there would still be 20 percent doing 80 percent of the work and 80 percent doing the other 20. It would just be a matter of degree.

The problem is that if the speeds are too different problems arise. First, it’s just a waste of resources to have skilled workers sitting idle waiting for a different group or process to catch up. Second, those workers will often get antsy and go rogue—writing code and introducing features that weren’t part of the initial requirements and aren’t part of the planned testing. Now you’re just adding chaos that disrupts the workflow even further.

According to the esteemed panel the goal is to find ways for those processes and teams to function at their own pace without it impeding the overall efficiency —hence two-speed IT. Rather than trying to force a square peg into a round hole, or getting frustrated that the square peg can’t just be round in the first place, you have to find ways to maximize efficiency with the teams and processes you have.

You can check out the full story at DevOps.com: Streamlining no matter how many speeds your IT operates at.