Ruven, They may be true stories but from my reading of the agile literature, I would see that the practices represented in the stories would be regarded as inaccurate representations of agile practice. In the most recent, you had "code for today". How can that be interpreted. The coders decided without consultation with the customer as to what was good to program today. Yes, I agree a bad practice. The naming is clearly designed to be critical of agile practices without wanting to look at any rigour or cross checks that might be in those practices. If what was selected as the stories for this iteration or today's coding where based on the priorities and risk factors worked out with the customer, is it still agile practice? Would this ensure that the project had some focus to deliver something of "benefit to the customer"? There were other aspects of the story that showed a lack of understanding of agile practices and how they may be applied to ensure maintainable design. The thing is that any development practice can have disaster stories told that reflect badly on the practices. Also having been on commercial projects that have used upfront design strategies and agile practices, I have come to see the strengths and weaknesses of these approaches. I have used some of these stories in my own teaching to emphasise why we want practices that will address these issues. My preference is clearly agile. It is also clear to me that many upfront design projects would benefit from the use of some agile practices such as behaviour-driven development or refactoring. Too many of the design upfront projects that I have been involved with have only come to completion because the programmers changed the design so it worked. They often floundered in maintenance because of duplicate coding and the lack of refactoring. They also ended up with redundant documentation that no longer reflected the operating code often because the designers had moved on to other projects or parts of the project and didn't want to talk with the programmers. Whose fault was this? No doubt the programmers, the designers, the analysts, the project managers, the changing requirements, the ...
In this message you say "From the point of view of nearly all of the writing in the agile world, the statement that "indeed different organizations have different needs" would be considered heresy, much less something that one could go ahead and stipulate." From what I understand of agile methods, they are tailored for each project based on the client's and the project's requirements. Yes, there are some core practices but the team has flexibility to tailor the practices and tool set to meet the project requirements. Schwaber may not say that Scrum is unsuitable for some organisations but I am equally sure that he doesn't say that Scrum should be implemented identically in all organisations. Sure there are some core practices that they would want to see in all projects. Let's stop knocking others because their paradigm of software development doesn't fit ours and look at ways of learning from each other's strengths and seeing our weaknesses. I say this because I quite like some of the model-driven ideas but I would like to temper their thinking with some test or behaviour driven ideas. Isn't there something to be gained by having a well modelled system that is also proven with a solid set of automated tests that can be updated and reapplied each time a system change is requested. Yes, let us not forget that software spends most of its life in maintenance and not in development. So what happens if we produce development methods that focus on maintainable software rather than on development. In my research into software development (yet to be published), a high percentage of those I interviewed saw design quality and maintainability as the critical aspects in software development. Many of these people also talked of using some agile practices to help achieve those objectives. Let us not be blind to the possibilities presented by alternative paradigms to our own. --------------------------- Errol Thompson Massey University PO Box 756 Wellington 6140 Phone +64 4 801 2794 x 6531 Mobile: +64 21 210 1662 Home: +64 4 938 5069 Skype: Kiwielt MSN: [EMAIL PROTECTED] Email: [EMAIL PROTECTED] Web: www.teach.thompsonz.net --------------------------- ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruven E Brooks Sent: Thursday, 4 October 2007 11:27 p.m. To: discuss@ppig.org Subject: Re: PPIG discuss: When agile goes bad.... [EMAIL PROTECTED] wrote on 10/02/2007 01:40:08 PM: > > I'm confused by the point of these anecdotes. Is there some study > that backs up these stories? > > Without defending the pros and cons of these (so called) agile > methodolgies we can stipulate that indeed different orginaztions have > different needs. However, these anecdotes come across as an attack on > non-formal methodologies and not a careful study of when and where > orginaztions need to apply different methodologies. > > Frankly, it seems just an attempt to troll for controversy. Any > methodology has aspects that can be abused. > > Cheers, > Chris Dean The "stories" are true stories, things that actually happened. If need be, I could have an outside auditor in to verify that. As things that actually happened in the real world, they're probably far better data than you'd get out of most controlled studies. From the point of view of nearly all of the writing in the agile world, the statement that "indeed different organizations have different needs" would be considered heresy, much less something that one could go ahead and stipulate. I've been reading "Agile Project Management with Scrum" by Ken Schwaber. No where does it say that SCRUM might be unsuitable for some organizations; in fact, it attempts to suggest that when SCRUM fails, it probably is due to inadequate training (Chapter 3). Before we can do our "careful study of when and where organizations need to apply different methodologies," there has to be some awareness that this is, in fact, worth doing, because methodologies do, in fact, fail. It's also useful to have some real world data on which to base theories of methodology suitability. I offer my "stories" as serving both purposes. Ruven Brooks ---------------------------------------------------------------------- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/