DevOps and agile development facing the challenge of urgency

delphine.coille's picture
Blog Categories: 

Joe McKendrick canvassed industry leaders about the prospects for DevOps and agile for this article originally published in ZDNet.

We’ve been talking about Agile development for two decades, and DevOps since 2009.

Everyone wants to take these business approaches to software development and delivery, but confusion and disappointment is often the order of the day. This year, marked by reconstruction in a post-pandemic environment, accompanied by ever faster digital competition, guess who will be under enormous pressure to deliver software with small budgets? Yes, managers and IT professionals can expect a busy time.

DevOps has an automation problem, while agile has an identity problem.

Both face organizational problems. These two, intertwined methodologies -- or philosophies, if you will -- will make the difference in the march toward digital transformation in the year ahead, but organizations still have a great deal of finessing to make things work. The goal is to have everyone on the same page, moving in the same direction, delivering quality software quickly.

The challenge going forward with DevOps is there are still too many manual processes, according to Eric Newcomer, CTO of WSO2.

Automation is key across the board, agrees Kief Morris, principal cloud technologist at ThoughtWorks.

People have different definitions of DevOps and agile

Lei Zhang, head of Bloomberg's Developer Experience group, says understanding what DevOps and Agile actually are matters. Zhang's team turned to the measurements established within Google's DevOps Research and Assessment guidelines -- lead time, deploy frequency, time to restore, and change fail percentage, and focus on the combination.

Over the coming year, we're going to see more efforts to get agile right.

Agile, which provides a sense of that all-important business collaboration as digital development moves forward, has been hampered by misunderstanding and miscommunication. While Newcomer reports seeing many instances of agile being successfully employed, there are still too many cases of the antithesis of agile, the waterfall approach, still in practice -- while being labeled as "agile."

DevOps also suffers from a similar identity problem. "Just like you see with agile, DevOps means different things to different people, so different people do different things and call it DevOps," says Morris. "People often focus on tools and the superficial forms, rather than on the principles and on outcomes. So you see DevOps teams that run Jenkins servers and maybe write Ansible, but you don't always see developers involved in operational aspects of the code they write, and you don't often see everyone across different roles including testing and governance collaborating effectively on building the right things into software."

There's even a tendency for organizations to attempt to simply rebrand existing process as "DevOps," without changing the fundamentals underneath. "It surprises me when I meet with leaders in other organizations and find out that their DevOps team members are really just rebranded ops members," says David Torgerson, senior director of engineering for Lucid Software.

DevOps is more than embedding ops members in dev teams, Torgerson says. "Their focus tends to stay on maintaining the production system instead of focusing on improving software development lifecycle, continuous delivery, and high-quality output. By focusing on the goal of shorting the software development lifecycle, implementing continuous delivery, and increasing quality of output, the way that traditional ops and dev teams interact changes, and that is when the true value of DevOps emerges."

At the same time, agile often gets boxed away, rather than baked into corporate culture

"I see a sort of disconcerting trend to view agile as more of a program or project management practice change, rather than a dev practice change," Newcomer says.

A healthy agile business technology organization extends beyond the IT group. Bring in the business lines. Agile technology initiatives include business lines, especially as process managers continue to get more deeply involved in automation, so digital process automation technologies that can be used for close collaboration across organizations will positively impact agile projects. For example, automation technologies should include wide options to allow visual programming for citizen developers to create user interfaces, define business rules and conditions, and coding capabilities for developers like SDKs, templates, archetypes, and extension points.

- Nicolas Chabanoles, CTO at Bonitasoft

This full-throttle engagement of the business is crucial, especially in terms of getting people in the corner offices involved. "Most agile initiatives are missing executive sponsorship that is both visible and durable," says Bryan Stallings, chief evangelist for Lucid. "Most agile initiatives lack the ability to quantify the impact of the initiative in comparison to its costs. As the attention of the sponsor turns elsewhere, the program starts to look like a pile of expenses without a quantifiable return. Invariably, business pressures mount and those involved in enabling the change are eliminated or returned to a focus on business as usual." In ideal situations, top executives -- especially the CEO -- should communicate their commitment to the effort, and take personal accountability, he says.

This post is an extract of an article by Joe McKenrick originally published in full on ZDNet and republished on