Agile Is Never a Recipe for Creativity
Much confusion and disillusionment about Agile stems from viewing it as a surefire recipe to solve problems that actually require a different solution each time.
Join the DZone community and get the full member experience.Join For Free
In some of my recent posts on Agile I voiced my excitement and support for the Agile 2 movement. Indeed, after many years in software a breath of fresh air can still get me motivated. Agile 2 has given a renewed incentive to everyone’s favorite waste of time: quarreling in comment threads about the True interpretation of the Agile Path. “Folks, can we please stop going around in circles. Agile is perfectly straightforward if you do it our way. Just come back from the Dark Side and get certified with us”.
Forgive my tongue in cheek. Disagreement is not a waste of time. It’s the foundation of any democratic process. Software projects are still being scrapped midway or delivered with huge overruns, and Agile has notbrought us the magic bullet. Have you not been involved in those projects, or been partly responsible? We still haven’t found what we’re looking for, as Bono sang. Every proposal to improve out methods, from modest to maverick, deserves to be heard.
In this post I want to look at creativity and how it relates to the difference between frameworks and recipes. Frameworks prepare you for the unknown journey ahead. Recipes deal with repeating the predictable, not the new and unknown. I believe much of the confusion and disillusionment with Agile practices stems from viewing them as a surefire recipe or formula to solve problems that really call for a different creative solution each time.
If you expect them to work like a cooking recipe, the balanced proposals from Agile 2 are as much in danger of being misconstrued as the original Agile Manifesto often is. A recipe lays out the path to your destination, but it assumes you can already walk. It presupposes basic skills and leaves out the details. Agile methods are deliberately sparse and do not even plot out the development journey. That’s why they are not recipes. They supply you with boots, ropes, torches, and advice on how to deal with bears on the way. You must find your own way each time.
Anyway, recipes are no guarantee for success. They carry the false promise that with the right ingredients and utensils the same cake comes out of the oven for everyone who applies said recipe. Yet skill and experience can’t be taken for granted – you still have to master the subtleties. You can’t plaster a ceiling first time right from watching a Youtube video (I tried). Bob Ross was wrong. Not everyone can do it.
Writing software is a creative act, and you can’t summon creativity through a recipe. Otherwise, we would have automated it. Rather, it’s creativity itself that produces the recipe. Software is the recipe. We confuse its creation with assembling the pillars and girders of a bridge. It’s not. it’s the design of the bridge. Coding is part of the design stage. Build and deployment can be fully automated. Cookbooks have appetizing pictures of the outcome that you hope to copy. In software or traditional architecture our work is to create that picture. Once we have it, we’re done. There’s nothing to copy.
Creativity is called for when we need fresh solutions to problems that are sufficiently different from previous ones. If something feels trivial and repetitious to implement in code, it’s a red flag that there’s a generic solution out there that will make your expensive and buggy coding superfluous. Maybe consider a low/no code solution?
Great creative achievements often obey rigid structural rules. That doesn’t make them formulaic. Baroque music of the 18th century is a good example. The rigid and mathematical precision in Johan Sebastian Bach’s music has a beauty of its own. Modern AI can produce tunes that the man himself could have churned out on an uninspired day. But it never comes close to the exquisite melodies of the Matthew Passion. Once it can, Skynet has officially made mankind redundant. Exceptional originality and success are frustratingly erratic. You can’t predict or repeat it at will. It was youthful passion and a clash of musical tastes that blessed the partnership of Lennon and McCartney. Much as I value his later work, Sir Paul rarely came close since.
Take dramatic writing. Renowned screenwriting teacher Syd Field recalled being booed off stage during a workshop in Paris when he posited structure as the necessary foundation of any screenplay. The French artistes were true romantics. Rules would only rob the creative process of its magic and yield unimaginative work. Hollywood does turn out plenty of clichés, but many great stories follow the rules of the game as Aristotle distilled them from the great Greek playwrights in his Poetics. Originality doesn’t suffer as a result.
Good programmers are not romantic creators who spurn rules and structures. They know that code cleanliness, predictable naming strategies and design patterns help creativity, not stifle it. But they also know that best practices alone cannot ignite the spark of inspiration. Rules guide us along the path, but they are not the recipe. Agile methods should be concerned with optimizing the conditions for creativity and they must allow for some rules to be malleable, even optional. Products are different, and so are company cultures and the people who work in them. If you respect that, hopefully the creative sparks will fly.
Syd Field, The Screenwriter’s Workbook. Page 27. Bantam Dell, 2006.
Opinions expressed by DZone contributors are their own.