3

Looking at the contents of the manifesto, I do not see if fulfilling the definition of a manifesto which is enter image description here

The document details the principles but nowhere does it argument why those principles are valuable. For example "Individuals and interactions over processes and tools". Why? Why individuals and interactions over processes and tools?

4
  • ...why not individuals and interactions over processes and tools? Nov 26, 2021 at 8:57
  • So don't act like it shrugs. You have done precisely zero research beyond copying from the Manifesto. That is clear. You have not even referenced it correctly. You asked "why" and did it in such a way as to purposefully cast a dispersion on the intent. So my response is apt...why not? Why would we NOT focus on individuals over tools? Or let me rephrase..why would you want to focus on tools over individuals? Nov 28, 2021 at 22:58
  • To answer your question, I would focus on tools and processes because that produces more technical excelence Dec 2, 2021 at 18:22
  • 2
    ...and now we neatly expose the true intent of your question. A misguided and misunderstood rant against the Agile Manifesto for Software Development. Nowhere in history has a focus on process over interactions ever yielded more technical excellence, not even in the military where Special Forces focus on adaptability, interpersonal communication and resilience not on tools. Process is merely a technique to enable better interactions. When you understand, the Agile Manifesto may be for you. Of course it was written by engineers so they prob knew a thing or two... Dec 3, 2021 at 1:24

3 Answers 3

5

Cambridge Dictionary defines a manifesto as a statement of "beliefs, aims and policies". The Agile Manifesto for Software Development does indeed set out some beliefs and aims, while the history page on the website explains some of their rationale.

In spite of its URL, agilemanifesto.org is not and has never been "the agile manifesto"; it is a manifesto specifically for agile software development and it makes no claim to be a proposal or statement about agility in general. Organisational agility and agile methods had existed for at least a couple of decades before the "software" manifesto came along. Since its authors were appealing to IT professionals who were late adopters of the agile idea, labelling it a "manifesto" presumably helped get people's attention and suggested that radical change was needed.

3

Words rarely have just one meaning. A better definition for manifesto in this case would be

A manifesto is a published declaration of the intentions, motives, or views of the issuer [...]

The Agile manifesto represents the views of people that met in a ski resort in 2001 wanting to share their experience on alternatives to the documentation driven, heavyweight software development processes of the time (and unfortunately also of the present). They identified some common characteristics in their "lightweight" methods (although some didn't like that term) and that view is expressed in the Agile manifesto.

2

Language Usage is Generally Out of Scope

If you want to question the meaning of the word "manifesto," the correct place to do that would be the English Language & Usage Stack Exchange. PMSE is not the correct place to raise issues about language usage beyond framework terminology.

People and Processes: A Value Statement Supported by Articulated Principles

You're starting from a common-but-faulty set of assumptions about what the Manifesto for Agile Software Development is, and what it's saying. First of all, it is not a doctoral thesis, and doesn't attempt to be one. So, if you're looking for canonical citations for every line of the manifesto, you won't find it without doing a lot of your own research.

The manifesto is pretty clear about the fact that its values and principles were developed empirically:

We are uncovering better ways of developing software by doing it and helping others do it.

Nevertheless, it is a very internally-consistent document. Consider the following value statement and commentary (bold emphasis mine):

Individuals and interactions over processes and tools...[W]hile there is value in the items on the right, we value the items on the left more.

Furthermore, quite a number of supporting principles are clearly set forth in Principles behind the Agile Manifesto:

  • Business people and developers must work together daily throughout the project.

  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

  • The best architectures, requirements, and designs emerge from self-organizing teams.

All of these principles are clearly about both people and interactions. You may or may not agree with them, but since they are simply cited as principles rather than indisputable and exhaustively-researched facts they certainly provide a consistent set of principles which support the defined values.

Other Viewpoints and Approaches

There are certainly people, methodologies, frameworks, and organizations that don't agree or align with the Agile Manifesto, either in whole or in part. That doesn't invalidate the manifesto, nor does it make alternative approaches or viewpoints "wrong." However, from a purely pragmatic perspective, my own empirical experience is that a failure to embrace the values and principles of the manifesto (at least in its general outlines) leads to poor agile framework adoptions and even poorer outcomes that get blamed on "agile" as a failed silver bullet rather than on the failure to truly adopt its values and principles.

Plenty of project management frameworks value other things more highly than individuals and interactions, silo teams, and do "big, upfront planning" rather than emergent design. It's also true that 68% of IT projects fail. Whether or not this is causal is certainly debatable, but empirically I can say from personal experience that truly agile projects either succeed more often, or fail faster (which is often a perfectly valid and desirable business outcome).

You don't have to accept the manifesto's values and principles. You don't even have to agree that they are accurate, valuable, or insightful, or that its components are anything other than a collected set of opinions that have been widely embraced and largely stood the test of time. That's really all it is, and you should evaluate it within that context rather than trying to treat it as something it isn't, and was never designed to be.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.