A well known derivatives trading firm actually uses this !!http://en.wikipedia.org/wiki/Scrum_(dev ... )Obviously the managers/management decided on it and employees hate it.

Obvious to who? I've coded with Agile techniques before and from an engineering perspective, I've found them to be both more enjoyable and effective than waterfall methods. When I became an engineering manager, they allowed me to more effectively defend my engineering team from unrealistic upper-management timelines and set more accurate timelines. Now we were using a slightly modified version of XP, but Scrum is based on many of the same principles.

Agile, XP, RUP are fads, they come and go. They are workarounds.They engender spaghetti code because all decisions are soo short-term. The design tends to be a dog's dinner. The solution is to have a good design, good poject managers and good software engineers. Not always possible to find such people. On the plus side, scrum gets otherwise reserved people to come of their box and this is good for team morale. I like the Spiral model. I hate XP's fundamental principles. Block UML design documents are the driver for us, like the drawing of a house you are going to build. With scrum, you may not get a house at the end of the day.

QuoteOriginally posted by: CuchulainnAgile, XP, RUP are fads, they come and go. They are workarounds.They engender spaghetti code because all decisions are soo short-term. The design tends to be a dog's dinner. The solution is to have a good design, good poject managers and good software engineers. Not always possible to find such people. On the plus side, scrum gets otherwise reserved people to come of their box and this is good for team morale.I both agree and disagree. It is critical to have good design, good PMs, and good engineers, and it's not always possible to find those people. Sometimes, even if you've found one, it can be hard to tell during the interview or hard to retain them after the hire.On the other hand, software engineering methods are fads until they aren't. OOP was considered a fad. Java was considered a fad. The 'Agile Manifesto' was signed in 2001. That's eight years of fad so far. It doesn't seem like it's dying out on its own anytime soon, so it would have to be replaced by something instead - and yet I don't see any new PM styles on the horizon.

We use it. I started liking it but now I'm not so sure. A lot of what Cuchulainn wrote is very true and I've experienced it myself.

it doesnt matter what methodology's being used. it's all people. like PapaJohns slogan "better ingredients - better pizza". if you have good people, they'll survice waterfalls and scrums and deliver a good product.

QuoteOriginally posted by: jawabeanit doesnt matter what methodology's being used. it's all people. like PapaJohns slogan "better ingredients - better pizza". if you have good people, they'll survice waterfalls and scrums and deliver a good product.So what's the conclusion about a good PM who chooses a particular methodology to run a project? Is he not a good PM because he chose a particular methodology, or did he waste time making the choice because methodology doesn't matter?

QuoteOriginally posted by: ThomasJSo what's the conclusion about a good PM who chooses a particular methodology to run a project? Is he not a good PM because he chose a particular methodology, or did he waste time making the choice because methodology doesn't matter?he's good PM not because of the methodology he chooses, but because of how he handles people, understands team dynamics, company politics, understands the business domain well enough, manages risks etc. these things have nothing to do with the methodology. i never cared of what methodology's used, it's the last thing i'm worried about. there was a time when i remembered what was M124 form in Method/1, it didn't have any effect - good or bad - on the quality of my code.

QuoteOriginally posted by: jawabeani never cared of what methodology's used, it's the last thing i'm worried about. there was a time when i remembered what was M124 form in Method/1, it didn't have any effect - good or bad - on the quality of my code.You don't care whether or not you're forced to do pair programming? You don't care whether or not your company requires unit tests to accompany all the code? You don't care whether you're in 8 hour meetings vs stand-up meetings? These are all part of the methodology selection for running a coding project.These choices clearly influence code quality. And even if for some reason you think they don't influence code quality, they clearly influence project timeline and therefore project success.

QuoteOriginally posted by: ThomasJYou don't care whether or not you're forced to do pair programming? You don't care whether or not your company requires unit tests to accompany all the code? You don't care whether you're in 8 hour meetings vs stand-up meetings? these things have nothing to do with methodology.nowhere in XP (which popularized it) it tells to force pair programming. i haven't seen a manager stupid enough to force it. personally, i like pair programming done sensibly. it's certainly is and have to be voluntary. i find pair programming very productive at times. unit tests are GOOD. i get frustrated when there's no time to write them. they're so helpful when refactoring or porting code.you won't see anywhere in RUP or "waterfall" clone or any other methodology to hold 8 hour meetings. they're not always bad, btw. i understand that you're referring to some waste-of-time meetings practice, but this belongs to management style or company practices. i doubt that you can have good developers and managers in that kind of environment. this brings me to my original point: i dont care about methodology, i do care about people. if a manager is an idiot, he can be Scrum master at the same time. all it takes is to attend a course and pass an exam. idiot is an idiot with or without methodology. a good manager with good developers produces good code under any methodology. i've been to many places, black belt 6 sigmas, iso 9000, CMM, waterfalls of many kinds, agile-shmagile crap - it was always about people: managers and coworkers.

QuoteOriginally posted by: jawabeanthese things have nothing to do with methodology.These things are explicitly addressed by Agile methodologies.Quotenowhere in XP (which popularized it) it tells to force pair programming. From http://www.extremeprogramming.org/rules.html: "All production code is pair programmed." I don't agree with this, and I don't use it on projects that I manage, but XP does specifically mandate it.Quoteunit tests are GOOD. i get frustrated when there's no time to write them. they're so helpful when refactoring or porting code.I agree. XP (and many other Agile methodologies) mandate that they be written before production code, and force the project to be managed such that they are built into the timeline, rather than writing them only when there's time.Quoteyou won't see anywhere in RUP or "waterfall" clone or any other methodology to hold 8 hour meetings. they're not always bad, btw. i understand that you're referring to some waste-of-time meetings practice, but this belongs to management style or company practices. i doubt that you can have good developers and managers in that kind of environment.OK, so I was using a bit of hyperbole with the 8 hours. But XP does mandate stand-up meetings which force the meetings to not go beyond 10 or 15 minutes.Quotethis brings me to my original point: i dont care about methodology, i do care about people. if a manager is an idiot, he can be Scrum master at the same time. all it takes is to attend a course and pass an exam. idiot is an idiot with or without methodology. a good manager with good developers produces good code under any methodology. i've been to many places, black belt 6 sigmas, iso 9000, CMM, waterfalls of many kinds, agile-shmagile crap - it was always about people: managers and coworkers.We're on the same page here. I just think that part of being a good PM is knowing when to adopt practices from Agile methodologies into your project, and I think that those Agile practices generally (but not always) have value. I think part of being a good coder is knowing when to adopt Agile coding practices like TDD or frequent integration into your daily routine. I agree that good engineers/managers are required, and I think one of the many things that makes engineers/managers good is knowing when these practices yield benefits, and what the trade-offs are in adopting them.

QuoteI agree that good engineers/managers are required, and I think one of the many things that makes engineers/managers good is knowing when these practices yield benefits, and what the trade-offs are in adopting them. In my experience good engineers tend to be good in software design (system decomposition, good interfaces, less is more, block diagrams ...) and their process quality seems to be built into their way of working. They tend to survive despite the process in many cases.Projects where the process takes centre-stage can be dangerous. It is possible to be CMM level whatever and still have a product that the customer/client hates. All the methods I mentioned are too IT focused and introverted. In 'good' projects, the 'process' tends to be in the background.

Quoteyou won't see anywhere in RUP or "waterfall" clone or any other methodology to hold 8 hour meetings. they're not always bad, btwtwo remarks:1. RUP is process-driven and there is no integration with SOFTWARE ARCHCITECTURE the last time I looked. I have heard more horror stories than otherwise. RUP was an enormous hype after the introduction of UML 0.8 (a subject that has spinoffs...)2. 8 hour meetings ==> something very wrong. On the other hand, short meetings !==> things are going well3. Where is the 'voice of the customer' in all these processes (do they 'scrum' or are they on the sidelines??)

"voice of the customer" or as it might be called "project owner" is the central role in Agile. In fact, so much central that the project owner can be overwhelmed with work (but not necessarily). Project owner is consulted with at every stage and can undergo a "learning process" herself about what exactly is needed to be implemented. It is suitable for situations where complete and consistent requirements might not be ready in advance. Or in a situation when the client might have changed her view on how it should work. Both cases are very abundant.And I would suggest that Agile or Scrum are less of a "process" comparing to many other methodologies.

QuoteOriginally posted by: jawabeanit doesnt matter what methodology's being used. it's all people. like PapaJohns slogan "better ingredients - better pizza". if you have good people, they'll survice waterfalls and scrums and deliver a good product.I would be probably not that strict, but I agree in principle. It was not really published widely, but there were comprehensive studies on productivity in sw development. With the scaring? range-result from 1 to approx 20 taking test persons with the same educational background.I want to add one thing: as manager of sw teams it is vital that you understand not only the capabilities but also the "temperament" of your team members and support (and never break) their authenticity (from the abstract astronauts to the accountants?).You might not create a winning team if you form a soccer team with 10 Ronaldos? p.s. I remember a project performed by 2 top programmers with, IMO, complementary temperaments. They rather spontaneously built a programmer-pair when writing a special Modula 2 compiler and a compiler-compiler (guidance of Niklas Wirth). With incredible productivity. When? Mid 80ies.