BT

Ron Jeffries Says Developers Should Abandon "Agile"

| by Rui Miguel Ferreira Follow 4 Followers on Jun 05, 2018. Estimated reading time: 3 minutes |

Ron Jeffries, author, speaker, one of the creators of Extreme Programming (XP), and a signatory of the Agile Manifesto back in 2001, shared a post on his blog in which he advocates that developers should abandon "Agile". The post further elaborated that developers should stay away from the "Faux Agile" or "Dark Agile" forms, and instead get closer to the values and principles of the Manifesto.

The terms "Faux Agile" and "Dark Agile" are used by the author to give emphasis to the variety of the so-called "Agile" approaches that have contributed, according to him, to make the life of the developers worse rather than better, which is the antithesis of one of the initial ideas of the Agile Manifesto. The main reasons pointed out by Jeffries for this to be happening are:

It's good for the Enterprise, not so good for Developers
When companies attempt to adopt agile, it usually means that they are trying to improve the way they do things. With the help of different flavours of coaching and training available, they are able to increase the visibility of their issues, which typically results in making better informed decisions by the top management and the company in general. According to the author, this is definitely a good thing, even if the values and principles of the Manifesto are poorly applied. It becomes a bad thing at first for the developers, and ultimately for the companies themselves, when we see poor implementations of agile

[Agile adoptions] often lead to more interference with developers, less time to do the work, higher pressure, and demands to "go faster". This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing "Agile" poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing "Agile".

 

The Developers will still be working under an imposed approach
Working for a company or an enterprise often means that some things are decided at the top level and then implemented or rolled-out throughout the organization. This is typically what happens for large scale implementations of Scrum using SAFe, LeSS and others, according to Jeffries. Then, most of the people will be required to adopt and to start applying it without proper training or coaching, and without understanding the true mindset behind this.
Although you cannot control some of the things happening around you, there are some advice that the author wanted to provide on his text:

  • Select the work to be done in a way that allows you to deliver small pieces of working software every two weeks or so.

  • Lower down the expectations, you need to understand your delivery capabilities and well as others do.

  • Leverage conversations on top of the small increments delivered iteration after iteration.


 

Getting back to the roots of the Agile Manifesto, Jeffries reinforces the idea that the most important thing behind Agile is the mindset, its values and its principles, as they still offer the best way to build software. So, no matter what framework or method formalized by an organization, every Agile Developer should work in the following ways:

  • Produce running, tested, working, integrated software every two weeks, every week. Build your skills until you can create a new fully operational version every day, twice a day, multiple times a day.

  • Keep the design of that software clean. As it grows, the design will tend to become complex and crufty. Resist and reverse this tendency consciously, refactoring in tiny continuous steps, all the time, so that your rate of progress is as steady and consistent as possible.

  • Use the current increment of software as the foundation for all your conversations with your product leadership and management. Speak in terms of what's ready to go, and in terms of what they'd like you to do next.


 

Ron Jeffries publishes articles in this blog and on Twitter.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

False perception by Adrian Ng

I can subscribe to many of the affirmations made above, however from my point of view not the methodologies are at fault but the way they are understood and implemented. Each technology can be misused, especially when not well understood. The less rigid a methodology is, the higher the chances that the methodology will be misused.

Ask an experienced developer and he’ll tell you which parts from a methodology will work, which won’t. Unfortunately, there are people stubborn enough to enforce their
understanding of a methodology, even if they haven’t written a line of code in their life.

I think that agile methodologies can be further used as long people take the best from them and customize them on their needs.

Jeffries should just admit the whole Agile thing is self-defeating by Andrew Wolfe

About the only benefit of Agile is that when a project fails or is crappy, you have some code to show for it. Otherwise there's practically no difference between its results and waterfall's.

He fails to mention the intrinsic flaw which has never been refuted by any Agile proponents: Agile prevents a team from developing a design—"clean" or otherwise.

And while castigating "imposed" Agile and "incorrect" Agile, he fails to explain how a team can work the "correct" Agile as a whole if that is not "imposed" on them. And to whom do all the "experts" in Agile sell their exorbitant consulting gigs? Not the developers!

Just trash the whole thing.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT