Agile's Creative Adaptation Can Be Exhausting

Image used under license from Freestock.com

No product of our human intellect, however ingenious, is immune to criticism. Especially if it’s ubiquitous, it will meet with disapproval somewhere. The way we apply Agile principles is a hotly debated topic, whereas the community generally stands by the original Agile Manifesto. Is it therefore a question of not doing things right, or might we not be doing the right thing? After all, large-scale projects still founder and software quality has not improved by leaps and bounds since 2001. 

The folks who make a living from training will never dismiss Agile that way. “You’re still not doing it right”. In the subgenre of how not to do it manuals I can warmly recommend Zombie Scrum Survival Guide, which charts the pitfalls well. The writers correctly note that complex problems don’t point you in the direction of a solution just by staring at them long enough (aka analysis paralysis). Much advice centers around the need for continuous adaptation and all that entails communication-wise. The traditional warning to measure twice before you use the saw makes sense for traditional engineering, but for innovative software projects a first-time right strategy is neither sensible, effective, or cheap. It’s mistakenly intuitive.

Originality is messy by nature and cannot be arrived at through a repeatable recipe, as I wrote before. Development is about creating original solutions to relatively novel problems. Writing new software to solve a copy of an existing scenario is reinventing the wheel. The Agile framework offers regular feedback moments to evaluate if the progress is headed in the right direction but cannot boost creativity itself. The original founders of the Manifesto knew this, thanks to their cumulative decades of experience with the unpredictable nature of creativity. What they could have done is stress more that this constant demand for coming up with inventive and adaptative solutions is itself a challenge. It’s more appealing in theory to be a fountain of inspiration than it is in practice. We pay lip service to it, while secretly craving a predictable process towards innovation. The agony of writer’s block isn’t coquettish exaggeration.

Practicing a craft is satisfying, especially when it has a predictable journey and beautiful destination, like ornamental plastering on a ceiling or making a violin from planks of wood. Writing code to detailed specifications can be delightful too. I can enjoy an afternoon picking apart some stranger’s spaghetti code, document it and make it testable. It does call for some originality, but it’s a different kind of challenge than, say, writing for this blog. Writing the first draft is often daunting. The fun is in refinement. Progress also highly depends on your concentration and state of mind. Despite your best efforts, some ideas prove more productive and popular than other.

We’re asking a lot of development team members. They must be involved in many more stages of a product’s lifecycle than just the writing of its code (especially in a DevOps setting). Business stakeholders must be in closer contact with technical people. There’s more communication going on, with more diverse coworkers. That requires soft skills you can’t pick up from a book or a classroom.

Working with the unpredictability of a creative process is not always fun. Nobody can be original for eight hours straight. Maybe that’s why we take refuge in Zombie Scrum and go through the motions during uninspired demos and retrospectives, hoping against hope that some good will come of it. Forget it: Agile is not a recipe.

It’s perhaps a disappointing lesson for some that a present-day developer writes a lot less code than she might wish. Some leave the craft and become managers, but blood is thicker than water. A long time ago (certainly pre-Agile) our team manager seized on a juicy programming task and shouted out with relish: Ah, life is sweet when there is a bit of coding to be done!