BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Ron Jeffries Says Developers Should Abandon "Agile"

Ron Jeffries Says Developers Should Abandon "Agile"

Leia em Português

This item in japanese

Bookmarks

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
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.

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

Community comments

  • False perception

    by Adrian Ng,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

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

BT