Maybe, it is time to reconsider our love with Agile Manifesto

Agile Manifesto is accepted as the main reference to agile mindset. Some people believe in the manifesto as the “holy grail” for successful software development (Hohl, et al., 2018),  Moreover, there is an assumption that agile principles are sacrosanct and there exists a tendency to add practices to resolve problems that arise in specific contexts as an appropriate solution (Rolland, 2016) without changing the “sacrosanct” part of it. 

Bad news; there are some widespread assumptions, accompanying limitations and context dependencies underlying the Agile development including Agile Manifesto. Addition to them, the manifesto has some imperfections such as:

• It was designed about two decades ago. As it mentions, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. However, within such a “regular interval” or not, during almost two decades, there is no intention to revisit the manifesto by its authors (Hohl, et al., 2018).
• The manifesto is developer-focused and developer-minded. For instance, there are obsessive “working software” expressions as a clear sing of developer point of view. Even though the manifesto states that “Business people and developers must work together daily throughout the project… The sponsors, developers, and users should be able to maintain a constant pace indefinitely”, the manifesto authors does not include any people from the business side. Thus, the development of the manifesto with the business point of view based on an agreed “Definition of Done” is missing.
• Agility is not only a right of a certain zone or organizations of a certain size or kind. However, the manifesto was designed for relatively smaller teams (as stated by its author, Dave Thomas (2015)), resulting in a “comfort zone”. Then, it fits and is most likely to succeed only within its own “home ground” (Barry and Turner, 2004).
• It has not been developed with a pure agile mindset providing the full power of agility. Instead of providing pure of agility, there are views to the manifesto as the packaging and structure of certain earlier concepts, with new terminology (Meyer, 2014) and as a reaction to elder development models.
• Agile Manifesto uses Hegel’s dialectics” as a leverage; it relies on a contradictory between opposing sides. It have generally and not surprisingly been seen as the contrary to traditional (heavyweight, disciplined, predictive, plan-driven) approaches due to its “binary coding” (Janes and Succi, 2012), which is not a pure requirement of being agile, instead of defining itself independently and originally. This case emerges “black and white” segregation and creates a dual polarization between these two edges. As a result, “the left hand side” expunges “the right side” of the manifesto by overriding it (Janes and Succi, 2012).
• Some statements named as principles in the manifesto are not principles rather they are assertions or practices. P(rinciple)6 is a kind of practice and assertion that is falsifiable (the false case is also possible; the most efficient and effective method of conveying information to and within a development team may not be face-to-face conversation). Similarly, P7, P9, P11 are assertions. In P10, definition of simplicity is wrong, it rather defines something else (Meyer, 2014).
• It is a tool they propose to achieve agility. The paradox is that the blind loyalty to the manifesto, is, at least, inconsistent with the first value of the manifesto. Any determinism or so called as formalism implies that their formalism can work for all context variations of us. However, what the manifesto proposes cannot react to variations in contexts of millions and violates its own fourth value; Responding to change over following a plan (or any deterministic form).
• The notion of “software” in the manifesto does not provide the full frame. An IT delivery to the users usually covers an entire solution that can include software, hardware, service or a combination of them, along with the supporting documents, trainings etc.
• People do plans, always, at strategic, tactic and operational levels, even for gathering to discuss about agile manifesto in a ski-resort. The plan is revised, if necessary, according to the real situations happening. In general, planning serves as a bridge between present and future time and people cannot live even their daily lives without this bridge. “Responding to change” can be possible by “following a plan” that is live and adaptive. This is what people do as a necessary part of the life and why the fourth value of the manifesto is logically wrong.

Maybe, it is time to reconsider our love with the manifesto. Such issues may (and hopefully) lead to questioning it in terms of providing “the real and pure agility”. At least, there are some rooms for improvements in the language adopted in the manifesto. We further need to normalize its biased position, springing from its radical approach to the traditional wisdom. Such radical initiation would not probably come from the original authors as some of them have stopped focusing on the future trends of the manifesto (Hohl, et al., 2018). Or, we should continue our agility journey by focusing on people and fundamental principles beyond the manifesto, binary thinking, determinism and dogmatism. I remind that agility is not a monopoly of a certain coterie but a common property of the whole community. If it is believed that agility is a need for all organizations, the responsibility of improving agility should belong to the whole community, even though such a work is not an easy task.

Or, for the author copy: https://www.researchgate.net/publication/337323304_Imperfections_Underlying_the_Manifesto_for_Agile_Software_Development