Hi all, In reading this thread about agile methods for managing software, I can't help but wonder if the point of the method has been lost. This might explain why people schooled in a particular method could still fail to get the benefits promised.
All methods are a set of heuristics to confront and manage the complex issues of software development. But what are the issues? It strikes me that a person who knows the method, but does not have a solid grasp of the issues the method is to address, will have a failing project. This would seem an easy state to arrive at. Any college student can read about Agile, but the same student will be hard pressed to have the raw experience necesarry to have the insight into why Agile works. More importantly, the student is unlikely to have the insight to know when a given method will work, and when it won't. It seems to me that a book styled like "The Myhical Man-Month", is more appropriate because it discusses the issues, while not making anything more then suggestion for how to handle them. The "ideal" method would most likely vary based on the managers experience, the resources available, and the goals of the project. I guess what I am saying is that the tool itself, whether Agile or another method, is blameless. Understanding when to use the tool, as well as how to use it is what really counts.Unless of course you have a sea of nails and one screwdriver. ----- Original Message ---- From: Hanania Salzer <[EMAIL PROTECTED]> To: [email protected] Sent: Saturday, October 6, 2007 3:45:13 AM Subject: RE: PPIG discuss: When agile goes bad.... Errol, you say that in the debate over agile methods some people fail to put aside their "own paradigm blinkers and seek to find maybe another framework for evaluating the solution". To continue along your line, I would add that both normal science and revolutionary science use the same rigor. Therefore, we have two issues here. (May I mention that my research revolves around occasional failure to identify and separate among issues…) - One is openness to the possibility that there are "other, equally valid and possibly challenging perspectives". - Another one is, that the alternative, potential perspectives should not be based on anecdotes alone, but mostly on scientific methods, which are, in this case, empiric ones. I presume that this segregation is in line with Kuhn’s SSR. Hanania Salzer, Tel-Aviv University, School of Education -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Errol Thompson Sent: Saturday, October 06, 2007 08:02 To: [email protected] Subject: RE: PPIG discuss: When agile goes bad.... From a quick look at the article, I would agree with many of its points. However, I would also suggest reading beyond our own domain and I am particularly thinking of Thomas Kuhn's (1996) work on Scientific Revolutions. A key issue there is how our paradigms for our field of research can close us off to other equally valid and possibly challenging perspectives. I don't want to reduce the rigour required in research but neither do I want to discard an alternative paradigm within my field without fully exploring its foundations and understanding whether it has anything to contribute. If I am to do this then I need to be able to put aside some of my own paradigm blinkers and seek to find maybe another framework for evaluating the solution. This what I would contend is not happening in the debate related to agile methods. Kuhn, T. S. (1996). The structure of scientific revolutions (3rd ed.). Chicago: University of Chicago.
