Has Agile Programming Lost its Way? – InApps Technology 2022

Programmers are passionate about which development methodology is the best. Is it Agile? Waterfall? Feature Driven Development? Scrum? So everyone took notice when one of the 17 authors of the seminal Agile Manifesto wrote a blog post last month headlined “Developers Should Abandon Agile.”

Further down in his post, Ron Jeffries made a clear distinction between Manifesto Agile — “the core ideas from the Manifesto, in which I still believe” — and its usurping follower, “Faux Agile” (or, in extreme cases, “Dark Agile”). Jeffries ultimately urged developers to learn useful development methods — including but not limited to Extreme Programming — that are true to the Manifesto’s original principles, while also detaching their thinking from particular methodologies with an Agile name.

We talked to Jeffries this week about how his readers reacted.

“A few noted that if I had quoted ‘Agile, it wouldn’t be so click-baity,” Jeffries wrote in an email. “But of course I wanted it to be.” And a lot more people were agreeing with him, experiencing what he described as “the dark side of would-be Agile.”

“People doing the work know that what’s going on isn’t working as well as it should.”–Ron Jeffries

His blog post advocates a world where developers produce running, tested, working, integrated software at shorter and shorter intervals, and designing clean software that avoids complexity and “cruft” by constantly and consistently refactoring code. Managers and product leaders could then always be referred to the software’s latest increment, cultivating a collaborative approach which just might change management’s focus from “do all this” to “do this next.”

“This is the development team’s best hope for a reasonable life… the running software in our hands lets us keep the conversation focused on the next, most important thing to do, rather than the near-infinite list of things they think they want.”

For decades, Jeffries has advised developers to try Extreme Programming (or “XP”), in which development teams pursue many frequent releases in short development cycles. This, in theory, controls some of the chaos of software development, breaking large projects into smaller and more manageable increments, while creating more opportunities to add changes and new features requested by customers.

Jeffries has referred to Extreme Programming as “The Scrum That Actually Works,” and in his blog post calls it “the best officially named approach that I know of.” He describes how, if he were a company leader, he’d insist on reviewing product slices on a regular schedule. The Extreme Programming method “contains all the planning and feedback loops you need, and it includes the basic technical practices you need to do what we’ve been talking about here, and to do what I’d be asking for.” Though eventually, you’d want to add in essential elements like test-driven development and refactoring,

And XP, of course, is one of the more popular forms of Agile development, which also emphasizes the ongoing iterative improvements as a path to flexibility and collaboration. But Jeffries is always careful to make a distinction between Agile and those other processes which seem to ignore its basic tenets — while still using the word “Agile” in their name.

In his blog post, Jeffries writes that these lesser forms of Agile — or perhaps that should be “Agile” — have “become big business,” and it’s a theme he returns to in his email, complaining that “The ‘Agile-Industrial Complex’ of training and coaching, and would-be ‘Agile’ processes like SAFe, and the more-nearly-Agile ones like LeSS seem to be thriving. Big companies think they need to go Agile. Despite the low probability of a real ‘transition,’ I expect that will continue.”

There’s some data that seems to back him up. This year the annual “State of Agile” survey found only 12 percent of respondents reporting high levels of Agile competency across their organization — and only 4 percent reporting that it was making it easier to adapt to market conditions.

Jeffries offers a fair assessment of the state of development today. “I think that when an organization tries to get help, in almost any format, they will generally get some benefit,” he told us Thursday. “If you try to improve, you probably will. What troubles me is that those improvements accrue mostly to the business, and possibly therefore to the managers who get credit for business improvements, but rarely do the people doing the work see any benefit.”

“Faux Agile too often becomes a way to put the developers and other lower level folks under more pressure, to try to push out ‘more work’, rather than actually doing what real Agile makes possible. Bottom line, the business benefits are there, and too often the benefits are not there for the people.”

Jeffries’ post attracted a whopping 191 comments from the developers in Reddit’s programming forum.

But Jeffries isn’t optimistic about breaking that cycle. “I expect that process to continue indefinitely, in the same way that other decent ideas go on and on, getting watered down too often, but still providing a bit of benefit to the organizations that try to adopt them.”

“And I expect that some of the less scrupulous providers will continue to provide inferior offerings, and I suspect that even the better organizations will continue to chase the dollar rather than focus on really helping people. That’s just the way the world is, I guess.”

In his blog post, Jeffries pointed out that “The organization should at least get increased visibility into what’s going on, and that will often lead even the least enlightened management to make better decisions. That’s good, and I’m all for it.” But poor developers end up with less time to code with more pressure and interference — which besides driving experienced developers out the door, also creates more bugs and slower progress. Saying he’s at core a developer, Jeffries writes that “it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers’ lives worse, instead of better.

“It also saddens me that the enterprise isn’t getting what it could out of the deal, but my main concern is for the people doing the work.”

Though the original Manifesto had called for self-organizing teams, Jeffries’ blog post points out that instead Agile is too often imposed on teams, sometimes as part of its implementation. “These are pitched to the enterprise, and the enterprise is expected to ‘install’ them, or ‘roll them out’. As a developer, you can be sure that this roll-out will not go smoothly nor in a truly Agile fashion.”

During a podcast at Agile2016 in Atlanta, Jeffries pointed out that that violates one of the core principles of the original Agile Manifesto. “imposing on the workers is not ‘Individuals and interactions over processes and tools’. So I’m somewhere pretty close to going full backlash against all of this imposed Agile — corporate Agile, enterprise Agile — and saying ‘Let’s get back to people and teams and helping individuals and small teams learn how to actually build software in a joyful way.’”

https://www.youtube.com/watch?v=unDxq76JcvE

Instead, corporations end up with this imposed development methodology, according to Jeffries’ blog post, where training may be skimpy — for both developers and leadership — with pressure to work faster.

At this point, Jeffries advises developers to fully complete something, then “take the inevitable abuse for not completing everything, and try to drive planning and expectations from reality, not the fantasy of what was demanded, that you never had a chance to do.”

“It won’t be perfect, and for a while at least, it probably won’t be fun. It’s just the best chance I know to survive down in that code mine.” And hopefully, more enlightened organizations will gradually embrace more of the original Agile Manifesto. “I’ve been in those situations, and other than leaving, the best I know is to do good work, keep it visible, running, tested, and integrated, and help people to see reality.”

Similar concerns have been raised by another original signer of the Agile Manifesto, Robert Cecil Martin — also known affectionately as “Uncle Bob.” In “The Land that Scrum Forgot,” he talks about the important technical fundamentals (like test-driven development) that were being left out of Scrum certification programs.

It’s an inspiring reminder that the world of programming has the benefit of several voices of experience. Jeffries wrote his first computer program in FORTRAN in 1961 — for an IBM 704 being used at the headquarters of America’s Strategic Air Command in Omaha. About 35 years later, in 1996, he worked on a path-breaking project at Chrysler, building a payroll system which he now refers to as “the original Extreme Project” (where he role was “the on-site XP coach”), and Jeffries became one of three founders of the Extreme Programming movement

It’s been 17 years since Jeffries became one of the 17 original signers of the Manifesto for Agile Software Development, and to this day he remains “an outspoken supporter of technical improvement and excellence in Agile Software Development,” according to his website.

In our email conversation, Jeffries predicted that the core ideas of the Agile Manifesto will have a rosy future. “The values and principles have held up very well. And as I look at them, it seems to me that they generally will hold up.”

WebReduce

Feature image via Pixabay.