Agile: For Developers, By Developers

Ron Jeffries is a legend in the world of agile development. He is one of the seventeen original signatories of the Agile Manifesto, and generally highly regarded agilist.

Jeffries is also one of the founders of Extreme Programming (the website is rather dated, but the information is still valuable), which is one of the methodologies that lead to the definition of the agile mindset – and one of the core agile methodologies even today.

Even though Jeffries of course recommends the practices of XP and will talk about its benefits, he's by no means evangelical about it. He is very much a proponent of the spirit of the agile mindset over any specific method or style of organisation. To each their own.

Developers Should Abandon Agile

Ron Jeffries posted a controversial blog post about a year ago on the topic of "agile" as he calls it (which you'll see described as Big Scrum in the above video).

In this post he argues, that developers should avoid "agile" and in stead do agile. As in, avoid things that sound agile but aren't and in stead follow the spirit of the agile principles – even under the confines of some weird constraining business scheme, that doesn't really give developers what they need.

Too commonly, the “Agile” approach a team uses has been imposed. Larger-scale “Agile” methods appear actually to recommend imposition of process. I include here the so-called “SAFe” method, Scaled Scrum, and LeSS among others. These are pitched to the enterprise, and the enterprise is expected to “install” them, or “roll them out”.

And we at Hyperreactive are completely and utterly agreeing with him on this point. We're not saying the SAFe or LeSS doesn't work, we're saying that it doesn't automatically work and often won't work. Pick a method that works for your team, not a method that someone is able to sell you on.

Finding the best approach to software development for each of your teams aren't easy. You can't put them into a formula and get a fixed result. And you definitely can't find one method and simply roll that out onto all your teams without dire consequences.

In stead, give your teams the resources and the knowledge they need to figure out their own best approaches. This approach requires great team members, experience and quite a bit of bravery. It might feel dangerous to let go of the reins in this way, but your teams' happiness and in turn productivity will be all the reward you need.

Want to be updated about more content like this?

Signup for our infrequent newsletter and receive tips and tricks for improving your team's communication, velocity, and skill set – all completely free!