On March 13, 1995 in Paris, during a press gathering held at a conference called Le cinéma vers son deuxième siècle, Danish filmmakers Lars von Trier and Thomas Vinterberg introduced a new artistic movement called Dogme 95. In the world of arts, this declaration is comparable to the Agile Manifesto in many ways; not only are they both contemporary, they are also a reaction to the current state of things in each of their respective industries.
In the case of Dogme 95, it was a reaction against the “Hollywoodisation” of movies; ignominously big budgets, “make it or break it” in the first weekend, the dictatorship of the box-office, the star system, and the consequent loss of depth and relevance of the movies produced.
The Dogme 95 manifesto contained a set of rules for movies to follow:
- Movies should be shot in location, not in studios, and without extra props.
- No music nor sound postproduction is allowed.
- Only handheld cameras must be used.
- No black and white movies; only color, and no extra lightning is allowed on set.
- No optical effects allowed during postproduction.
- No gratuitous action allowed: no murders, no firearms, etc.
- Films happen here and now; not in the past, not in the future.
- No genre movies allowed (western, science fiction, etc).
- Films must be shot using 35 mm film.
- The name of the director must not appear in the final credits.
The “Dogme 95 Collective”, also known as “Dogme Brethren”, that gathered around these ideas, produced 31 films following these guidelines between 1998 and 2005.
Interestingly, most of the films in the list violated one or many of the points above. Each filmmaker, following their own artistic license, deviated from those guidelines (or were they rules?) as they saw fit. Some Dogme 95 directors went as far as publishing a “confession” of the deviations they took from the manifesto, in order to finish their films, like in the case of “Mifunes sidste sang” (1999) by Søren Kragh-Jacobsen.
Were they doing Dogme 95 wrong? Hardly.
Art does not serve any purpose per se. Hence, it exists for its own sake, and thus, it is never wrong. It can be shocking, it can generate emotions, or it can be simply beautiful, without any other objective. Hence, any deviation from the Dogme 95 rules simply meant… not being included into the Dogme 95 movie list. Nothing else. Those movies could still receive awards, be shown on festivals, or even released as special BluRay boxed editions for Christmas.
But coding is very often considered an art. Why is it then, that an Agile software-making organization has to face that eternal Damocles Sword engraved with the Latin words Nefas facis?
This is one of the most disturbing phrases one team could ever hear: “You Are Doing Agile Wrong.” “This is not how you hold retrospectives.” “This is not a proper Kanban board.” “What would Kent Beck say of those tests.” And so on, and so forth.
In doing so, consultants and disgruntled developers join the ranks of Dogma. Not “Dogme” (see the “e” at the end of the word) but Dogma. A God-like contraption that holds unlimited power of life and death over the minds and actions of anyone involved in a programming team. A way to instill guilt, not helping in actually figuring out the deeper structural and communication problems that a team might be suffering from.
The idea of Dogma is that, by following it, there is a guarantee of success, order, and outcome. Of course, early successes makes followers become fanatical; and on top of that, rigid hierarchical social structures in corporations block the dynamic alignment of skills towards the resolution of problems, thereby preventing all deviation from Dogma.
Yet, in a mostly ironical turn of events, the Dogma of Agile advocates precisely for that: the dynamic alignment of skills towards the resolution of problems. That is, in essence, Agile.
Which means that the Dogma of Agile is, in essence, to avoid Dogmas. Yet, instead of remembering that, we have The Scaled Agile Framework® (SAFe®). Yes, there is a real trademark sign at the end of the name.
The root problem of SAFe is hypocrisy: SAFe works as a way to hide hierarchy behind the pretense of Agile. In essence, Agile was a cry against hypocrisy. So, instead of SAFe, if companies want to implement hierarchies for their software processes, they should just do it, and enjoy all of its caveats and advantages. Software produced under such conditions might be very rigid as per Conway’s Law, but it is totally possible for it to gain wide market acceptance, and to generate an interesting ROI; as the French say, personne n’est à l’abri du succès.
But please, do not even mention the word Agile; doing so risks turning the Dogma of Agile into nothing else and nothing more than a cargo cult.
History shows that hierarchical structures can be wildly successful when they embrace their hierarchy. So, who knows? Maybe a more rigid structure can enforce documentation production, stricter Q&A processes, better programming language choice guidelines, more architectural or design meetings, enforced code reviews, and more. Drop the crazy standup meeting, YAGNI. Maybe I am an older developer, but I could totally understand why companies would like to work like this.
Of course, due responsibility for failures should be acknowledged at the right levels, which in itself would be politically dangerous for career-minded managers, and this could be the demise of the structure itself. It is hard to cope with the hubris of a few well-placed individuals in a structure.
When a methodology (any methodology) becomes an objective per se, instead of a way to organize the production of working software, all hope is lost, and Agile is no more. Instead, it is the time of the Dogma of Agile.
Quoting Edsger Dijkstra:
The first effect of teaching a methodology-rather than disseminating knowledge-is that of enhancing the capacities of the already capable, thus magnifying the difference in intelligence. In a society in which the educational system is used as an instrument for the establishment of a homogenized culture, in which the cream is prevented from rising to the top, the education of competent programmers could be politically unpalatable.
(Dijkstra, Edsger W. 1972. “The Humble Programmer.” Communications of the ACM 15 (10): 859–66. https://doi.org/10.1145/355604.361591.)
Dijkstra’s words apply not only to country-sized political systems, but also to most social structures, from corporations to the smallest of teams therein.
Cover photo by Tingey Injury Law Firm on Unsplash.
