Agile Is Not a Method, Let Alone “The” Method

(Previously published on DZone)
In four years, the Agile Manifesto will celebrate its silver jubilee. I want to devote another post to these sensible recommendations you find hanging in poster format on office walls the world over. Agile as a noun has become solidified in the established practice of software development to the point where many treat its values as if descended from Mount Sinai on stone tablets. They are not eternal truths and can make no such claims. They were written when Perl/CGI was the go-to stack for web apps. Agility encompasses adaptability, so the values themselves must be constantly re-evaluated and questioned.

The Agile Manifesto summarizes its values and principles on a single sheet of paper. The Scrum Guide needs more space, but it’s still concise enough to be called a summary. That needn’t be a problem. Many complex cooking recipes fit on a single page. But Agile, however you define it, can at best only be a set of ideas and values, never a recipe or how-to guide for building great software – Scrum doesn’t even talk about software. That’s why the agile method is a deceptive term. The Oxford dictionary definition of method resembles that of a recipe quite well: “A particular procedure for accomplishing or approaching something, especially a systematic or established one”. It’s funny that the entry should give a method for software maintenance as an example. The lexicographer probably thought refactoring is like plastering a ceiling: something hard that requires skill, but no originality or imagination.

I wrote earlier that there’s no recipe to creativity, but even recreating things you didn’t invent yourself is rarely as easy as following a description of the steps involved, except perhaps for an Ikea bookcase. People train for years to become a top chef. You can’t expect to create their haute cuisine by careful reading alone.

Since developing novel software is an act of creation, there can be no cookie-cutter approach, or we would have automated it already. However, there certainly is a methodology that inspires the way we go about it. These are the more abstract principles that justify our choices, like openness to change and end-user involvement. The Agile Manifesto set out to define such a set of ideas through the condensation of a lively debate. The details of these conversations are left to the reader to fill in and interpret, but they are not incidental. They are at the heart of the methodology. It takes experience and judgment to understand and appreciate these ideas.

Method and methodology – they sound like a Jane Austen novel – go hand in hand. The first concerns the how, the latter the why. A methodology explains and justifies the ideas behind the operational mechanics of a method. The method appears neutral, but it can never be uncontroversial when its underlying principles are open to different opinions. This is certainly the case with original Agile values like team autonomy and the strong preference of face-to-face communication.

How many of the Manifesto’s principles for the most efficient way of working are backed up by rigid scientific evidence? Maybe some are, but most are at best tenuous, and some no better than personal preference, probably unrecognized as such at the time because of the very homogenous nature of the original brotherhood of men who expressed them. “We all think so, therefore it must be true”. That is dangerous groupthink. When you’re considered an expert in the field and people adopt your opinions, you bear a great responsibility to separate personal taste from proven facts.

The values and assumptions behind the original Agile ideas lead to a rather rigid method for building any type of software. But a single method can never be equally suited to every product in every industry. Agile values must be generic enough so they can allow for multiple methods.

Since we all love the movies, please indulge me in an analogy with another method, i.e. The Method. I’m sure you’ve heard of it. The Method is an approach to stage and film acting based on the ideas of Russian actor/director Konstantin Stanislavksi. It encourages sincere and expressive performances through identifying with, understanding, and experiencing a character’s inner motivation and emotions. Its gained global influence through Lee Strasberg’s Actor’s Studio in New York in the 1950s and the generations of legendary film actors who trained there. 

An actor must understand how the writer and director intend to convey to the viewer the plot of the story and the emotions of the character. The Method has practical instructions to help the actor. Its methodology is opinionated about the purpose of acting, which is to approach as truthfully as possible the emotional life of the character. There is no better way to do that than becoming the character. Some actors go to extreme lengths in that quest and there are plenty of popular Hollywood legends about self-inflicted hardship. Most famous is the story surrounding the infamous torture scene in Marathon Man between Dustin Hoffman and Laurence Olivier. To get in character and look suitably haggard, Hoffman had deprived himself of sleep, at which Olivier asked with amused surprise why he didn’t just act it. As a veteran of the British stage, Olivier had a different artistic outlook. 

Image (c) cottonbro licensed through

The Method is grounded in a naturalistic philosophy of acting. There is also the school of Michael Chekhov, which favors the power of imagination over perfect realism. Two different philosophies with very different methods and radically different results. Sometimes a role demands a pure, naturalistic approach. Think of Oscar winners Brie Larson in Room, or (again) Dustin Hoffman in Kramer vs. Kramer: completely different films and actors, but with the same approach to realism.

But sometimes real isn’t interesting, in the words of Stanley Kubrick (I mentioned him before – I’m a fan). To play a proper baddie, you need to push beyond real. Think of Jack Nicholson in The Shining, Christian Bale as American Psycho Patrick Bateman, Anthony Hopkins as Hannibal Lecter, and the two Jokers Heath Ledger and Joaquin Phoenix. They are mesmerizing performances, but their characters are not true to life. They are over the top, which makes them scary and funny.

Truly great actors know that they must sometimes change their customary approach to do full justice to a part. Method devotee Al Pacino portrayed drug kingpin, Tony Montana, quite differently from his earlier roles. Why? Because Scarface was not your average gritty gangster movie. It was an outrageous drama, like Shakespeare’s Macbeth set in Florida, and it called for a character larger than life.

Different vision calls for a different character and a different method. I hope you find this analogy to the craft of building software useful. Substitute the artistic vision of a writer/director with the product vision of the organization, and add to the mix the prospective end-users, restrictions of time and money, and the diversity of the people involved. Suddenly, “working software,” like “good acting,” is too generic to be useful. The context determines and refines how we should define working software, and what’s the appropriate method to attain it. What works for an online game would be completely unacceptable for the James Webb telescope. How could there ever be one effective practical method applicable to all?

Few Agile values are non-negotiable, besides honesty, respect, and everything it takes to be a good person. If a single set of immutable values doesn’t even work for multiple projects in a single organization, it’s naïve to expect that it should work for the industry as a whole. Yet this is what we keep doing. The wisdom we like to call our experience is weighed down as much by the baggage of our preconceived notions. You just can’t take on a new project or job and shoehorn your old routines to fit new circumstances and requirements. Be more like Tony Montana next time – well, Al Pacino’s interpretation of the monster, obviously.