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

BT