Dark Manifesto for Agile Software Development. Take 2
In addition to this:
Do you think that instead of "We are uncovering better ways of developing software by doing it and helping others do it." people tend to adopt "We are uncovering the only ways of developing software teaching others."?
Yes, I have often seen a kind of indoctrination into the new «one and only true agile cult». But that is because people do not actually read and reflect on what writing software and agile are about. So the problem is radical dogmatism: people imposing unquestionable ideas over other people; that kind of dogmatism has the consequence you are contrasting. There is another kind of dogmatism that is chosen by an individual upon herself provisionally, as a stage in her apprentice path; about this look for ‘Shu-Ha-ri’ in the agile literature.
Do you think that instead of "Individuals and interactions over processes and tools" people tend to adopt "Individuals and interactions and not processes and tools"?
Yes, I have recently seen a development director that forced their teams to use Post-it on the wall whereas they have a fully functional development suite of wonderful tools to have a ‘single system of record’ of project reality; one consequence is that those teams now have two systems to keep in synchrony, wasting effort that could otherwise be in more useful activities.
Do you think that instead of "Working software over comprehensive documentation" people tend to adopt "Working software and not comprehensive documentation"?
I have seen no significant change with the problem of documentation. I still see much of both, too much ineffective documents and too little concise and useful forms of documents that help to communicate, and to preserve, important justifications of why the software is as it is.
Do you think that instead of "Customer collaboration over contract negotiation" people tend to adopt "Customer collaboration and not contract negotiation"?
I would be interested to see what might come out of such a tendency: "Customer collaboration and not contract negotiation". I still see too much protectionist focus on the terms of the contract, out of pure fear from both the customer and the provider. I would like to see more about designing value-streams that end at the end-user level.
Do you think that instead of "Responding to change over following a plan" people tend to adopt "Responding to change and not following a plan"?
I see that teams must respond to change but they do it in different ways depending of their context, and with different business consequences. Some, by contract restrictions, certainly must wait until the current plan ends; others, who provisioned proper contract clauses, can adapt to new business priorities more quickly. Many could respond to change quickly but also can break things more quickly; I still see fewer teams who are able to actually change quickly and not breaking a single feature at the same time.
Do you think that instead of "That is, while there is value in the items on the right, we value the items on the left more." people tend to adopt "That is, while since there is no value in the items on the right, we value only the items on the left."?
I think that we people fool ourselves into thinking that we understand something new without proper application of the tenets of critical thinking. We often fail to challenge properly our own presuppositions and then misread new concepts, relating them with what we already have in our memory; mere opinion is misinterpreted as knowledge. So, little or nothing new is actually learned. For example, an agile development process is seen as a sequence of steps or discrete iterations instead of an integrated set of value streams.