Why do we need a change?

1. Project Risks are very high with the current approaches.  

2. Often Projects face unpredictable or rapidly changing requirements.  

3. Organization needs to embrace the client requirement changes

4. Often quality is a trade-off with meeting the deadlines 

5. A single person owns a Project, making the organization completely depend on him/her with that project.  

6. Absence of Standard Software development practices makes duplicate efforts across the projects, thus wasting useful resources. 
 

Agile Software Development 
 

It is a method of attempting to minimize risks by developing software in small time boxes called iterations. Iteration is like a miniature project by itself, which includes all the software development lifecycle properties such as Planning, Requirement Analysis, Design, Develop, Deploy and Documentation.  Agile Methodology emphasize on real-time communication, face-to-face, rather on written documents.  
 
 

Extreme Programming (XP)

What is XP?

XP is an agile software development methodology created to help developers design and build software that effectively meets user expectation. It includes a set of values, principles and practices for rapidly developing high quality software that provides the highest value for the customer and in the fastest way possible. XP is extreme in the sense that it takes 12 well-known software development best practices to their logical extremes.

Implementing XP in our organization in phases can resolve all the issues we face currently with our structure and methodology.

XP Values

XP recognizes basically four values. They are:

A new fifth value had been added in the second edition of XP book by its author, 
    5.   Respect 
 

Communication 
 

Building software systems requires communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation. Extreme Programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, Extreme Programming favors simple designs, metaphor, collaboration of users and programmers, frequent verbal communication and feedback. 
 

Simplicity 
 

Extreme Programming encourages starting with the simplest solution and refactoring to better ones. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that may change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed. Related to the "communication" value, simplicity in design and coding should improve the (quality of) communication. A simple design with very simple code can be easily understood by every programmer in the team. 
 

Feedback 
 

Extreme Programming, feedback relates to different dimensions of the system development: 
 

a. Feedback from the system: by writing unit tests the programmers have direct feedback from the state of the system after implementing changes. 

b. Feedback from the customer: The functional tests (Acceptance tests) are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development.   

c. Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement.  
 

Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements (user stories). According to Kent Beck, one of the founders of XP methodologies, "Optimism is an occupational hazard of programming, feedback is the treatment." 
 

Courage 
 

Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary. This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage knows when to throw code away. Every programmer has experienced getting stuck on a complex problem in their own design and code after working on it all day, then coming back the next day with a clear and fresh view and rapidly solving the problem in half an hour. 
 

Respect 
 

The respect value manifests in several ways. In Extreme Programming, team members respect each other because programmers never commit changes that break compilation, that make existing unit tests fail, or that otherwise delay the work of their peers. Members respect their work by always striving for high quality and seeking for the best design for the solution at hand through refactoring.
 

XP Practices 
 

1. The Planning Game

Business and development cooperate to produce the maximum business values as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same:

2. Small Releases: 

Start with the smallest useful feature set. Release early and often, adding a few features each time.  

3. System Metaphor: 

Each project has an organizing metaphor, which provides an easy to remember naming convention. 

4. Simple Design: 

Always use the simplest possible design that gets the job done. 

5. Continuous Testing: 

Before programmers add a feature they write a test for it. There are two types of flavors. 

6. Refactoring: 

Refactor out any duplicate code generated in a coding session. Since there are unit tests for everything, programmers can do refactoring with confidence. 

7. Pair Programming: 

All production code is written by two programmers sitting at one computer. Essentially all code is reviewed as it is written.  

Two programmers working side-by-side, collaborating on the same design, algorithm, code or test. One programmer, the driver, has control of the key/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver and identifies tactical defects and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software.

Advantages

Pair programming can produce high quality products with in a short time than a single person working on the same problem. The best part is, it shares the knowledge and allows all the members of the team to contribute equally. Since there is another person involved with the development always, chances of making errors are very poor. Also it forces the programmer to convey the right thing with confidence. For the organization this gives a big advantage in the event of a developer leaving the job. According to Kent Beck, “The more different pairs that can work together productively, the lower the project risk”. This is one of our organizational objectives in adopting XP.

Disadvantages

Many times it is difficult to bring the other person along when you are pair programming. Pair programming works only if the personalities match each other. It needs a lot of patience and social skills to succeed in a pair-programming project. With a multi cultural/ethnic or international team it will take some time to achieve true pair programming. 

8. Collective Ownership.  

All the code belongs to all the programmers. This lets the team go at full speed, because when something needs changing, it can be changed without delay. No single person “owns” a module. Any developer is expecting to be able to work on any part of the code base at any time. In XP code has a collective ownership but a task has individual ownership. 
 

9. Continuous Integration:  
 

All changes are integrated into the code base daily. All the tests should run 100% both before and after the integration.  
 

This keeps all the programmers on the same page, and enables very rapid progress. Perhaps surprisingly, integrating more frequently tends to eliminate integration problems that plague teams who integrate less often.  
 
10. 40-hour Week.   

Go home at time, have a nice weekend. Programmers are allowed to work occasional overtimes. Continues overtimes shows that there is something going wrong with the project.

Tired programmers make more mistakes. XP teams do not work excessive overtime, keeping them fresh, healthy, and effective. 

11. On-site Customer.  

Development team has access to a real customer who will be using the system. 

An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the programmers have them. The effect of being there is that communication improves, with less hard-copy documentation - often one of the most expensive parts of a software project. 

12. Coding Standard.  

Everyone codes to the same standard. Ideally looking at a piece of code, none should be able to say who wrote that piece of code.

For a team to work effectively in pairs, and to share ownership of all the code, all the programmers need to write the code in the same way, with rules that make sure the code communicates clearly.
 

Adopting XP Practices and embracing the Organizational Change.

It is important to identify the practices that could fit appropriately in to our organization. It may not make sense to adopt all the practices of XP to our organization in one step. We need to carefully consider the uniqueness of our organization, the type of projects we are undertaking and the best practice that will fit in to our culture. The ultimate objective is to achieve our desired institutional goals to improve the process and procedures.  
 

The major areas of considerations are,

Organizational Culture

XP is based on self-directed team. They are given the broad goals and then they work with the customers to achieve those goals.  

Command and Control style of management is a block to the successful adoption of XP.

An important organization issue is about planning and commitment making. If the organization commit to a plan and requirements up front, it is very difficult to implement one of the major XP practices of “incremental planning and requirement definition”. XP assumes that we cannot know all the things that will come up during the project.  So we have to plan and define the requirements at only a high level in the beginning. Later we add the details and revise them incrementally through out the project, keeping the broad goal in sight.

Customer

XP expects the ultimate customer to be part of the project development team through out the project. This could be an obstacle in adopting the XP practice as the customers would not be able to devote their resources to the project.

Type of Projects

Every project in the organization is somewhat unique and represents unique challenges and opportunities. All of them are web applications with a relatively predictable set of attributes and the organization tend to keep it that way to reduce the risks involved. Some of them are really strategic application which contributes to the main source of income. XP is well suited for small to medium sized applications and definitely all our projects come under that category.

Tools and Methods

The methods we employ do not exist in a vacuum. They are strongly influenced by the environment in which we use them; and an important part of that environment includes the supporting tools and processes that we depend upon.

As things stand today, our organization already has a set of tools and processes in place. We need to determine to what extend will those tools and processes be compatible with and support the new XP practices we expect to adopt. It is important to understand how much flexible the current methods like requirement gathering, user involvement, quality control process etc are to adjust with the new XP practices. Also we may have to adopt some new tools as part of the changes like a new Testing Tool which is very important in adhering to the XP standards.

Another example is code control systems. XP methods assume strong code control systems and strict adherence to the disciplines involved in using them. Liberal use of things like refactoring and shared ownership of code can only work in an environment that provides the necessary code control tools and processes.

Development Team

XP methods expect that development teams will be self-directing. This means that instead of being told what to do (command and control), the team understands the objectives of the project, and they collaborate with the customer and each other to determine the most appropriate steps to take at each juncture.

In order to act autonomously, the team members must be willing and able to take on a new level of responsibilities and accountability. This has a downside of how much a developer is willing to take accountability for the work he/she is doing and how much they are willing to be a decision maker.

Also the team members can be intimidated by the changes in the methods. It may challenging for some to adopt the changes with whatever available technology and the current state of the project. The frustration can add up with the new customer requirements also.

One of the main factors is to consider, how much uniformity in capabilities is there among the development team members and how willing they are to collaborate with other developers and with the customer directly. 
 

Implementing XP

Changes cannot be implemented overnight in a small organization where there are already established process and procedures. Changes can only be achieved iteratively starting with a project with 1-2 programmers involved. It is really important to prove the whole Development Team that XP delivers the required objectives in a desired manner.

The following steps needed to be taken in order to implement XP in the small organization.

A. Pick a project to start with XP

Selection should be made in such a way that minimal disruption is caused to any other ongoing projects.

B. Select volunteers from the development team

Team member should be committed to work on the XP project along with his/her own project. It is understood that due to the nature of the business and the organizational culture, interruptions would happen and the focus should be shifted.

C. Start with some XP practices that align with the current organizational practices.

D. Listen to the feedback from other Developer, Top level Management and most importantly from the customer.

E. Iterate the development process, adding more XP practices such as Refactoring

F. Evaluate the processes and feedback received and repeat the above process until high level of confidence is achieved from all Stakeholders.

G. Communicate with the other team members about the results achieved and convince them to adopt some XP practices to their own projects. 

 
Implementing XP using the scale of 7 keys to success

The process of adopting XP can also be designed and executed based on the 7 keys to success as follows.

1. Stakeholders are committed

Make sure we get the commitment from the CEO (Program Manager), Customers and the Development team to embrace this change. It is extremely important to assure the Top Level Management that all the ongoing projects will go uninterrupted and result of XP programming will be communicated in short intervals.

2. Business Benefits are realized

Convince the business benefits of “XP Programming” to the Top Level Management, Clients and the Developers. Educate the stakeholders about the business benefits of XP practices. Make sure they understands that the XP practices allows a small sized development teams to help ensure quality and high business value in the code they produce, while eliminating excessive overhead. One of the main advantages of XP is Handling Risk Management. XP allows delivering what customer really wants in a short time with highest quality.

3. Work and Schedule are predictable 

User requirements are broken down to chunks (User Stories) by the developers, and they provide estimates to each user stories. Actual progress is measured with iteration and passed to the stakeholders. At any stage of the project stakeholders can know the overall work progress and anticipate how much would be done by the actual schedule.

4. Team is high performing 

With pair programming and shared code base, development team can produce high quality products in less time. Coding is done in a way that any future requirements can be added to the current system with out trouble. 

5. Scope is realistic and managed

Since users are part of the whole development process, we know what exactly they need. The chances of Scope Grope and Scope Creep are very unlikely.

6. Risks are mitigated 

XP accepts the fact that the change is a part of life. Since Iterative and Pair Programming are followed in XP practices, risks are realized and the team responds to them positively.  

7. Delivery organization benefits are realized

At the end iterations, user’s feedback are collected and reviewed. All the progress are recorded and documented for the institutional level implementation. All the pitfalls are evaluated as a team and corrective measures are taken to implement in the next iteration.

Conclusion

Implementing XP allows adding more organizational value. Since users are part of the development process, their feedback can be iteratively included in the development phase itself. Also this process identifies any risks or mistakes at the early stages itself and allows taking corrective measures. XP allows delivering a quality product to the client when they need it.