Agile on the Precipice

After 20+ years of growing influence, Agile appears to be standing on the precipice of irrelevance. ?

In this time, Agile has spread wider than we Manifesto authors dreamed, but failed to spread as deeply as needed. Agile has lived up to Jerry Weinberg’s Law of Strawberry Jam, “As long as it has lumps, you can never spread it too thin.” We need more “lumpy” implementations of Agile.

Will Agile be relevant in the future of software development? What needs to change? Following are a few thoughts I’ve had on this subject. ?

How do you interpret the Agile Manifesto?

The United States constitution will be 236 years old in 2023, and in Congress and the courts, there is an ongoing heated discussion over what it says and what it means. While pragmatists seek to comprehend the practical ramifications of their decisions, literalists focus on a precise interpretation of the words. The literalists seem to be arguing that if the words were good enough 236 years ago, they should be good enough today—as if we were in the same world today as in 1789.

Similar arguments surround the Agile Manifesto. There are some who insist that “Working software over comprehensive documentation,” means that the Manifesto applies only to software (literalism) whereas the pragmatists see their way clear to apply the agile values to a wider set of products and services. What you think about the Agile Manifesto and its relevance today depends on your perspective.

We need a balanced approach to interpreting the Manifesto—not so literal we get stuck in the past, but neither so pragmatic we lose value. ?

Which mountain are you trying to climb?

What are you trying to accomplish—a leisurely, alpine flower extravaganza stroll up the Alta, Utah?Cecret Lake trail; the moderately technical, daylong 2,000 foot ascent of the North Ridge of Mt. Stuart in Washington state; or an expedition to Mount Lucania, second highest mountain in Canada and so remote the second ascent took place 30 years after the first? Each of these peaks requires a different level of?planning, expertise, preparation, and coordination.

Don’t you have software projects or products with the same differences in difficulty? Won’t your approach to each of these challenges differ, probably significantly? With methodologies it is easy to fall into the “one size fits all” trap—don’t!

Prescriptive agility, really?

Why do we need the adjectives prescriptive and adaptive agility? Shouldn’t the word “agility” be enough? Sadly not. Didn’t we leave prescriptive, Monumental Methodologies, behind? Apparently not. In order to be agile, we must experiment, learn from success or mistakes, and adjust. This applies to methodology as well as products.

Whether for Scrum, Extreme Programming, Kanban, Crystal, DSDM, or any other Agile approach, anyone or any organization who still promotes prescriptive agile has lost the spirit of what its designers intended. Methodologies should be a guide, not a restraint.

Is velocity killing Scrum?

The focus on “Doing Agile” (activities and processes) rather than “Being Agile” (values and principles) has been one issue plaguing agile implementations (and not just Scrum).

Scrum critics chide implementations that fail to get the culture part right. Using unsuitable success metrics are part of this problem. Organizations claim to value adaptability, but they stubbornly cling to outmoded industrial age measures of success. Productivity measures are a hazardous holdover from the industrial age and in our topsy, turvy innovation age they are barriers to agility.

Velocity is a productivity measure, and therefore an entirely inappropriate gage the success of knowledge work. Its like arguing that James Michener was a better writer than Ernest Hemingway just because he could type faster!

In today’s high tech world, managers still rely on productivity measures, not because they are effective, but because they are precise and relatively easy to collect. Give me a fuzzy metric of something important (like customer value) instead of a precise metric of something unimportant every time.

If you use productivity measures to access software development performance, you will ultimately fail to “Be” agile. Go with fuzzy, but relevant, value measures.

So, which methodology is best?

And the answer is, there is no best methodology, only ones that are better or worse for particular undertakings, in particular situations. In my six decades of experience with a variety of ad hoc, structured, monumental, rapid application development, and Agile methodologies my conclusion is “I think the root cause of success is people and their interactions, and the root cause of failure is also people and their interactions.”

I’ve seen all these methodologies work, and all fail, but ultimately success depends on people, not the methodology.

In conclusion,

Agile, in the form of Agile Methodologies may be on the precipice, but the need for agility, at all levels of enterprises, remains critical to surviving and thriving. It’s time to reinvigorate the Agile movement by adding additional “lumps” to the jam. Where are the new lumps? As a starting point, visit one of the original Agile Manifesto signatories, Alistair Cockburn, at The Heart of Agile , or more recent agilists advancing the art of Agile at Serious Scrum or Agile 2 .

Note: This article was originally published at jimhighsmith.com . These topics are explored further in my forthcoming book, “Wild West to Agile : Adventures in software development evolution and revolution.