I'll try be brief (time is precious) :) Gerhard wrote: >> You must be an Agile convert already. :) From the Principles of Agile >> Software: >> >> " Simplicity--the art of maximizing the amount of work not done--is >> essential." > > You mean this ? > > I was somewhat of an Agile convert before there was Agile :) Most of this > is not that new, and many developers in small groups have done most of > this > for a long time -- where appropriate, and as much as appropriate --, long > before Agile became a buzzword. That was my point exactly. Agile makes sense. >> I used to think this way too, but a guy from Boeing said that the best >> thing to do is to dive right into the project, without any formal >> documentation. When you have a highly iterative and interactive >> environment, you discover problems and inconsistencies very quickly. > > Well, yes, but I bet that this guy from Boeing doesn't pay for the > development. No, but his job is at stake (he's the project lead). And obviously he has the requirements, the team know where they're going -- why document the obvious? Document it if it needs to be documented, when you get there. > I'd like this guy see bidding on a complex software project in > this fashion... and then executing it with a satisfied customer at the end > (which means, among other things, within schedule and budget). The key is keeping the customer involved in the decision making. Among other things, making the customer realize that resources are limited and he needs to make choices (which features to keep, for one). > It's not only about problems and inconsistencies. Real-world projects have > schedule and budget constraints. You need to start out with a realistic > goal, otherwise much of the Agile effort will be wasted, too. Just because > you're going Agilely in the wrong direction doesn't guarantee a success :) Based on the above, I'm afraid you don't understand what Agile is about. :) Don't take this personally, use this as an opportunity to learn more about Agile -- the time investment will be worthwhile. > Agile is (among other things) about small iteration cycles. That's good; > make them as small as makes sense, but not smaller. (Now how small is that > exactly? :) As short as one week, and as long as 2 months. The "sweet spot" according to some is 2 weeks. Basically, whatever works for you -- and the Agile process can help you determine the answer to this question as well. Set your iteration cycle to two weeks. At the start of the next cycle, ask: "was this too short? too long? about right?" -- and adjust the length of the cycle accordingly. > But most customers don't really care that much about small > deliveries. While these are good in many aspects (and one of them is to > make sure the customer sees progress and remains confident), the > customer's > satisfaction comes only with the final delivery, of the full scope, within > budget and schedule. I strongly disagree. With Agile, the customer makes a list of features, and prioritizes them. Then you go down the list. Each iteration resulting in yet another feature. It's up to the customer to say, "OK -- that's enough" at any point in the project (even early), and he ends up with useful, *working* software. Agile helps avoid feature creep. With traditional development, the customer may end up with a pile of out-of-date documentation, and software with lots of features that don't work. > I need to make sure up front that I can meet the > final, full delivery within budget and schedule. This requires early scope > clarification (would you bid on a project without this?) and budget and > schedule estimates. How often do your estimates turn out to be correct? Agile recognizes that estimates are just educated guesses, which are often wrong -- and helps you deal with it. >I don't think a real-world project (government and > Boeing projects possibly don't qualify here :) works well without either > of > these. I'm sorry I cited an engineer from an actual company. :) In Boeing's defense, they are a private business (with a bottom line), which doesn't receive government subsidies, and has to compete against a rival that does. [snip] > I'm not saying there are no excesses in documentation. Of course there > are. > Boeing probably can afford to waste lots of money both on excessive > up-front documentation and on aimlessly developing in never ending small > Agile cycles, with a complete refactoring of the core of the system every > other month. I will take "never-ending small Agile cycles", each of which results in WORKING software, over any of the the waterfall methodologies, anyday. With traditional planning, you can spend 30% of the project planning -- all of that time, upfront. So on a nine-month project, after three months you'll have nothing to show, but a pile of paper. > But in most real-world development projects, scope clarification and > overall effort and schedule estimates up front make things easier for > everybody. Why do you think scope clarification and overall effort and schedule estimates are not part of Agile? > People have something to work towards. Just as they do with Agile. > I get this feedback a > lot; most developers don't like to plan, but like it when they know where > they stand in a plan (if the plan is a realistic one and gets adapted with > the progress of the project). Absolutely. [snip] > I often work with distributed teams... For me it's a rare (and expensive) > luxury to have everybody in the same room. There are a few goals that are > often contradicting each other: hire the good, the motivated people, get > the all in the same room, and do it all within budget. Usually I don't > have > the right people for the job in the neighborhood for a price the budget > can > afford, so I need to work differently. To some degree, I think this goes > for everybody. Say you are in Colorado, and meet this guy who's just the > right guy for an upcoming project of yours, but he's in Virginia and > doesn't want to move. And no really good guy available right now in your > vicinity for a reasonable amount... What you're saying sounds logical, but my limited experience with distributed development has for the most part been negative. I came to the same conclusion long before I became aware of the existence of Agile: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." It may cost less to relocate your company to a more populated area, or offer stronger incentives to the engineer to persuade him to move, than to engage in distributed development. Of course, that would be true if you value efficiency above other things, which as we both know is a rather controversial topic. ;-) > 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 :) If a bunch of smart, experienced programmers got together, and came up with a simple set of principles that they all agree work, wouldn't you want to at least investigate what their methodology is really about? You can label any set of useful principles "religion", and reject it on that basis. Vitaliy -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist