Most organizations now use agile software delivery models, with the No. 1 goal of delivering new capabilities as fast as possible.
Consider the numbers: The 14th Annual State of Agile report, released in May 2020 by Digital.ai, found that 95 percent of respondents say their organizations practice agile, and that the top reasons for doing so are to accelerate software delivery, to enhance the ability to manage changing priorities and to increase productivity.
Despite such ambitious goals, however, agile experts and agile practitioners say many organizations aren’t achieving the speed they seek because they’ve turned a blind eye to persistent problems in their practices.
“Everyone says they’re doing agile, but many aren’t or they’re not doing it as much or as well as they want,” says Dave West, CEO of Scrum.org.
So where are organizations falling short without realizing it? Here are 10 common self-deceptions that still slow down software delivery.
1. We’re agile because we use the terms
West has seen IT teams adopt the nomenclature of agile methodologies, renaming project managers as Scrum masters and dubbing workgroups as tribes. Granted, using the right terms can be important, but it’s often merely superficial change. Such steps must be backed by the more substantial work of restructuring the organization so that the work being done matches the new titles doled out.
“Too often people are doing the same thing, they’re just calling it a different thing. They might have changed the names, but not the elements. And most people just pay lip service to that realization,” West says.
Christine Hales, vice president of technology at Capital One, agrees.
“This is really a cultural change. If you approach it as a bunch of processes and tools, you’re missing out on what’s really possible,” Hales says. “People need to work differently as teams; that’s a cultural transformation.”
German financial institution DZ Bank has brought in a range of technologies over the years to support its long-standing DevOps practices, but Henning Ehm, head of DevOps at the Frankfurt, Germany-based bank, found that the adoption of such tools was hit or miss.
“I was thinking, ‘I am doing something good to help people, I will build the technology and they will use it in a proper way.’ But what we saw was a lot of cases of resistance,” he says.
It’s not uncommon for IT leaders to assume that their own technologists will automatically seize upon the latest tools and quickly ramp up their use of them. But, as Ehm learned, technologists need training and benefit from change management strategies, too.
“Engineering people like to play around, but to get the true potential out of tools, and to introduce them into our processes, is hard work You have to put in a lot of effort on the change process.,” Ehm says. “Now I focus more on the people and how to bring them to where they use the technology to [its full potential].”
3. Teams will keep meetings brief
Agile practices abandon long formal meetings in favor of brief huddles and other such engagements, but old habits die hard. For example, Ehm says he has seen Scrum meetings that should take 15 minutes last three times as long, with participants using the time to address all manner of concerns and topics.
“Meetings should have a very specific purpose, and a lot of people aren’t used to that,” he says, citing the need for managers to educate teams on how meetings should work when adopting agile as well as the need for managers to enforce the limits on time and topics.
“Now we discuss one thing and only this thing at our meetings,” Ehm says.
Although modern practices encourage teams to pick ways that work for them, Amit R Bhandarkar, director of engineering at American Express Global Business Travel, has seen the downside to that approach.
He says his teams ended up with different CI/CD tools, with some using open source solutions and others using offerings from various vendors. “They were achieving the same outcome but in different ways, and it was affecting agility; some teams were hitting it out of the park, others were struggling,” Bhandarkar says.
In response, the development teams standardized, moving to a single, consistent environment that supports more uniform success rates and also reduces the maintenance burden on developers.
Bhandarkar believes there’s a lesson in that. “You ought to be prescriptive in your approach everywhere there are choices; whether it’s the specific methodology you want or the length of your sprints, you want to be prescriptive and consistent so everyone is in sync with each other,” he says.
5. My teams are flexible enough
Steve Berez, a partner at Bain & Co. and co-author of Doing Agile Right, once worked with an airline that needed its engineers to create new capabilities for its flight operations at the same time it needed less work on customer systems; but the number of engineers capable of working on the flight operations was limited, making the IT department less responsive to shifting business needs.
It’s a common problem, Berez says, adding that “engineers aren’t fungible enough.”
He says CIOs can address this issue by increasing their use of common technologies across different parts of the business along with greater cross-training of their people so that employees can work on multiple technologies.
“What it often means is doing new development using microservices and using the same development language for those microservices even across the different functional areas,” he explains.
6. That rule doesn’t apply to us
Like all methodologies, agile frameworks advocate for using a list of best practices.
But West has seen many organizations dismiss the need to follow some prescribed processes, seeing themselves as exempt — only to then wonder why they’re not seeing as many benefits of agile as they anticipated.
He has seen, for example, organizations exclude one particular business group — such as marketing — from agile teams, reasoning that in their company it just won’t work because their processes are far too unique when in reality it’s just a territorial battle that no one wants to fight.
“The ‘I’m special’ is a great excuse for ‘I can’t fix this,’” he says.
West continues: “Everybody is unique, but the reality is they are and they’re not. It’s true that every situation is unique, and that one model doesn’t apply to everything and every situation, but the underlying tenets do. So if you’re going to break [an agile principle], you need to be explicit about why you’re doing it and understand the consequences of doing that.”
7. Process change is enough
“At the moment there is so much focus on agile methods and ceremony that everybody ignores structure,” says Prashant Kelker, a partner at ISG, a technology research and advisory firm.
He says agile advocates within the enterprise need to also consider how they restructure their departments and their products, determining, for example, whether such elements are centered around customers or processes.
It’s a tough area to tackle, Kelker admits. “Once you start talking structure, then you get focused on egos, job titles, people’s careers and career advancement,” he says, but stresses the need to address structure nonetheless.
8. Our budgeting process doesn’t slow us down
Although most organizations have adopted agile methodologies, management experts say many of them fail to acknowledge the need to update long-standing budgeting practices.
“What we see in many, many organizations is that it takes too long to start the process of pursuing a new business opportunity. And it takes too long to stop working on something when the value they [anticipated] turns out not to be there,” Berez says. “This often comes because many organizations still fund projects on an annual basis.”
Berez says the most successful agile organizations have switched from deciding what initiatives to fund on an annual basis to a budgeting process that doles out smaller amounts more frequently as work progresses and proves its value — a process akin to venture capital funding. Others use a process where empowered product owners use funding stretched over a period of time to deliver specified business outcomes.
Such budgeting approaches, Berez says, “creates more flexibility and agility.”
9. My partners and vendors don’t need to be agile, too
IT leaders generally believe that making changes to their own teams and internal processes will get them the speed and agility they need to deliver new capabilities as quickly as their business units and the market require.
That, however, is not enough, Kelker says. They must get their partners onboard as well.
He adds: “What if the contracts with your suppliers only allow waterfall? What if the way you’re buying is plan-build-run? What if your sourcing doesn’t allow DevOps?”
Kelker says enterprise IT teams can’t maximize the full benefits of agile unless — and until — they get their vendors and partners to follow suit, noting that IT contracts with their third-party suppliers should be written to ensure that all parties are using agile methodologies to quickly deliver new features and functions as well as incremental improvements — with payments structured to support that move.
10. We’ve implemented agile so we’re good
West was working with a software company to scale its agile practices when he asked one of the executives about the effectiveness of the company’s Scrum practices. The executive was dismissive, saying that the company had already put those practices in place. The executive considered Scrum practices (like the other agile principles that the company had adopted over time) were a done deal; he didn’t consider anything amiss with that line of thinking even as his company failed to deliver products after several separate sprints.
“They think agile can be done and finished: That’s the ultimate elephant in the room. They completely forget the continuous improvement element,” West says. “And if you take your eyes off of it, if you don’t have a plan for building in continue improvement for your agile practices, you end up with a problem.”