eXtreme Programming at Sabre Case Study Assignment

Topic: eXtreme Programming at Sabre Case Study Assignment

Date: 11st April, 2016

Word Count: 1966

1. How should the company introduce XP?

More specifically, should the company just jump right into it and attempt to use XP on a large, upcoming project that is mission critical to the company? Or, should it experiment with a smaller, less critical project?
eXtreme Programming (XP) is a project development methodology in order to deliver a valuable product to customer within a short time. As we know, XP is based on the Agile process model, which means it is more friendly when use it on a small project. When using XP, it will decompose the entire project into small releases where each release contains one or more functions that required by the customers. The benefits to divide the project into small releases is that the developers can quickly get feedbacks from users and being able to solve the problems at an early stage. The final deliverable project should be able to implement all or most of the functions to the end users. Because each release of the project was designed and tested individually, so project manager can accept any form of changes from customers during the development process. Any changes are obtained from communication with customers, like what features that customers want and what the final project should be looks like, and then signed into user stories. The whole development process could be repeat several times until meet the customer requirements. Clear and strong customer communications required during the development, because the functionality of the project is based on the requirements not in the documentation. On the other hand, it has been proved that XP can be also used directly on a large project. For example, Mitchell, Owen & Warr (2004) indicated that in their technical journal which is a group of ten peoples using XP method within required timeframe could successfully complete the requirements to develop an internal component for WebSphere Application Server, which is one of large IBM products. They also show that the results of the project have fewer bugs than projects using traditional methods. However, not all projects suitable using XP method, the reason is that certain XP practices were not designed for large project, for example, if the large project decomposed into small releases, the number of releases could be extremely huge and hardly maintain. So the entire project may take a long time to complete, and cost could be expensive. The main purpose using XP is qualitative measurement due to the project is focus on time consuming, and needs to quick iterations at each release in order to reach the final target of project. When the team develop a project, they should follow the XP practices, like small releases, simple design and pair programming. Because little or no planning required when developing a project using XP method, so teamwork is highly important for the team. In addition, paralleled programming could reduce the required time, because between two developers who working on the same project, they can fix the bugs immediately during the testing. Although the XP method is not easy to implement, but the end results of using XP can reduce defects in the project. As a result, in order to reduce errors in the project, better use XP method was introduced by small project implemented in advance.

2. Can traditional project management tools such as work breakdown structure (WBS) be used in XP?

Work breakdown structure (WBS) can be used in XP. According to Marchewka (2015), the WBS is more focus on developing the project plan rather than change the project structure. So using WBS or other traditional project management tools could help XP achieve better results. Work packages is the name when WBS decompose the project into small pieces, like I mentioned releases in XP before. The function of work package is that to develop a project plan, which is good for time scheduling, budget and process monitoring (Marchewka, 2015). In XP, user functionality is noted in a work package, which the work package contains the terms of functionality what the customers want to have in their project. At the same time, the team should discuss break down the work package into individual task or activity, like what each team member should do. WBS in XP focus on the function to be made before the project initialise, and also make sure the duty of people should be carried out in the project. In addition, WBS in XP also perform an acceptance test which is always updated during the process, rather than planning everything at the beginning of the project. Because WBS provides a bridge between the scope of project and plan, the level of details should support the project, more specifically, the time schedule and budget. Traditional WBS is more like a Waterfall process if compared with our XP-WBS method. When we planning a project, we usually put the plan at the front, and then we can determine who should do what. The XP method is take WBS into every release, so each release know their plan and goal, which is help to achieve the project’s MOV. Because one of the practices of XP is simple design, which means simple code should be implemented during the project, and also as the requirement of work package any issues should be fixed before the milestone of deliverable release. Using WBS in XP is also help reduce the potential risk come with the project, because every task has been levelled in order to make sure the project is deliverable. It can help the logical scheduling, which is make the goals can be complete by step by step. And also, WBS will make sure every team members have communicate with each other, which is can reduce redundant works and possible errors. As a result, work breakdown structure can be used in XP.

3. What methods for estimation would be most appropriate when following an XP approach?

eXtreme Programming’s approach is that using smaller release to improve the quality of a large project. In other words, if one small release can reduce the defects in the project, a lot of small releases could reduce more defects in the project. There have two possible budgeting estimation approaches could apply to this case – top-down approach and bottom-up approach. Kim & Park (2006) shows that top-down budgeting was introduced to deal with the fiscal crisis in 1990, and it more efficient to manage government resource compared with bottom-up budgeting. The recent study shows that the advantages when apply top-down approach to the project. First of all, the company or manager control all the budget allocations to different apartment, and they can make sure the project did not over budget. Secondly, manage budget efficiently in order to do not make any damage to company financial system. Thirdly, this approach will allow employee work within the budget and make the best effort (Kramer & Hartmann, 2014). On the other hand, the disadvantages of using top-down approach is that the project may fail if the manger wants to make changes to this project, and it might not attractive because the limit budget. For example, the potential talent programmer might not want to work with company who have a limit budget on their project. In addition, apply bottom-up approach to this project could increase motivation due to the budget is controlled by themselves. And also, the bottom-up approach could help manager or company to get a better understanding on their project due to when they control the budget, they can participate in the working process. Furthermore, it could help get better communication between different departments within the company, because they need to communicate very often in order to eliminate any errors could have within the project. Moreover, the bottom-up approach could also help decrease potential increase funds in the future, because this kind of approach encourages low-lever employees to present their ideas, and the company could wisest uses of those ideas to reduce budget and get better product. Another benefit is that the manager could change the project at early stage, because the budget is control by themselves. However, the disadvantages of using bottom-up approach is that the company might need to change their roll-out system at later, because the contribution of this project is different for different levels people who involved in this project, like people get how many wage is depends on their amount of work. Another drawback to a bottom-up approach is that it might be difficult to list every tasks that need to do at which phase, which means that the planning is not necessary for this kind of approach. As a result, the bottom-up approach is the most appropriate method when following up the XP approach, because it more flexible to manage the project.

4. If the company’s developers have always followed a more traditional approach to IT projects, what impacts might introducing XP have on them?

The traditional approach is contains a leader who makes the every decision about the project, including a method that would be used, what plan should be, etc. The person who take all the responsibility of the project, and also he or she will decide jobs for each member of the team. However, without discussion about the role of the job and the scope of the project, the final product could be failing to meet the requirements. So when developers finish the final product, only some functions could be working at certain circumstances, and probably few features that customer satisfied. The worst scenario is start over the whole project from the beginning. The XP method make the developers, managers and customers work together and communicate a lot before start the project, so when developers finally begin to working on the project, they will get a clear picture of what this project looks like, and what customers asking for. Compared with XP approach, developers in traditional approach usually working alone, which brings to a lot of disadvantages, such as need a long time to complete the project, no help from others, constraint in ideas, and may cause too much stress. On the other hand, teamwork could bring a lot advantages to this project, such as increase the work efficiency, higher quality outcomes and improve office relationships. When the project change development method from traditional to XP, developers might think their personality could be lost, because they need to work with others. And also, they might cannot easy to focus what the job they doing, because other members in the group could be conversing the whole ideas. But, well teamwork leader could prevent those problems, respect others ideas could be save a lot of agreements during the discussion. The developers should cooperate in developing a product. It will be difficult work together, but find a right partner could save a lot of time on the development process and save a lot of money. Pair programming could increase productivity due to only small amount of error can be found in the project. Rico (2008) shows that the XP method should obtain some good things from the traditional method, like traditional quality and reliability theory, because it eliminates the possible defects at the early stage of the lifecycle. In order to apply XP method to traditional team, the team leader or manager should consider carefully, because not every project suitable the XP method. Achieving customer requirement could be difficult, but apply the appropriate method to the project could increase the success rate of the project.

As we discussed in the previous session, applying XP method to a new project could be difficult, however, making the right decision is very important when decide what method should be applied to the project. Project manager should choose the appropriate method to the project, although XP method could bring a lot of benefits to the product.

References:

Marchewka, J. (2015). Information technology project management: Providing measurable organizational value / Jack T. Marchewka. (5th ed.). Hoboken, NJ: John Wiley & Sons.

Mitchell, S., Owen, J., & Warr, K. (2004). IBM WebSphere Developer Technical Journal: An adventure in extreme Programming. Retrieved from http://www.ibm.com/developerworks/websphere/techjournal/0408_mitchell/0408_mitchell.html

Kim, J., & Park, C. (2006). Top-down Budgeting as a Tool for Central Resource Management / John M. Kim and Chung-Keun Park, OECD Journal on Budgeting Vol. 6, no. 1, p. 87-125 6:1<87.

Kramer, S., & Hartmann, F. (2014). How Top-down and Bottom-up Budgeting Affect Budget Slack and Performance through Social and Economic Exchange. Abacus, 50(3), 314-340. doi:10.1111/abac.12032

Rico, D. F. (2008). What is the Return on Investment (ROI) of agile methods? Retrieved from http://ww.davidfrico.com/rico08a.pdf