Critics of scrum have asserted that there is no difference between Scrum and XP without its technical practices. This has led to the development of a sentiment that Scrum is just XP without the technical practices and this paper will attempt to validate this claim by comparing and contrasting XP‘s non-technical practices with Scrum practices. The paper will start by introducing agile software development under which Scrum and XP fall. The paper will then define Scrum and XP before looking at the technical practices of XP. The paper will finally look at the XP non-technical practices, comparing and contrasting them with scrum practices to validate the claim that Scrum is just XP without the non-technical practices.
Agile software development revolves around several software development methods that are iterative meaning that needs and solutions emerge from the link between self-organized cross-functional teams which promote disciplined project management processes that encourage frequent inspection and adaptation. These methodologies create a leadership philosophy that encourages teamwork and accountability and they are supported by an agile manifesto that was formulated in 2001. The agile manifesto is focused on uncovering better ways of software development that value individual and interactions, working software, customer collaboration, and response to change. The manifesto overlooks processes and tools, comprehensive documentation, contract negotiation, and the following of a plan. Scrum is an agile method of managing projects that do not address the practices needed to create products of any kind. Instead, it gives the process that takes the project manager from the inception of a vision to the final project without depending on the actual development process which means that that scrum does not show one how to create quality; it just points out where quality is, identifies and locates problems and drives one to fix them. On the other hand, XP, or extreme programming is an agile software development method that gives the developer a process that they can use to create software in an agile and productive way, though it does not concentrate on the developmental process. Extreme programming focuses more on software engineering practices to deliver quality software as opposed to a scrum which focuses on the developmental process.
What are the technical practices of extreme programming? There are 12 main extreme programming technical practices. One of the practices in the planning game is a collaborative and iterative practice that involves negotiations that establish achievable plans that can efficiently meet business needs. The other practice is small releases which involve the development of small chunks that provide customers with demonstrable value and customers can easily verify that the system development is progressing towards meeting their needs. The third extreme programming practice is the metaphor which describes how the system will look like using similes (Palmer, 2005). Metaphor is the main practical requirement of XP and the actual descriptions of the systems are documented in stories that describe the essential attributes and actions of the system. The fourth XP technical practice is a simple design that advises the programmers to avoid making designs that cannot allow the current story to be implemented. This practice is important because it is upholding XPs philosophy of simplicity which states that simple design practices will result in lesser work that is designing is geared for the future.
The other XP technical practice is Test First which ensures that a single line of codes is written to implement automated tests that will be used to verify the stories and this practice is very important because it helps in successful integration. The sixth XP technical practice is referred to as refactoring and this practice prompts the programmers to ask questions that will help them to work on a story in a systematic way that will make the final result simple. Refactoring is important because it ensures that simple designs do not become complex as the programmers add more stories. The other technical practice is called pair programming and it entails a continuous, real-time review of all that has been accomplished and it is important because it emphasizes technical excellence while collective ownership as a technical practice goes to the opposite extreme to ensure that no code is individually owned. This practice is important because it assigns responsibility for every code module to a single person. The other practice is continuous integration which ensures that the process of product building goes on continuously by running the entire suite set automatically and this helps the pairs of programmers working on diverse stories to integrate their work without halting the building process. 40 hours a week is another XP practice that ensures that overtime is a rate and this keeps the programmers fresh by avoiding burnout. There other three XP practices include on-site customer and coding standards. While adopting scrum to develop software, various practices are borrowed. From XP and these include test-driven development, refactoring, and user stories because technical practices are absent in scrum.
It is now important to look at scrum and XP in the absence of XP technical practices. Without the technical practices, there are more similarities between Scrum and XP. To start with, Scrum just like XP contains a set of practices that are used for quick development of quality software programs and the only addition in scrum is that it removes anything that may make the process of software development stall down. XP without the technical practices has the same goals and methodologies as scrum. XP uses sprints just like Scrum and the two commence with a planning meeting. However, it is important to note that though the two have sprints, the length of the sprints is different (Cohn, 2006). The sprints in XP do not last more than seven days and at the end of seven days, XP programmers give the customers a bug-free system that works efficiently. However, sprints in the scrum last between a fortnight and a month, and the focus are the date of product release rather than a working system as in the case of XP. Sprints in XP are also more flexible than in Scrum because Scrum does not have room for changes.
Looking at a Scrum meeting, there is no single difference with XP meetings. In Scrum meetings, just like in XP, every iteration starts with a sprint planning meeting where the product owner and the team decide on the stories that will be in the sprint. The product owner decides which stories have the highest priority because high-priority stories have the largest business value. Just like in XP the stories are then put in the sprint backlog. The methodologies used in both scrum and XP meetings are the same and they ensure that quality is improved the only difference is that the two use different approaches assure quality.
Just like XP, scrum has some degrees of unpredictability in its system specifications and instead of defining all the system requirements at the outset, planning is performed up to the point in a scrum just like a brief planning phase is used in XP. The other feature of a scrum that makes it resemble XP is the focus on timely deployment of software. In scrum, functional deliverables are released when each sprint is concluded and updated when necessary and this corresponds to the XP’s focus on small working releases that ensure that the overall product doesn’t fail.
Just like XP scrum focuses on frequent communication between team members and this communication is vital in XP because it helps the team members to get clarification from the on-site customer while in Scrum, frequent communications between team members are meant to reduce the margin of error.
Though the methodologies are similar, XP is bound by a strict priority order that entails the development of features as prioritized by the customer and the team has to follow that order while in the scrum, the date of product completion rather than priority is emphasized. This means that Scrum product owner prioritizes but the team decides on the sequence that they should use to avoid product backlog, therefore scrum teams do not work on the highest priority items.
Scrum and XP management artifacts are also similar, though management practices are absent in XP (Cohn, 2004). Apart from the sprints and daily scrums, other management artifacts like burn-down charts and retrospectives in both scrum and XP are similar and that is why if you remove the engineering practices from XP, what you will get is nothing different from the scrum. That is why, in modern practices, engineers mix scrum and XP. They take scrum artifacts and use them alongside XP engineering practices and the result is just another efficient XP.
Both scrum and XP can be adopted to develop a project, creating a very good cooperative relationship that takes advantage of the similarities between the two methods and the strengths of each method while minimizing the weaknesses of each method. Though Scrum resembles XP without engineering practices, its main weakness arises when poor technical practices are used. This means that to raise the quality of the final product, high-quality programming must be used where guidelines are clearly defined and proper meetings established.
Proponents of scrum have failed to avail evidence to dispute the fact that Scrum is just XP without engineering practices. A study into the methodologies and management artifacts used by scrum reveals that they are quite identical to the methodologies and artifacts used by XP and though there are some significant differences in approach. Using evidence from such studies, it can be therefore concluded that Scrum is just XP without the engineering practices.
Reference List
Cohn, Mike. 2004. Agile methods. Chicago: Addison Wesley.
Cohn, Mike. 2006. Agile Estimating and Planning. NJ: Prentice Hall.
Palmer, Daniel. 2005. Extreme Software engineering.NJ: Pearson.