Agile development [closed]

Question

At university we talked about agile programming, but also how many agile methods aren't used in business, like pair programming.

I would like to know which methods belong to agile programming (extreme programming, pair programming) and which are really used / do you use. What about iterative and incremental development?

edit: to those who wanted to close that Question because of "subjective and argumentative". This question can be answered,because agile development is a defined expression. http://en.wikipedia.org/wiki/Agile_software_development. Further more many Users are interested in this Question, to close it isn't well considered

Answer 1

Agile development is not a methodology in itself, it's an umbrella term that describes several agile methodologies (that all belong to the Iterative and Incremental Development - IID - family).

alt text http://img62.imageshack.us/img62/6374/dd997578teamprojagileum.png

At the signing of the Agile Manifesto in 2001, the following methodologies were represented: eXtreme Programming (XP), Scrum, DSDM, Adaptive Software Development (ASD), Crystal, Feature-Driven Development (FDD), Pragmatic Programming. Each of them share the core values of the Agile Manifesto but implement them with a slightly different approach.

In contrast, pair programming is an engineering practice (it is one of the practices of XP which captures many practices as an indivisible set but you can use it outside of XP). And, while I value practices very much, just keep in mind that practices are not an end, they are just a mean as I wrote previously. Agile is not about doing pair programming, stand up meetings, etc. Agile is about maximizing the customer value while minimizing waste to provide the most optimal ROI. Agile is business oriented, practices are just a way to achieve this goal in a given context.

Scrum and XP (used together) are the most commonly used nowadays.

Answer 2

Sounds like you really want to know what people are actually using in the real world. There are plenty of sites about what is in and what is not an Agile practice/methodology.

So, my experience so far in my recent (last 5 years) roles:

1. Nobody used pair programming except in panic situations (major bug fix in zero time), managers still just don't buy into the idea at all - and I'm talking AT ALL, which is a shame as I quite like it.
2. User stories and users choosing a deck for next release - doesn't really work unless the users really really buy in, which I've not seen yet. Users in my area always say that everything is of top importance, they cannot live without any of it. I personally just rephrase into "what order should I personally work on these tasks in your opinion?".
3. Test driven dev - very little of this happens, but a lot of unit tests get written (after the code does though), so a near miss imho
4. Continuous integration - this is highly dependent on the team, in last 5 years all my teams had it, but it often lapsed (broken build) for days/weeks at a time before it got attention. A lot of people still don't buy into this.
5. Refactoring often - this is actually getting some serious buy-in. Refactoring is a skill that if you don't have is likely to be a serious problem.
6. Small releases - this (in my work) is generally the norm anyway, although probably being done
7. Coding standards - yes
8. Collective code ownership - blame is still pretty much rife, and often a "bad" module never really gets fixed cos the coder that produced it just fixes and fixes it till it "works".
9. No overtime - nearly, but highly dependent on the team lead - I've seen the worst stuff (death marches) going on within a few feet of my team...
10. Tests first when find bugs - this happens in my experience. Is a very good thing.