With Agile developers constantly ready to ship new up-to-date iterations, managers are suddenly forced to make crucial decisions about when to release. And “They’re not ready for it,” argued Agile expert Fred George, one of the speaker’s at GOTO Amsterdam. “They’re used to throwing things over the wall and walking away.”

And they are not the only people in the organization that want to agile deployments, he argues. The office is full of them.

In general, he believes the first saboteurs are always the people who are losing power — the ones who are used to signing off on things. “Guys like, for example, the senior architect,” George explains. People used to come to their office and pray at his door, as George tells it, “making sure he will approve something before they move on to the next stage.”

“They’re not value-adding to the process. In fact, they stifle the innovation.”

repost for posterity pic.twitter.com/R70kuQrkmm

— Dan Hon (@hondanhon) August 10, 2022

But this senior architect has legitimate reasons to worry. George tells the story of advising a company that acquired another company. “The first thing we did…? We find everybody who makes rules and enforces rules… and got rid of them all.”

If they know what’s coming, George argues, they’ve got a motivation to sabotage an Agile transformation.

In fact, later George even puts “oversight” as a bullet point under “organizational sabotage.” Or as George puts it contemptuously, “people you have to ask permission of.”

“Organizations love to have this, because they think they’re in control when software is being developed. They’re not. Software is an unpredictable process.

“You can say all you want to and put all the charts together you want to. It’s always going to be an unpredictable process. But they still want to have the review boards, architects, standards….”

The Approval Process

George supplied an example, remembering his team’s room suddenly receiving a visit from a web services compliance architect demanding “Where’s my web services compliance report?”

Elsewhere in the organization lurk all those other people used to that one-massive-release philosophy of “waterfall”-style development.

“Most of the time it’s the UX guys, who say they’ve learned the process in school. They’ve got to study the entire thing, they’ve got to go do focus groups…. Then they’re going to think about it for a while, and they’re going to draw some pictures and wire it together perfectly. And then they’re going to give it to developers,” he said.

“I’m not going to wait for that. This process cannot tolerate that sort of feedback cycle.”

George names other villains — including “database guys, who have to approve things, and architecture boards, and all these other approval processes.”

But then, George believes, there are other people who are just jealous. He presents the example of a hypothetical Senior Java tech lead complaining “It can’t possibly work. And it’s not the way we used to do things… and this is not the way I want to work.” They’ll minimize your teams accomplishments, speculate about the hypothetical possibility of failure in different environments, and argue that Agile methodologies can’t possible work in a real-world situation.

Stalin-esque Mitigation Strategies

So what’s an effective mitigation strategy? “Well interestingly enough, we use a strategy from Stalin,” George tells the crowd, referring to Russian political leader Joseph Stalin. Specifically: don’t argue with people who disagree with you — George attributes this approach to long-time Agile advocate Roy Singham, founder of the IT consulting company ThoughtWorks.

Here’s how George summarizes Stalin’s approach for people who disagreed with him: “When all you other guys agree with me, we can shoot him.” The workplace equivalent? Avoid active confrontation. “Just keep working with the people who agree with you, get more and more of those guys on board,” until the person who disagrees with you realizes they have no influence, he explained. “I’m going after the masses. I’m not trying to convince everybody…”

George also offers another powerful mitigation technique: just label the whole thing as an experiment. “Don’t say, ‘We’re going to do this forever.’ People will get all upset. ‘We’re going to run an experiment.’

“When they object to an experiment, they look really unreasonable.”

And of course, keep the top executives involved. “Bring them to the showcases,” George advised.  They’ll be thrilled at the prospect of teams that are speedy, productive, and endlessly flexible.

As George tells it, the teams will get excited too. “This is fun stuff. You’re shipping code all the time. We’re working with each other, we’re solving problems together — this is fun.” So the problem isn’t the top-level executives or the developers down at the bottom who are doing the work. Instead, it’s “the guy in the middle” — whether it’s the middle manager the architect, or “the web services compliance guy.”

“He sees what’s going on. He’s not a part of that…”

It’s these risk-averse folk who don’t want to take a chance on a new methodology. “So ignore them. Get the guy at the top!” And then “Bring a new guy in, add him to the team. He will absorb the power necessary. Power is something teams give you… ”

But what happens when change agents become unpopular? What’s George’s strategy there? Hire someone else to absorb all that flack. “I guarantee you: bring in a real change agent, and you look very reasonable compared to them.”

George also has harsh words for the companies that attempt Agile transformations not by training each team’s developers in Agile methodologies, but by hiring a Scrum master for those teams to then dictate Agile processes from above. George describes one client’s strategy as “he will tell you how to work, and you will follow his directions.”

“Yeah, you can imagine how well that’s worked,” George scoffed.

“You just can’t hire people to enforce a process. The process has to be imbued with the people themselves.”

Throughout the talk, one thing shines through: George’s genuine enthusiasm and commitment for the Agile methodology. “Once you start down this process with your programmers, you can’t go back — they’ll quit!” he tells his audience.

“They’re having too much fun….”

WebReduce

• Lex Fridman hears life lessons from the world’s greatest chess player.
• A math-loving YouTuber’s hunt for five five-letter words using 25 unique letters.
• After 25 years, a husband-and-wife game team was lured back into the industry to resurrect a 1977 text adventure — in 3D.
• A superfan creates an AP-style exam about Star Wars.

David Cassel is a proud resident of the San Francisco Bay Area, where he's been covering technology news for more than two decades. Over the years his articles have appeared everywhere from CNN, MSNBC, and the Wall Street Journal Interactive...

Read more from David Cassel