Hi, Before everyone rushes off and reads Ludwig Fleck, Thomas Kuhn etc., it might be better to start with something like Boehm and Turner's book "Balancing Agility and Discipline" [1]. It contains a risk based model for choosing (and balancing) between agile and plan driven methods. Like most work from Boehm, its well worth a read.
Returning to Ruven's original story about development problems around a framework, I think the book "Extreme Programming in Action" by Lippert, Roock and Wolf [2] is relevant. In this book they draw attention to the way XP has been appropriated for types of development it was never designed for - (1) the development of application frameworks, (2) the development of eBusiness applications, (3) software product development, and (4) outsourcing. They also discuss some of the common work-arounds employed by companies who have appropriated XP for these. I'm not sure how this generalises to Scrum etc. For anyone interested in Kuhn, I'd suggest reading Sharrock and Read's [3] discussion of his work. It will help in avoiding some common misinterpretations of Kuhn - particularly the over emphasis put on paradigms and paradigm shifts (As we can see in this discussion, people tend to see just about anything as a paradigm). [1] Boehm, B., and Turner, R. 2004. Balancing Agility and Discipline Addison Wesley, Boston. [2] Lippert, M., Roock, S., and Wolf, H. 2002. Extreme Programming in Action. Practical Examples from Real World Projects John Wiley and Sons, New York. [3] Sharrock, W., Read, R. 2002. Kuhn: Philosopher of Scientific Revolution. Polity, Cambridge. I hope these suggestions are of interest. Regards, John. On 09/10/2007, Clendon Gibson <[EMAIL PROTECTED] > wrote: > > 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: discuss@ppig.org > 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 toput > 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 separat e 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]<[EMAIL PROTECTED]> > ] On Behalf Of Errol Thompson > Sent: Saturday, October 06, 2007 08:02 > To: discuss@ppig.org > 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. > >
