The first Extreme Programming project was started March 6, 1996. Extreme Programming is one of several popular Agile Processes. It has already been proven to be very successful at many companies of all different sizes and industries world wide.

Extreme Programming is successful because it stresses customer satisfaction. Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it. Extreme Programming empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.

Extreme Programming improves a software project in five essential ways;

communication, simplicity, feedback, respect, courage.

Extreme Programmers constantly communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. Every small success deepens their respect for the unique contributions of each and every team member. With this foundation Extreme Programmers are able to courageously respond to changing requirements and technology.

The Rules of Extreme Programming PlanningManagingDesigningCodingTesting

Our rules set expectations between team members but are not the end goal themselves. You will come to realize these rules define an environment that promotes team collaboration and empowerment, that is your goal.

Once achieved productive teamwork will continue even as rules are changed to fit your company's specific needs.

Agile software development is based on fundamental changes to what we

considered essential to software development ten years ago.The most important thing to know about Agile methods or processes is that there is no such thing. There are only Agile teams. The processes we describe as Agile are environments for a team to learn how to be Agile.

The biggest problem with software development is changing requirements. Agile processes accept the reality of change versus the hunt for complete, rigid specifications. There are domains where requirements can't change, but most projects have changing requirements. For most projects readily accepting changes can actually cost less than ensuring requirements will never change.

Agile also means a fundamental change in how we manage our projects. If working software is what you will deliver then measure your progress by how much you have right now. We will change our management style to be based on getting working software done a little at a time. The documents we used to create as project milestones may still be useful, just not as a measure of progress.

Surprise! Software Rots!Is software designed to be simple and elegant

more valuable than software that is complex and hard to maintain? An Agile process accepts this as an important fact.

It may surprise you to learn software rots. Intellectually we know it really doesn't, but it might as well. Software rot is caused by improper design and limited project resources. Complexity creeps in as easy code changes are made instead of difficult design changes. Code duplication accumulates rapidly during maintenance tasks.

Berry Boehm found that as software proceeded through its life cycle the cost of making a change became larger. Ratios of 100:1 for making a change after delivery versus project start are common. But ratios as low as 5:1 can be found. How flat this curve stays depends on many individual project factors.This cost curve is commonly interpreted to mean that you must create infallible requirements documents followed by complete, detailed, and error-free designs or pay a huge price later.

There are three life cycle events that seem to accelerate software rot. When we proclaim the design is done and accept no more changes.