Dive Brief:

• Business technology units are turning to DevOps because it offers accelerated delivery, better alignment and the improved ability to manage change, according to Nathan Wilson, Sr. Director Analyst at Gartner, speaking at the Gartner Symposium/ITxpo in Orlando, Florida, earlier this month. These were the same problems people tried to solve using agile, but the expectation of large product deliveries left projects unfinished.
• With agile, packages of "potentially shippable" code arose every few weeks, but offered no value for the end user, Wilson said. "Almost done" became the cliche of development teams, where 90% of projects were 90% done for 90% of their lifecycle.
• DevOps and continuous delivery models emerged to solve the disconnect between potentially shippable code to placing it in production. In a DevOps environment, teams do not have to deliver completed products all at once, according to Wilson. Instead, teams can execute iterative deployments, move quickly, work with end-users to understand requirements and remain flexible if changes come up.

Dive Insight:

Focus on enterprise technology tools has abated in favor of establishing the right methodologies to implement change at scale. On their own, tools prove useless without guidance and leadership from technology stakeholders.

DevOps works to combine two previously disparate parts of the business: development and operations. It aligns project teams with the end-users, working to solve disconnect in a business.

End users know what they want, but it's usually not what's delivered, according to Wilson. "How many software projects look like great flight, wrong airport?"

The key for enterprise delivery is moving on from big batch to continuous delivery, keeping the end-product value in mind.

DevOps implementation is not without its faults. Too often teams are hesitant to invoke real change, relying on vendors to provide easy answers to cultural disconnect. The key is not to skip steps along the way.

With the efficiencies created by DevOps, it is possible to move too quickly with iterative releases. C.H. Robinson adopted innersource and revamped its engineering structure, sparking a huge uptick in the number of deployments.

Though an improvement from the sluggish pace of waterfall releases, users were in a near-constant state of adjustment and tech was asked to "slow down."