Previously published on DZone

In a recent article titled Why Do Many Developers Consider Scrum to Be an Evil Scam, Scrum consultant Willem-Jan Ageling bemoaned the clear impression that people outside his professional circle didn’t share the same devotion to the framework, “I am a Scrum enthusiast. When I’m in my Agile bubble, I have the pleasure of having great conversations. We may have different opinions about approaches, but in the end, we mostly agree on the merits of Agile and Scrum. But when I leave my bubble, I often receive backlash. The worst thing I have been called is a snake oil salesman, selling an evil scam”.

I won’t unpick his arguments in detail. I don’t think Scrum is an evil scam and I don’t think Mr Ageling is a snake oil salesman. Yet I have seen Scrum being misapplied too often to ever become an enthusiast again. Here are my very personal reasons, based on first-hand evidence. It’s biased, but then I don’t pretend to speak for ‘many’ developers, let alone all.

Continue reading →

Previously published on DZone

I like reading books about corporate dysfunction when they come in the shape of a compelling (fictional) narrative. Business writers know how storytelling can spice up dry theory and support their argument. Patrick Lencioni’s The Five Dysfunctions of a Team and Gene Kim’s Unicorn and Phoenix projects are good examples. It works for popular science too. In Snakes in Suits, psychologist Robert Hare, a renowned authority on psychopathy, explains for a lay readership the manifestations and biological foundations of this dark human design flaw. He interweaves the science with a chilling fictional narrative of a parasitic young suit slithering his way up the corporate ladder. So, when a coworker told me the other day about an especially glib colleague who lied, cheated, charmed, and flunked his way to job security, I immediately thought: psycho!

In software, any rule or recommendation, whether it’s the Law of Demeter, SOLID principles, or the Agile Manifesto is the distillation of years of experience, spirited discussion, and plenty of compromises. Observing how teams work has led us to certain recommendations that boil the specific down to the generic. Stories are a wonderful aid to explain and justify such rules because they can show how the rules were arrived at in the first place. They supply the back story that reconnects the specific back to the generic. You need these to know and respect the justifications behind a principle. It’s not enough to learn a rule by heart if you want to apply it well. Concise lists of opinionated statements make for pithy posters, but the necessary back story is missing from the text. 

Continue reading →

The seventeen participants could not have predicted the success of their collective weekend brainstorm in February of 2001 that resulted in the Agile Manifesto. Their recommendations have held sway over common thinking about software development since then. Scrum saw the light in 1995, but cleverly hitched a ride on Agile’s bandwagon to the point that many consider the two one and the same. Many young developers have never known a different way of working in their professional careers.

But the spirit of Agile is becoming a dead letter. Coaches complain that most organisations do as they please. They explain in their blogs and books how true Agile should be practised. Developers grumble too, but rather because the enthusiasm over a better way of working has turned into going through the motions, rigidly and uninspired. What’s going on? Didn’t the Manifesto stand for careful deliberation and adaptation?

Continue reading →

(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.

Continue reading →