3
The Most Popular Agile Methods
Agile methods have become very popular because of the promise to deliver superior quality products in significantly shorter time frames than traditional practices. Along with meeting an organization’s needs and business goals, agile methods focus on satisfying stakeholders and the end user. This chapter discusses two agile methods only: Scrum and XP. There are in fact other agile methods, however, this chapter discusses the two methods that are considered to be the most popular. Additional agile methods are covered in Chapter 17. Scrum and XP are the main agile methods that are covered on the PMI-ACP exam.*
Scrum is considered to be a lightweight agile method that uses practices, events, roles, artifacts, and rules for project execution. This method is supported by three “pillars” that guide all facets of the Scrum project:
Transparency: Everything on a Scrum project is visible to all who have a stake in the outcome.
Inspection: The Scrum project is inspected on a regular basis to ensure that progress is being made toward the goals and objectives.
Adaptation: Processes are adjusted as needed when problems or undesirable issues present themselves.
The benefits of Scrum include but are not limited to the following:
• The process is incremental and iterative.
• Requirements are permitted to change over a period of time.
• The end users are actively involved throughout the project.
• The process is straightforward and uncomplicated.
Possible weaknesses of Scrum methods include:
• In the event that a team member leaves the project, the impact is significant.
• The Scrum project requires experienced team members. Inexperienced team members can lead to project delays.
• The method is very informal.
A typical Scrum project has six to ten team members. This agile method is more suited to small teams, however, it can be adapted to large teams as well. Companies and projects that are team, value, and customer oriented are the best candidates for Scrum methods.
XP is considered to be strictly a software development agile method that focuses on good practices. This method supports several core values during its practices. The values are simplicity, feedback, courage, respect, and communication. XP values are manifested throughout the entire life cycle.
The strengths of XP include but are not limited to the following:
• Very responsive to changes
• High priority features are developed first
• Pair programming enhances creativity
Possible weaknesses of XP include:
• Large amounts of overhead may be required.
• The order of feature importance can be subjective.
• XP should not be used on a project with a very large staff.
XP was developed to address the issues associated with project risk. XP practices were established to mitigate risk and increase the probability of success. XP was developed for small groups of developers (i.e., between 2 and 12). Risky project types that are good candidates for XP include but are not limited to the following:
• The customer needs a new system by a certain date.
• A new system is a big challenge for the software industry as a whole.
• A new system is a challenge for a company’s internal software group.
We now begin our discussion with an overview of Scrum. Figure 3.1 outlines the Scrum process in detail.
FIGURE 3.1
Scrum process.
SCRUM OVERVIEW
Scrum is a lightweight agile framework used for developing a product. For the purposes of our discussion, we need to clarify what we mean by the word product. A product is typically software when we are referring to development work; however, a product can be a service, a tangible deliverable, or a desired result. According to SCRUMstudy (2013)*, the Scrum framework can be used on any type of project in any industry. This means that Scrum can be effective on small as well as large teams upward of hundreds of team members. In the case where the Scrum team size is larger than ten, it is recommended that several Scrum teams be formed. For the purposes of this book, the author’s focus is on small teams with at least six to ten members.
The work on a Scrum project is divided into Sprints (iterations). The team on a Scrum project is self-directed, cross-functional, and is empowered to make its own decisions. At the end of each Sprint, the Scrum team creates a potentially deliverable product (Sprint increment). The Scrum framework delivers products based on empirical process control (observing and experimenting) rather than up-front project planning. In order for the Scrum project to deliver the best value to the customer as quickly as possible, the team must prioritize and determine what should be done. All stakeholders on the Scrum project collaborate, interact, and work in a cohesive fashion in order to deliver the greatest amount of product value. In addition, time-boxing is a Scrum technique that establishes the time frames under which work is completed and meetings are conducted.
The Scrum framework is very adaptable based on the fact that very little up-front planning is done and the focus is on observing and doing. The product’s development is iterative, very flexible, and designed to incorporate changes at any point in the project. The information path on the project is very open and transparent where everyone can quickly and easily see the status. The Scrum team gets continuous feedback as a result of meetings and activities. Each Sprint provides the team with an opportunity for continuous improvement with the product and the team’s practices. The iterative nature of Scrum provides for frequent delivery of the product based on the customer’s needs which in turn translates to continuous value for the customer. The Scrum framework is based on working under a sustainable pace for an indefinite amount of time and typically this would mean that the workweek is 40 hours per week maximum.
The product backlog, a requirements document that represents the project scope, is prioritized based on the product features that have the greatest amount of value for the customer. To be clear, the customer is responsible for making the determination as to which requirements are considered to be the high-value ones. High-value requirements are delivered earlier than those with lesser value. The Scrum development process is considered to be very efficient in that most of the activities are time-boxed. This means that a short and specific period of time is established for the work to be completed. This leads to an efficient development process for the Scrum project. The Scrum framework is reported to lead to very high levels of team motivation, namely because of the daily standup meetings and Sprint retrospective processes. The Sprint team can resolve problems faster than with traditional project management because of colocation, collaboration, and cross-functional teams. Scrum deliverables are deemed more effective because of regular customer interactions and the prioritized backlog based on the customer’s needs. There is a heavy focus on increasing business value by collaboration with stakeholders under a customer-focused framework.
Scrum processes facilitate a high trust environment with very little conflict among team members. This occurs because of the daily standup meetings (15-minute time-boxed discussions used to report progress), and Sprint retrospectives (meetings used to discuss lessons learned during the end of each iteration) that promote Scrum principles such as openness, collaboration, and face-to-face communication. In addition, the Scrum work environment is one where team members are permitted to take ownership of the project work, resulting in a high quality product. Everyone is responsible together for the success of the project and product delivery. A collaborative work environment enables the Scrum team to attain a very high velocity. Finally, working under an innovative environment has the potential to increase learning, adaptability, and contemplation. An innovative environment has a high probability of an increase in the level of creativity in the work environment.
Scrum Transparency
Scrum activities are very transparent in that all project-related information is visible to all stakeholders and project team members. Information flows very freely and is not hidden from anyone on the team. All team members are made aware of the project vision; the product backlog is posted for everyone to see; the progress of the team is discussed out in the open during the daily Scrum meeting and everyone is made aware of release plans. In addition, Sprint review meetings include everyone and Burndown and Burnup Charts reflecting the amount of work that has been accomplished are posted for viewing by all.*
Adaptation
Adaptation is a Scrum concept that refers to flexibility based on the needs of the project. The Scrum team learns what needs to be accomplished almost effortlessly as a result of the project’s transparency. By monitoring and observation, the team is able to adapt as required by making improvements to the work as needed. There is very little planning on Scrum projects because of adaptation. As a result of adaptation, the finished product has a very high probability of success.
The Scrum team utilizes information obtained from the following sources for adaptability:
• Daily Standup Meetings: A 15-minute time-boxed meeting where team members come together to discuss progress.
• Retrospect Project Meetings: A meeting used to determine how collaboration and effectiveness of the Sprint team can be improved in the future.
• Retrospect Sprint Meetings: A four-hour time-boxed meeting used to discuss lessons learned throughout a Sprint.
• Consistent Risk Identification and Management: As a result of regular feedback, risks are discussed during the daily meetings and are addressed during the upcoming Sprint.
• Change Requests: Small changes are approved by the Product Owner. Any requested change that cannot be approved by the Product Owner is presented to the stakeholders. If the change is significant, then senior management must provide the approval. Changes are also approved during the grooming of the product backlog.
• Scrum Principles and Values: Values are identified in this chapter under the heading “Core Values of Scrum.” Scrum principles are outlined in Table 3.1.
TABLE 3.1
Comparison of Scrum and XP
Scrum (Project Management Approach) |
XP (Software Development Methods) |
|
Objective |
Communication Team and management interactions Team empowerment |
The customer has the driver’s seat The code is the main focus |
Perceptions |
High-value focused Risk focused Team controlled |
Trust the developers to get the job done Developers can “Do their thing” Lack of management control |
Principles |
Commitment Servant leadership Openness Respect Courage Self-organizing project teams Multifaceted knowledge transfer Subtle control Regular transfer of information Visibility Communications No interference |
Quick feedback Incremental change Excellence in work Common understanding Programmer well-being Continuous process Communication Simplicity Courage Initiative |
Motivation |
Identify changes early Let the development team do their job and stay out of their way |
Refactoring the code makes it easy to change Customer has authority to make all business decisions Development team has the authority to make all technical decisions Short iterations Customer provides fast feedback |
Activities |
Sprint planning Daily Scrum Sprint review Retrospectives |
Create user stories Release planning Planning games Code development Spikes Execute Acceptance Tests |
ScrumMaster Product owner Scrum team |
Programmer Customer Coach Tracker Sponsor Manager |
|
Deliverables |
Sprint backlog Release backlog Product backlog |
Release plan User stories Product backlog Unit tests Acceptance test |
Approach Iteration length Planning Artifacts |
Iterative incremental 2–4 weeks Iteration planning Release planning The finished product (operational) |
Iterative incremental 1–3 week iterations Planning games Stories Constraints Tasks Acceptance tests Code Releases Metaphors UML design Documentation Standards Unit tests Planning Release plans Iteration plan Test results Spike solutions Resources Scope Quality Time Tracking results |
Project Type |
Small projects |
Quick development Not dependent upon a deadline |
Scope |
Defined by the customer |
Uses a product backlog to define scope |
Create product backlog Identify and remove impediments Define Sprint backlog No interference allowed No intruders allowed Demonstrations Observations |
Planning games Small releases Simple design Metaphors Refactoring Testing Pair programming Collective code ownership Continuous integration 40-Hour workweek On-site customer Coding standards |
Source: Derived from G. Admad, T. R. Soomro, and M. N. Brohi, European Academic Research, 2014. Retrieved from http://www.euacademic.org/UploadArticle/273.pdf. With permission.
Inspection
This Scrum concept is based on the team having visible information sources available for inspection. The Scrum board (see Table 3.2), a tool used for Scrum planning and tracking purposes, shows the team’s progress for the completion of tasking for the current Sprint. The customer, the person or company that procures the project’s product, services, or result, provides constant feedback with regard to the prioritization of the product backlog items, breaking down epics (i.e., large untouched user stories), and release planning activities. Finally, an inspection is performed to validate the product at the end of each Sprint. Inspection is a way to verify quality and provide the customer an opportunity to inspect the product for acceptance.
TABLE 3.2
Scrum Board
Iterative and Incremental Development
This refers to a style of product development that is done in iterations and is focused on improving the product over a period of time. An important aspect of iterative development is that it provides opportunities for rapid feedback used to decide the next steps for the product’s features. High-priority functionality is iteratively added to the product and changes are effectively addressed, one iteration at a time. Scrum is also considered to be incremental, which means that new features are added to the existing code. In contrast, iterative development refers to making modifications to existing functionality. Thus the product is both incrementally and iteratively developed.*
Time-Boxing
This is an agile concept that refers to fixed periods of time for work to be finished and for activities such as meetings to take place. When the established time has expired, the event is discontinued and whatever has not been completed is moved to the next time-boxed period. An example of a time-boxed event is the daily standup meeting which is set for 15 minutes per day. Sprints are time-boxed at two weeks or up to a month.
Collaboration
With Scrum, this is a concept that refers to product development that includes all stakeholders collaboratively working together to create and deliver the high possible amount of value. We recall the agile principle: “Customer collaboration over contract negotiation.” Collaboration must occur in order to develop and deliver the product increments that have the maximum amount of value for the customer. In cases where requirements need to be better understood, collaborating with the customer minimizes the need for excessive change requests. In addition, as threats appear on the project, customer collaboration can result in the early identification and assessment of uncertainty, which in turn lessens the overall risk impact for the project as a whole. The customer is the best resource, in most cases, to address issues with user stories (requirements).
Self-Organization
The expectation for a successful outcome on a Scrum project is that the team is self-motivated and accepts full responsibility for the success of the product. When the team is also self-organized, then the expectation is that a high-value product will be delivered. Scrum projects work under the “servant leadership” principle where the needs of the team are satisfied in order to achieve the desired product results.
It must be made clear that a self-organizing team does not have the right to do whatever it wants to do. This means that team members use their own judgment and experience to get the work done on the project based on the technical and managerial requirements necessary to deliver the product. Each member of the Scrum team takes responsibility for defining and completing tasks, creating estimates, and agreeing upon the team’s velocity during the Sprints.
Scrum Management and Leadership Styles
On the Scrum project, the role of the project manager is considered to be distributed. This means that project management functions are “shared” among the Product Owner, the ScrumMaster, and the Scrum team. On traditional project management teams, the project manager has responsibility for the majority of the leadership and management tasks. In contrast, the ScrumMaster functions as a servant leader to the Scrum team, ensuring that the path is clear so that the product to be delivered has high value for the customer. The Scrum team self-organizes and self-manages with minimal interference and obstacles along the way. Lastly, the team collaborates with the customer on a consistent basis. Up-front planning is practically nonexistent.
Scrum Roles and Responsibilities
Scrum roles consist of three types: the development team, the Product Owner, and the ScrumMaster. Ancillary or additional team members include stakeholders who give advice, support the team, and are watchful of the project. To add humor and fact to this discussion, the core team includes the Product Owner, developers, and the ScrumMaster and the group is considered to be the pig. The ancillary team, the project stakeholders are referred to as the chicken.* All team members must come into agreement with regard to what “done” actually means for the project. A discussion of each role follows.
Product Owner
The Product Owner is considered to be the customer or the voice of the customer. The responsibilities of the Product Owner include the following:
• Creates the product vision for team and stakeholder acceptance
• Accepts or rejects the product increment at the end of each Sprint
• Prioritizes requirements (user stories) in the product backlog based on business value
• Clarifies items in the product backlog
• Establishes release dates for the product
• Assesses the feasibility of the product
• Overall responsibility for the product delivery
• Ensures that the product backlog is transparent on the project
• Establishes the goal for each Sprint
• Grooming of the product backlog
• Obtaining the maximum business value
• The Product Owner also shares the Servant Leader role with the ScrumMaster
ScrumMaster
The ScrumMaster’s role on the team is that of a facilitator, motivator, and coach. The responsibilities of the ScrumMaster include:
• Protecting and guarding the team from outside interferences
• Not conducting any actual technical work
• Making sure that the team follows the Scrum procedures
• Functioning as a change agent; making sure that the change process is obstacle and hassle free
• Maintaining the Blocks List (the list of impediments and unresolved issues encountered by the team)
• Servant Leader to the Scrum team
Scrum Team
The Scrum team (i.e., the development team) is self-managing, cross-functional, and consists of six to ten members on average. The responsibilities of the Scrum team include:
• Completing the work on the product during Sprints
• Understanding the requirements
• Maintaining equality among all team members
• Being generalists across domains and specialists in a minimum of one area
• Grooming of the product backlog with the Product Owner
SCRUM PLANNING
The Scrum framework has several planning events (meetings) to establish the goals for each Sprint. A discussion of these important activities follows.
Sprints
A Sprint is a time-constrained (time-boxed) iteration of two weeks to one month used to build a potentially shippable product increment. Each Sprint is implemented similar to a small project and it consists of five major milestones:
• Daily Scrum: A daily 15-minute time-boxed meeting used for the development team members to discuss progress, issues, and provides answers to three important questions:
1. What have I completed since the last meeting?
2. What will I do before tomorrow’s meeting?
3. What, if any, obstacles are in my way?
• Sprint Review: A meeting that is conducted at the end of every Sprint to present the product increment to the Product Owner and stakeholders. Backlog items are presented for acceptance; however, these items can in fact be rejected by the Product Owner.
• Sprint Retrospective: A lessons learned meeting conducted at the end of every Sprint. The meeting is based on the previous Sprint and opportunities for improvement of future Sprints are discussed.
• Sprint Planning Meeting: A time-boxed eight-hour meeting (per one month Sprint) that takes place at the start of every Sprint. The purpose of this meeting is to establish objectives and estimates for completing tasks. The product backlog is broken down into tasks. Estimates are created for the tasks in terms of complexity, risk, and completion times. All tasks defined in the Sprint planning meeting are included in the Sprint backlog.
• Release Planning Meeting: A meeting used to establish the durations of the Sprints and the planning for multiple Sprints within a release. In other words, the purpose of a release planning meeting is to establish the schedule for the product releases.
CORE VALUES OF SCRUM*
The Scrum Alliance promotes and acknowledges a solid foundation of values for the Scrum team’s processes and main beliefs. These five core values provide the team guidance that focuses on collaboration and continuous improvement.
Focus. The team’s focus is only on a small amount of things at a time. The team works well together to create superior work. Value is delivered sooner rather than later.
Courage. The team members are all in it together. They are not alone. They have support and resources at their disposal. They have the courage to take on great challenges.
Openness. Team members all work together as one team. They communicate and openly express themselves on progress and obstacles. They openly address any concerns they may be having.
Commitment. Team members are committed to having control over their destiny. They are committed to the team’s success.
Respect. The team members work well together because they share successes and failures. They respect each other and in turn they are worthy of being respected.
SPRINT ARTIFACTS (DELIVERABLES)
There are several artifacts associated with the Scrum framework. A discussion of the particular items that must be established and delivered for the project follows.
Product Vision
The product vision is a single sentence that describes the expectations for the product. This statement is created by the Product Owner and is agreed upon by the Scrum team.
Prioritized Product Backlog
This artifact is a list of product requirements (i.e., user stories) that are implemented as product features and functionality. Items in the product backlog support the delivery of the product vision. The Product Owner owns the product backlog and has the responsibility for prioritizing the items on the list based on value.
Sprint Goal
The Sprint goal is presented by the Product Owner and represents the goal(s) for the current Sprint.
Sprint Backlog
The Sprint backlog represents the list of requirements that have been assigned to a particular Sprint. The development team commits to completing all items in the Sprint backlog. The Sprint backlog includes a list of estimated tasks that only the development team can change. To be clear, only the development team can change the tasks within a Sprint. The Sprint backlog items cannot be changed once agreed upon by the team. The product backlog must be “groomed.” This is a process of adding additional detail and organization to the backlog. The Product Owner and the developers take responsibility for grooming the backlog. Developers may update task estimates and the Product Owner may change the priority of the backlog items.
Blocks List
The blocks list represents any obstacles and outstanding issues that the development team may be facing. This list is addressed and maintained by the ScrumMaster for resolution.
Sprint (Product) Increment
This is the potentially deliverable product increment created by the development team that will satisfy acceptance criteria.
Sprint Burndown Chart
This chart is used by the Scrum team to track the progress of the Sprint. Stakeholders use this chart to determine how much work remains (y-axis) to be completed in the Sprint, based on the amount of time remaining in the Sprint (x-axis). The chart shows the velocity (speed) of the team when completing the work for the product. On a daily basis, the team updates this chart based on the work that has been completed. The chart also provides an indication of whether the team will complete all of the planned work in a Sprint. The Planned versus Actual lines indicate how well the Sprint is proceeding according to the team velocity. Figure 3.2 represents a sample Sprint Burndown Chart.
FIGURE 3.2
Burndown Chart example.
Scrum Board
The Scrum team utilizes a whiteboard to plan and track its progress during a Sprint. The Scrum board has three columns that illustrate the progress of the Sprint (To Do, Work in Progress, Done). In addition, the Scrum board also displays the Scrum Burndown Chart. Table 3.1 shows an example of a Scrum board and the Burndown Chart.
Recap of Scrum
The Scrum framework’s most important factors are: *
• Scrum projects are completed in iterations (Sprints).
• Scrum is more of a project management focused agile method in comparison with other methods.
• High business value functionality has the top priority level for completion.
• Each Sprint produces a potentially deliverable product increment subject to the Product Owner’s approval.
• Regular interactions occur between the customer and the Scrum team. This would include the Scrum meetings: Daily Standup, Sprint Planning, Sprint Review, and Release Planning.
• Face-to-face interaction promotes speed in communication.
• Working software at the end of each Sprint is the measure of success.
• Everyone on the team is equally responsible for the success of the project.
• Changes in the product requirements are easily accommodated and expected.
• The Scrum framework ensures that progress is made on a continuous basis.
We now move our discussion to the next agile method: XP (Extreme Programming).
EXTREME PROGRAMMING (XP) OVERVIEW
Extreme Programming or XP is an agile method that is focused on software development best practices. XP was developed by Ken Beck, a software engineer, during the 1990s. XP was created to be a software development discipline used to create high-quality software more productively.* Scrum and XP are methods that use iterations, however, Scrum iterations last two to four weeks and XP iterations last for one to two weeks. XP is very strict with working in priority order, however, Scrum developers have decision making authority to determine how backlog items will be turned into tasks. Lastly, Scrum can be used with large teams, but XP teams need to be small so that they can operate efficiently and effectively.
XP Core Values†
The core values for XP include the following:
Simplicity. The development team does only what is required and nothing more. This keeps things simple and value is maximized. Baby steps are taken in order to reach goals and mitigate failures when they occur. The team creates work they are proud of and the work is maintainable for the long term at reasonable costs.
Communication. The development team communicates face to face on a daily basis. The team works together on every single thing and creates the best possible solution together.
Feedback. The team uses all iterations to deliver working software on a frequent basis. The team listens and makes changes very carefully. The team talks about the project together and adapts processes as required.
Courage. Team members are truthful when discussing progress and estimates. They do not document or make any excuses for failure because they have courage. They have no fear because they work together. They adapt to changes at any time when they occur.
Respect. Everyone gives and receives respect on the team. Everyone is valued as a team member. The development team respects the knowledge of the customer and vice versa. The management team respects the team’s rights to accept responsibility and for them to have authority over their own work.
XP Roles and Responsibilities
The XP team has several roles on its projects: customer, developer, tracker, and coach. The first two roles are core and the remaining two are supplementary and may not be present on every XP project. A discussion of each role follows.
Customer
The customer defines the requirements for the project and establishes the project goals. In addition, the customer makes the hard business decisions for the project and works very closely with the software developers. The more involved the customer, the higher the likelihood of project success on an XP project. In actuality, the customer is the voice of the end user of the product. This role clarifies the features of the product and writes the user stories for the team. Finally, this role executes customer tests with assistance from the development team to ensure that a user story is actually done. The working software at any time on an XP project should include all functionality that has the greatest value to the customer.
Developer
The responsibility of the developer on an XP project is to create product functionality based on the user stories provided by the customer. This role must understand and implement product features by working very closely with the customer. Tasks are created from user stories and correct estimates enable the customer to decide which user stories have the highest priorities. Developers are empowered to estimate their own tasks without any interference from the customer.
Tracker
This role is considered to be supplementary and does not exist on every XP project. The tracker is responsible for maintaining the project schedule. Team velocity is also measured and tracked by this role. Regular tracking of the team’s progress enables adjustments to be made that will ensure that iterations stay on target.
Coach
The coach is another supplementary role that may not exist on every XP project. This role is responsible for providing guidance and team mentoring. The coach’s role is to ensure that the team understands the XP practices in conjunction with software development. This role also assists with problem solving and functions as an arbitrator between the customer and the development team if needed.
XP Core Practices
The XP methodology has several core practices that are considered to be best practices for agile software development. A discussion of these practices follows.
Whole Team. This XP practice ensures that the “whole team” sits together in the same location for the duration of the project. This refers to everyone, specifically the customer and the development team. The reason for this practice is to ensure ease in sharing information. XP supports the idea of generalizing specialists on its projects. This means that anyone who is qualified for a role can take it on because XP roles are not limited to people who have specialized skills in a particular area. This practice is popular because it enables team members who can perform multiple roles to switch back and forth from one role to another on demand. This practice also keeps everyone on the team engaged while working to ensure a balanced work load.
Planning Games. The XP planning games practices have two major events: release planning and iteration planning. A release represents a software version with new functionality that is delivered to the production end user. Releases typically occur once or twice a year. Iterations, however, represent short development cycles that occur every two weeks for XP projects and are included within a release.
Small Releases. The XP practice of small releases means that software is delivered to the test environment to show that the software is working. As we know from Scrum, working software is an indication of progress. Small releases support a quality product and extensive testing is conducted by means of continuous integration of the software.
Customer Tests. The XP customer defines the actual tests that show that the software is actually working. The development team constructs the test per the customer requirements to verify that the software is in fact working as it should.
Collective Code Ownership. This XP practice means that any pair of developers is authorized to modify any part of the code on the project. Multiple people may work on the code and this is expected to result in increased visibility and knowledge of the code among the development team. With multiple eyes on the code, this practice ensures that the code is of high quality because defects can be better detected. In the event that a developer leaves the project, the impact will be lessened because knowledge of the code has been previously shared.
Code Standards. In order to practice collective code ownership on an XP project, it is necessary for all developers to follow a code standard to ensure that the code looks as if a single person has made the changes. No specific code standard is required, however, all developers must be consistent with the method of writing code.
Sustainable Pace. XP understands that the team must maintain a consistent level of productivity. This can only be accomplished if the team maintains a sustainable pace which translates into a 40-hour workweek.
Metaphor. XP uses metaphors to reach a common understanding of designs and to establish a shared technical vision. A metaphor is something used to represent something else. For example, a metaphor is: the address module is like a GPS that makes sure the locations are correct.
Continuous Integration. This practice refers to the integration of the code and making sure that all of the code works well together. The practice is important because problems can quickly be detected before integrating defective code or mismatched design. Continuous integration ensures that integration testing is conducted on the code every time new functionality is added. This results in problems being detected immediately.
Test-Driven Development. This practice requires that the team write the test before developing the code. This means that in order to show that the developed tests work correctly, the code is expected to fail the first time the tests are run. Once the functionality has been correctly developed, the tests will then pass to show that the code has been written correctly. The idea behind test-driven development is that the test and feedback cycle is as short as possible so that the feedback can occur early.
Refactoring. This XP practice is a process of enhancing the code’s design without changing the functionality. The design should always be efficient where adding changes is easy. Refactoring removes duplicate code, increases cohesion, and decreases dependency among code modules.
Simple Design. XP supports simple design where the development team can quickly and easily make changes. The design should remain simple in that only the simplest things that work are included with no complicated structures or features. Design complexity increases risk and has historically resulted in failed projects.
Pair Programming. XP practices require that two developers (a pair) work on the code at the same time. This results in dynamic reviewing of the code at all times. This saves time because issues can be detected very early and it is beneficial to have two developers share the same knowledge of the code.
Recap of XP
We now provide a recap of XP.
• Developers are empowered to respond to changes at any time in the life cycle.
• XP is focused on teamwork to accomplish its goals.
• XP is a software development focused agile method.
• The customer drives the XP project and must always be available.
• Design is kept simple at all times.
• Feedback is provided early and continuously.
• Iterations are typically two weeks long.
• Software is delivered in small releases.
CHAPTER SUMMARY
We will now conclude this chapter by providing factors to consider when selecting either of the two most popular agile methods: Scrum and XP. Table 3.2 provides a side-by-side comparison of the two methods. When making a decision to use XP or Scrum, the project manager may want to select XP for web-enabled projects that require very little documentation and are restricted on their time to market. XP was designed to reduce the overhead associated with project management. With regard to Scrum, this method is more project management focused than XP. In addition, Scrum is more product focused than XP. We hope this information is helpful when making a decision upon which method to choose. Keep in mind that there are many more agile methods from which to select. The agile method selection process should be based on the needs of the organization or the project requirements.
This concludes our discussion on two different agile methods, Scrum and XP. Chapter 17 provides a discussion of additional agile methods.