Loading ...
Sorry, an error occurred while loading the content.

Re: The Dark Side of Agile - Request for Contribution

Expand Messages
  • marcodorantes
    ... 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
    Message 1 of 6 , Nov 11, 2012
    • 0 Attachment
      This is my take 2 on the survey:

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

      Thoughts?

      --- In extremeprogramming@yahoogroups.com, "marcodorantes" <marcodorantes@...> wrote:
      >
      > Let me also post here my responses for further discussion:
      >
      > Part 1
      > >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."?
      >
      > If "doing it" is removed then there are lesser chances to reflect, to inspect, and to adapt on the search for the specific business value —which often is a moving target— in a given context. Key parts of software development could be seen as epistemological endeavors; thus, if the empirical or experimental part is removed then the justification of the achieved business value could be dramatically diminished.
      >
      > >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"?
      >
      > If the processes and tools do not help for better communication between individuals then those processes and tools should not be followed or used. Instead, an open dialog among practitioners should define proper processes and tools that help them to practice their values and professional principles.
      >
      > >Do you think that instead of "Working software over comprehensive documentation" people tend to adopt "Working software and not comprehensive documentation"?
      >
      > The lack of a proper way to remember or to communicate relevant things to future or distant people is certainly a problem that should be solved in a project or product. That is a different problem than the problem of effort wasted in obscure and ineffective documents that nobody read. Besides, there is a plethora of recording technologies that could help to preserve and transmit relevant and valuable things about a project.
      >
      > >Do you think that instead of "Customer collaboration over contract negotiation" people tend to adopt "Customer collaboration and not contract negotiation"?
      >
      > And for that matter: who, on the face of the Earth, is going to listen to the end-user?
      >
      > >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"?
      >
      > If «a plan» no longer follows discovered and corroborated reality, then it is wise to make all sort of proactive adjustments or an entire new plan. The key to follow, of course, is not the outcome —a plan— but the frequent practice of planning. Conversely, blind reactions to whimsical moves, without awareness of the related costs, pave the path to diminished business value or business failure.
      >
      > >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."?
      >
      > A part of the problem is a psychological pattern of neglected interpretation. It is not, of course, something exclusive of agile methods but it is a pervasive lack of education that permeates politics, economics, and many more spheres of society. The root cause is a very, very poor foundation in important areas of life, whereas is it called science, philosophy, history, mathematics, ethics, etc.
      > What prevents us from learning a new concept is the preconception that usurps its place. See what Derek A. Muller has to say in the case of scientific concepts: youtu.be/eVtCO84MDj8
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.