Extreme Programming is first introduced by Ken Becket in Chrysler Comprehension Compensation Project at 1996. It’s name comes from the fact that best practices should be applied to extreme level. These best practices in fact form base ground for Agile.
In agile, team collaboration and work style is considered to be single most important productivity improvement. Customer or domain expert should be in close contact to development team to yield easy feedback and fast answers to domain specific questions. Requirement change is considered as reality of world and whole software production framework should enable fast adaptation to possible requirement changes as needed. As a result, project management is now modified to enable regular release of working software.
In extreme programming, managers, customers and developers form a collaborative team to value simplicity, communication, feedback, respect and courage. Design is kept simple to reflect just to meet current requirements, not more. Team members should be in close, face-to face communication in order to work in harmony, and discover any ambiguities early. Development should be test driven, and highly controlled by unit tests. This permits early feedback if a change breaks the current code. Since customers are able to use these regularly provided working software releases, we are able to get very crucial feedback from domain users. Good test structure and feedback from customers, give courage to team in responding to changing requirements. They will be sure not to break anything or displease customers by making a change in their code. Managers should respect developers desire to accepting responsibility and receiving authority.
We start with managing goals, where our goals are the features of our product. We state our features and starting from most important ones, we begin to implement them. By this method, at any time we have working software with complete and tested features. User is able to add additional features and remove obsolete ones from backlog which means evolving requirements due to better opportunities and competitive advantage. Each feature is represented as a user story. User stories are small 3-5 sentence descriptive statements from customer point of view about desired feature, detailed only enough to enable a release time estimation.
When we face a technical challenge about a design issue or implementation detail, we may build some spike solutions to test which path to proceed. These spikes with user stories will form a somewhat iterative work to form a release planning. Release plan is important in the sense that it should be realistic and it should be agreed on by all involved parties, since these will form baseline for iteration plans and iterations.
Each iteration has an iteration plan which displays the amount of work to be done in that iteration. And this iteration plan is enhanced more in daily meetings, in which current tasks are discussed in short but somewhat more detailed manner. In these daily meetings developers quickly talk about challenges and achievements in order to synchronize with each other. This is important as in agile they will all be responsible from produced work. Daily meetings enable the team to keep in a sustainable pace. Developers should do at least one daily integration, which forces working with the latest code in the repository.
In iteration planing, it is important to be honest and make honest plans. Estimations should reflect to reality. It is expected to make some mistakes, and as long as new measures are taken in order to correct the path, this is ok. Making safe-side estimates in order to avoid mistakes will be much worse than making honest mistakes in the long term. Every team has a different pace, and timing estimates will be more correct, if they are given by the team with considering past experience. Iteration durations should be kept as short as possible up to point which enables meaningful additional features. Short iterations yield rapid release of working products, which will yield important feedback from customer. In extreme programing we rely on our ability to rapid adaptation to requirement changes which is only available from our done releases. A done software release at the end of iteration and, a possible demo of this release to product owner and customers, iteration retrospective and review will collectively form project heartbeat. In an healthy project, this should be strong and at a constant pace.
In extreme programming, team cohesion is one of the most important assets. Team members should have all communication channels open. This should avoid many errors before they are even coded, as in pair programming. Well written unit tests and acceptance tests, better let them be automated, will make team comfortable in the sense that they have continuous integration and they dont break anything. Pair negotiation, standup meetings, iteration plan and release plan, all make project well self controlled and coherent. Members will not be afraid to take critical actions because they know, they will not be blamed. In fact, in extreme programing, it is important that, people make critical decisions themselves on time, instead of delegating these to someone else. This is the only way to handle angst of frequently changing requirements.