Vitaliy wrote: > You misunderstood what I said. > > With Agile, you still define those things with the customer. You know that > you're working with limited resources, so you rank the features (with > customer's help) in order of priority, considering cost/benefit of each > feature, etc. You end up with a Users Guide, a requirement spec, whatever > else you end up with that you use for quoting. > > With traditional "waterfall" development, I wrote a whole bunch, then I decided to take a step back, go straight to the roots and have a look at the Agile Manifesto . If this is what we're talking about... things are different. And so I deleted most of it... :) I agree with everything that's said there -- but nowhere in there is said that a waterfall methodology may not be the best and most suitable one in a given situation :) The Agile Manifesto makes a lot of sense -- because it is kept very generic. That also makes that deriving any specific structure or organization technique from it is quite difficult. Part of my confusion came from you citing specific techniques and labeling them as "Agile". They may be -- but so may be any number of other techniques. There is no single technique and organization structure that's natively Agile (in the sense of the original manifesto) -- and there's none that's by definition not Agile, at least according to this manifest. > With Agile, you have short development cycles (usually 2 weeks). You pick a > set of tasks (or just a single task) that you can complete in one iteration. > Each iteration includes test & debug phase, so at the end of the two weeks > you end up with fully functional, tested and debugged software. Hm... including a manual for it, an installer for it (possibly for all three layers), and software that moves over the existing customer data? The way you describe only works for /very/ small projects, or projects where /very/ few people work on. > Whatever the reason, you give the customer SOFTWARE THAT WORKS. In theory, maybe -- but even then only with incomplete theory :) One thing is what Nate is talking about in his response. The definition of "software that works" can be quite a bit different from the standard desktop software case. But even if it doesn't go to such lengths as in the telco business, must business software has specific interface requirements, and half working in that respect is usually not working. E.g. a billing system that's half working (that is, implements fully some of the billing rules) will generally be considered not usable at all. > --> By the way, another advantage of Agile is that you can ship the product > early (whenever you decide that the feature set is sufficient). In the > meantime, you continue development and implement those fun and exotic > features you wanted to implement from the start. This is not Agile, this is plain common sense. If you have this freedom and the architecture and requirements allow it without adding much to the cost, that's how you work to minimize the risk, even when working with a waterfall model. But that's what I've been doing 20 years ago when possible (and I'm sure I wasn't the only one -- it's not something I'm considering especially smart, more like obvious :). > What does "right" mean to you? All agreed-upon features, on schedule, within budget, client happy, programmers/engineers happy, me happy :) > The comments you make about Agile, of course. I think you're confusing Agile > with a twisted version of XP. You're right, I confused them a bit. OTOH, it seems you brought in some confusion, too -- at least I can't follow how you derive that the waterfall method is /not/ in accordance with the Agile Manifesto, if applied appropriately. There's nothing in the waterfall methodology that says that it can't be applied to sub-projects. > Who are those programmers? Which post-Agile movements? This is all nice, but then there's the question how in accordance with the Agile Manifesto it is to spend that much on defining management techniques :) > I'm yet to hear you offer an alternative methodology. What works for you, > personally? How do you approach a project? Depends a lot -- how big, how long, what kind of customer, whether I'm more a partner or a service provider or selling a product, and so on. > What do you think works for other programmers? Depends a lot, on the programmer, the team and the project, at least -- and often on the client, too. I've worked with programmers that I had to shield completely from client contact in one project, while in another I could let the same guy handle 80% of the client contact. That's what I meant with "flexible" -- IME it depends a lot on the specific circumstances. >> For Agile, two of the requirements that kill it for me in most cases are >> the physical proximity of the team members > > That makes it more difficult, but certainly not impossible. Again... the manifesto is so generic that almost everything can be fit in there. Which makes it difficult to talk about "Agile". [Gerhard in reply to Vitaly, 4/14] >>>> Rather than "Agile", I prefer "flexible" (note the lower-case "f" and >>>> the upper-case "A"; I think it's the case that makes a religion, not >>>> a deity -- everything and everybody can become a deity :) [Vitaly in reply to Gerhard, 4/14] >>> You can label any set of useful principles "religion", and reject it on >>> that basis. [Gerhard in reply to Vitaly, 4/14] >> Maybe you're getting a bit defensive here. I marked my respective comment >> with a smiley, it was in a tongue-in-cheek context from a previous message >> -- and I never said I rejected Agile, much less that I do it because I >> could label it as "religion". > > It was Nate who said: "Welcome to the church. Agile is just another > methodology/religion." The sentence above was my reply to his statement > (which you echoed). I'm not paranoid. :) Hm... see the dates added to the citations above. When you wrote that >>> text, it was right below the cited >>>> text :) > However, some methodologies are better than others. I still fail to see a /methodology/ in the Agile Manifesto. It's a few good thoughts, but they don't imply (or disqualify) any specific methodology -- if it is applied with the proverbial grain of salt. Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist