Extreme Programming in Agile – A Practical Guide for Project Managers and UDN Task Manager ers
We have received an awful lot of requests about extreme programming in waterfall – and that how one could benefit from it as a project manager . Just in case you didn’t know what extreme programming is, it is a form of agile framework where PMs get the best out of available resources in a software development environment.
Extreme Programming (XP), an Agile software development framework, is specifically designed for improving the quality of the software, the work process for the development team and increased customer satisfaction.
It is a method devised for a smoother and efficient software development life cycle (SDLC) for your projects, and it was first implemented on a project on March 6, 1996.
Extreme Programming works towards providing iterative and recurrent software releases throughout the project; instead of everything together after a single, long project development lifecycle.
These short iterative cycles help both team members and customers to assess and review the project’s progress throughout its development.
XP incorporates the following 5 values:
The core of XP is an interconnected set of software development practices. While it is possible to implement these practices in isolation, many teams have found that some practices reinforce the others and should be done in conjunction. This can enable fully eliminating the risks you often face in software development.
The original twelve practices for XP comprise:
Over the years, teams have found that some practices reinforce the others. To eliminate risks, these should be unified. The following descriptions include some of the refinements based on various teams’ experiences:
Whole Team : Teams should comprise cross-functional groups of people with different skills. In this way, they can complement each other to accomplish a specific outcome.
Sit Together: Most people agree that face to face conversations are the best form of communication. Teams should sit together without barriers to communication e.g. cubicle walls.
Informative Workspace : Teams should be arranged to sit in a way to make the team’s work transparent to each other and the affiliated people outside the team.
Energized Work : This means making sure that a person is mentally and physically healthy to focus on work. This also implies there should be no over-work and respect teams to support their mental and physical health as well.
Also Read:
How to Manage a Project like a Pro in today’s Work Environment?
Pair Programming : The idea behind this practice is that 2 brains are better than one. Pair Programming refers to software production through 2 people sitting at the same machine. By this, there is a continuous work review and problems receive a faster response. This method has been shown to improve quality and stay more focused.
Stories : Stories define the features that the product should have that would be meaningful to customers and users. These stories are used for planning and also serve as reminders for further conversations.
Weekly Cycle : The first day of every week, the team meets to reflect on the progress to date. The stories that should be delivered in the week are selected by the customer. The team determines how to approach those stories. The goal behind this is to achieve a running, verifiable feature by the end of the week. The fixed period allows for the production of a feature that can be shown to the customer for feedback.
Quarterly Cycle: The purpose of the quarterly cycle is to check the detailed work of each weekly cycle in the context of the overall project. The customer provides the overall plan for the team within a particular quarter. This not only gives the team a view of the project but also helps the customer to work with other stakeholders involved.
Slack : This implies adding a few, low priority tasks or stories in the weekly and quarterly cycles. If the team is lagging on more important tasks, these can be dropped. Else, these will also be completed, increasing the chances of meeting the estimated schedules.
Ten-Minute Build : The entire system and all of the tests should be run within 10 minutes. If the time exceeds this limit, multiple reruns will cost larger periods between errors. This practice encourages automation of the build process, making it feasible regularly, to run all of your tests.
Continuous Integration: This practice encourages immediate testing of new code to the existing larger codebase. This helps catch and fix integration issues sooner. This practice requires discipline and depends on the practices of Ten Minute Build and Test First Development.
Test-First Programming : Instead of following the regular way i.e.,
Develop Code -> Write Tests -> Run Tests
The practice of Test-First Programming takes the path of:
Write Failing Automated Test -> Run Failing Test -> Develop Code to Make Test Pass -> Run Test -> Repeat
This practice, too, reduces the feedback cycle for issue identification and resolution. This results in a reduction in the number of bugs that get introduced into production.
Incremental Design : This practice portrays doing a certain amount of work upfront to understand the breadth-wise perspective of the system design. After that, work further on the details of a particular aspect of the design when specific features are delivered. This approach reduces the cost of changes and allows you to make design decisions when necessary based on the most current information available.
XP incorporated particular practices for your team to follow and does not establish specific roles for the team members. However, according to the requirement, the 4 most common roles are:
The Customer: The XP Customer is expected to actively participate in the project. The Customer makes all of the business decisions regarding the project such as:
The Developer : Developers realize the stories identified by the Customer, which means deliver a project with decided features.
The Tracker : The tracker is an optional role and depends if the team requires one. This is carried out by one of the developers for keeping track of relevant agile metrics , and it is for progress evaluation and identification of key areas for improvement. This is important for progress tracking and identification of key areas for improvement. Some of these metrics may include the amount of time worked, amount of overtime, the passing and failing tests, velocity, and reasons for variations to velocity.
The Coach : This role is helpful particularly if the team is just starting up. The Coach can be an outside consultant who has used XP before and can help mentor the team on the XP Practices as well as self-discipline. Employing the Coach helps avoid potential mistakes that new teams may make, expediting the project.
The XP lifecycle can be explained concerning the Weekly Cycle and Quarterly Cycle.
To begin with, the customer defines the set of stories. The team estimates the size of each story, which along with relative benefit as estimated by the customer, indicates the relative value used to prioritize the stories.
In case, some stories cannot be estimated by the team due to unclear technical considerations involved, they can introduce a Spike. Spikes are referred to as short, time frames for research and may occur before regular iterations start or along with ongoing iterations.
Next comes the release plan: The release plan covers the stories that will be delivered in a particular quarter or release.
At this point, the weekly cycles begin. The start of each weekly cycle involves the team and the customer meeting up to decide the set of stories to be realized that week. Those stories are then broken into tasks to be completed within that week.
The weekends with a review of the progress to date between the team and the customer. This leads to the decision if the project should continue or if sufficient value has been delivered.
XP for Krizp System
Krizp Solution was a startup, web-based development company in India. Their business plan encompassed the creation of web portals for other small companies or educational institutions. The company began as a part-time business, employing people that were already working for other major IT organizations. The plan was to continue full-time only if the startup ventured into a success. There was no framework for their software development processes as it was just a startup company with not many projects and a few employees.
The company lacked a structured approach to software development. With initial requirements jotted down on paper, further information and clarifications were received from the customer via phone calls. Usually, the major changes in requirements did not come about until the customer review, which was after the solution was developed.
Other than for bug fixing , the developers had little or no communication with each other. They worked separately on different features. This led to becoming a barrier for discussions regarding improvement in working methods.
Moreover, the projects were not documented. There was no project manager to track the projects or to make sure that the requirements laid out by the customer were being met. The developers worked only on what was asked to be done.
The team at Krizp System was introduced to the concepts behind the different Agile frameworks. The XP method was employed over a span of one month and the results were assessed.
The CEO of the company took on 2 roles: the customer representative and the tracker. For his first role, he prioritized user stories, delegating them to the development team , and had regular communication with the customer. As the tracker, he kept track of the time to complete specific tasks. The CEO also initiated the planning game every week (or at least once in four days), as the project was small and developers could complete tasks in one user-story faster. However, the customer was available for direct communication only twice per month and the rest of the time he was in contact through phone calls and e-mail.
The Paired Programming technique was adopted whereby both the developers worked together. After task completion, both of the developers reviewed the code with the CEO.
Customer tests were introduced and the team worked on continuous design improvements, which were about 12-15 per month.
Summary
The XP approach seemed to have a good impact on the software development cycle for the company. Some of the positive changes included:
To assess the practical applications of Waterfall vs. Extreme Programming, a research study was conducted through 2 case studies: one at IBM and the other at Sabre Airlines. Each case study compared the waterfall approach to the XP approach.
In the first case study, at IBM, the researchers wanted to study the impact of adopting the XP approach on productivity, quality, and customer satisfaction. A year-long study was conducted on a team of 7 – 11 members regarding the adoption of XP practices. The team was responsible for developing Servlet/XML applications for a toolkit utilized by other IBM teams to create products for external customers. The case study analyzed 2 approaches on consecutive releases of the same product. The first one was the traditional waterfall approach and the second was XP.
In the second case study, at Sabre Airline Solutions, the same method was used i.e. comparing 2 approaches through different releases of the same product. The team worked on developing a scriptable GUI environment for external customers to develop customized end-user and business application. The team comprised of 6-10 members. The old release was finished 3 years prior (spanning 18 months) using the waterfall method whereas the new release was completed recently (spanning 3.5 months), using XP.
The first step was to establish an Extreme Programming Evaluation Framework (XP-EF), which comprised three parts: XP Context Factors (XP-cf), XP Adherence Metrics (XP-am) and XP Outcome Measures (XP-om):
In addition to the framework, interviews were conducted with team members and customers to help understand incorporating XP by the team for the customer’s satisfaction.
Summary
At IBM, the XP method seemed more productive compared to the waterfall method by the following measures:
At Sabre Airlines, similar results were noticed:
Use Case 1:
Problem Statement: The company website needs to be redesigned.
Actors: Customer, Developers, Tracker
Using XP:
Use Case 2:
Problem Statement: A client requires a game to be developed from scratch.
Actors: Customer, Developers, Tracker
Regular Flow of Events:
Using XP :
UDN Task Manager is a Task Management System that supports the Agile method of Extreme Programming framework. It is an online task management application designed specifically for teamwork and project delivery. Regardless of the industry, UDN Task Manager facilitates the XP methodology and contributes to effective project planning and process alignment.
The following are some of the ways UDN Task Manager can help you plan and achieve your project goals better, all within the XP framework.
Meeting Scheduling
You can schedule your sit-ins, weekly meeting as well as quarterly meetings beforehand. The agenda and timings of the meetings can be specified. You may define a fixed time for the meeting or send out a suggested time to the team, to be finalized after team response.
This application also allows you to note down all the important points discussed in a meeting. The minutes can be then reviewed and published for the rest of the team.
Team Allocation
You may arrange your team and the roles they will undertake through the team allocation section. You can easily define roles for the developers, the trackers, and the customer.
Project Creation
The customer may create the project and specify the requirements. The customer can also define the budget and timeline.
Task Creation and Assignment
The customer can create stories by creating tasks within the project. The tasks will comprise a list of activities to complete under one story. These stories can then be assigned to the programmers.
If the stories are completed before time by some of the team members, the customer can assign them the “slack” tasks i.e. lower priority tasks within the remaining timeline. This saves time working faster towards project completion.
Also See:
Introducing UDN Task Manager 2.0 – Our most awaited update yet
Project Flow
The Project Manager or Tracker can help keep track of the project flow through the Timesheet module. This module allows for effective monitoring and evaluation of project progress. It helps individually assess the timeline for different tasks as well and the milestones reached or pending.
Easy Collaboration
At times it is not possible to hold face to face meetings e.g. when a certain team is working on another site. In such cases, the automated updates on projects, tasks, and meetings can ensure timely and effective team collaboration and discussion. This avoids time being wasted in the manual arrangement of project and task follow up, communicating meeting of minutes, or project update.
Real-Time Comments provides an easy way to communicate with the team. Whether it is the exchange of information or new ideas, this makes it easy for the team to stay on the same page.
The interdependent tasks are highlighted and each team member can check the updates instantaneously as updated by the other team members. This keeps the team updated on the changing situations and in planning the next task, accordingly.
Moreover, the customer can directly collaborate with the team and update any change in requirements.
Transparency
UDN Task Manager gives a transparent view of all the projects and corresponding tasks and sub-tasks through its Taskboard. Any project created or modified is communicated to the team, immediately. There is no need for rechecking progress updates, meeting invitations or project reports.
The tasks updated, modified or deleted paves way for the entire team to be fully aware and know exactly what is being accomplished when.
With its Filter option, you can choose to see updates for selected projects based on priority or the task at hand. With the Status option, the status of the selected task can be seen whether it has started or not, completed or in progress.
Conclusion
This write-up details how you can benefit from XP as an Agile worker. In addition, UDN Task Manager is created to perform such requirements within the domain of extreme programming and waterfall techniques. Therefore, do give it a read and don’t forget to share your thoughts through the comments section below. Alternatively, you can email us at .
