Agile Software Development

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of feedback emphasizes the belief in that requirements always change and/or are not well understood in the beginning of the project. Therefore the only way to build software the customer really needs is to continuously adjust the development basing on his feedback. Same goes to the technical level.

The biggest difference of agile methods from traditional waterfall is the short feedback loop. The whole concept of agility in essence is no more, than "build the most important piece, evaluate, adjust, and repeat". Automated tests in the agile methods serve as a very important tool for shortening the feedback loop.

In the most of traditional processes automated tests are mimicking the manual test procedures. The tests are often written not by the code developers. Tests usually involve testing the functionality of the whole system. Test results come to the original developers quite late and tests don't take into account the latest code changes. Automating functional and system tests is a good thing. It makes testing a little easier, more effective and saves some money for the company. However, it is no more, than automating a small piece of the manual labor.

Agile software development processes by any definition encourage the in- and-out team communication via various practices from pair-programming to informative workspace to retrospectives. With the respect to all the usual practices there is one more often underestimated way of getting the in-team feedback - the hallway testing. The term Hallway Usability Test coined by Joel Spolsky stands for "grabbing the next person that passes by in the hallway and forcing them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code."

All the agile software development processes are iterative. Iterations are used in order to release complete increments of software within predictable periods of time and get customer or pseudo-customer feedback early. Different processes recommend different iteration lengths. Scrum is very strict in this sense and requires exactly 30 calendar days long iterations. This period of time is considered being a typical amount of time that product owner can allow the team go independently without the external control. eXtreme Programming brings the idea of frequent customer feedback to the extreme level and advocates for shorter iterations down to one week long.