"Rolf" wrote: [snip] Rolf, thank you for the background, it is very interesting. What I know about Agile comes from an Agile "bootcamp" I attended about two years ago, the books on Agile that I've read since, and (somewhat limited) experience applying it at work. IANAE, but I do know a thing or two about Agile, and it sounds like when you say "agile", you mean something else. > When we investigated agile programming we found that it was likely not > going to fit with our 'culture' because it would actually reduce > flexibility as we have to regularly switch from development to support > roles, interspersed with customer interaction and other diversions. Switching between roles is not a problem for Agile. It is expected that interruptions will occur, and an attempt is made to make the weekly/biweekly estimates take them into account. Even combining part time/full time people is not a problem. Customer interaction is a must for Agile. Otherwise, you risk delivering a product that does not meet the customer's needs. > On the other hand, we have a couple of 'Agile' teams that were put > together to fulfill specific client functionality where there was no > existing support for that in the current business solutions. These Agile > teams were assembled and then sequestered from the rest of us so as not > to be distracted (actually, a couple of them play opera music to keep > the pressure down, and we kicked them out because we don't like opera... > ;-). You say the Agile team was "sequestered", do you mean that before you were all in the same room? That's actually what agilists recommend: instead of every programmer having their own office, they should work as close together as possible, preferably in a "bullpen" environment. The goal is to reduce the cost of interaction. > Still the one team is still going after 2 years, hardly 'Agile'. I believe this is one of many Agile myths. There's nothing inherent about Agile that limits the duration or scope of the project. > And worse, the product they developed has won all sorts of awards, and > is well regarded in the financial industry, This is consistent with a survey that DDJ did in 2007: teams using Agile report a higher success rate than traditional teams. > unfortunately it is a bugger > to integrate with the rest of the system. What do you think makes it so? > Development is scheduled from a business-functionality perspective (e.g. > we need to build a Credit Risk Assessment strategy to calculate Risk > Metrics on 'Toxic Mortgage Backed Assets'). The Finance Guru's will > build models of what calculations need to happen (about 30% of our > company has a phd, and many have 2 - not bad for 'programmers'), and the > process will be broken down in to what data needs to be available, etc. > From that point on a project manager will be assigned the > responsibility of ensuring the software can produce the correct metrics, > and will then start the battle of getting dozens of teams to schedule > time to actually ensure that the databases, middleware, reporting > frontends, calculation engines, etc. can actually process the data > coherently. What you describe sounds like the traditional waterfall model: you gather the requirements, then you do the design (on paper), then you implement, and the final step (not mentioned above) is to test. Sounds good in theory (to some, to others not so [1]), but as far as I know, the waterfall model never works in practice. I'm going to make a few guesses about the way things work at your company. - For example, I bet that the Finance Gurus don't simply build the models, and throw them over the wall. They interact with the people who are actually going to implement the models, right up to the end of the project. - Also, you don't build the whole thing all at once, you build it in pieces, and test each piece. Then you make more changes, and test the pieces again. - You routinely revise your assumptions and requirements throughout the duration of the project. Am I right? My point is (in case anyone missed it :) that waterfall development methodology does not work, and that Agile tends to fit the "natural" model of how programmers work, better. > Agile development would put together a smallish team to work on the > whole thing from beginning to end with mini milestones, etc. This would > not work for us because we often need to get many dozens of people > co-ordinated to get the functionality available in many components that > need to be backward compatible for hundreds of other Risk-Management > processes. - The first statement is another myth. Agile is scaleable, even though best results are achieved in small teams. I've read about projects which were completed by dozens of geographically dispersed Agile teams (hundreds of people). It is possible to have several "layers", where for example "product owners", one from each team, have their own weekly meeting to coordinate the higher-level efforts. The way it works is the same way you would naturally break down a large project: by system, by component, by subcomponent, by feature. - "Milestones" are not an agile concept, it is something you hear about a lot in waterfall-type projects. Agile has the concept of "iteration": a short, fixed length of time, at the end of which you must have working software. Working software, because "code does not lie". Documentation on the progress of the project often does. > Basically the scale of development, testing, integration, and regression > management preclude any one (small) team of people from having the time > to learn what they need to know to get the job done. Imagine this: you have your team of, say, ten people working on a small subset of functionality. There are several other teams that are working on other subsets. You have short meetings (30 minutes to an hour) once every two weeks to look at, and prioritize the task list. Your team has a "product owner" -- basically, a delegate from your team who meets with delegates from the other teams, to coordinate the higher level task list. If necessary, this team of product owners can send its own delegate to a yet another higher level meeting. You may say this sounds ridiculous, but consider that with a team size of 10 the three levels can coordinate the work of 1000 programmers. If your company only has 100 people, you only need one extra "layer". Most small companies only need one. > While there are people > in the company that could replace me (and I them), a 'fresh' Agile team > would take years to gain the collective experience of a bunch of people > to get the task done, and not also run in to all sorts of compatibility, > regulatory and other issues. Your assumption is that you can't use existing people who share this collective experience, to form Agile teams. Are there any reasons for this, besides people's natural resistance to "new" ideas? > An agile team will fail if it is required to disintegrate routinely to > work on unrelated maintenance tasks. That's basically why it would not > (does not) fly really well in the areas i work. Has this been tried at your company? I don't understand why an agile team would be different from any other team in this regard. > Still, there are times when we need to build (small) new pograms that do > whizz-bang things, and we get to do the especially fun stuff of rapid > prototype development, and then it is close to 'Agile'. Size does not seem to matter, agile processes still turn out to be more efficient. > For the record, we got a new 'chief' recently up top at work, and his > philosophy is that maintenance is not much fun, we should all be doing > agile type development, and we should outsource the maintenance to > Estonia. Personally I think it would be a mistake because maintenance > should be the responsibility of the developer if only to ensure that > they develop maintainable code ... ;-). I agree with you, you have to eat your own dog food, not feed the Estonians. I would further suggest that your company should adopt the Test Driven Development (TDD) approach (another "Agile" thing) With TDD, you create a scaffolding around your code, so that if you break something while fixing something else, you know it right away. TDD people say that you're supposed to write the test first, run the program to make sure the test fails, then write the code that the test will test. Not too long ago Timothy J Weber and I talked about ways to make it work for embedded development: [EE] Test driven design for embedded applications I'll admit I haven't tried it yet, although recent bug reports give me plenty of reasons why I should. :) In conclusion, if you haven't really looked at Agile, you definitely should. It can save you tons of wasted effort, and help you produce a quality product with features that your customers actually find useful. Vitaliy [1] http://en.wikipedia.org/wiki/Agile_software_development#cite_note-0 ^ Gerald M. Weinberg: We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's ServiceBureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell, indistinguishable from XP. [. . .] All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for "software development. quoted in Larman, Craig; Victor R. Basili (June 2003). "Iterative and Incremental Development: A Brief History" (pdf). Computer 36 (No. 6): pp 47-56. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist