Software development has undergone a sea of transformations. With each passing year, project management approaches that are popular today will be obsolete tomorrow.
The birth of Extreme Programming (XP) marked the beginning of a new era.
Ken Beck, a software engineer, and one of the seventeen signatories of the Agile Manifesto created Extreme Programming in 1997 to produce high-quality software and adapt to the evolving customer needs.
Fast forward to over two decades later, Extreme Programming has organizations thronging to adopt it.
If you’re one among them, here is a detailed guide about Extreme Programming that you might want to read.
Here’s kicking off with the basics!
1. Planning: The primary stage is the planning stage, customers meet the development team with the requirements. The Product Owner along with the development team translates the requirements into user stories. The team further estimates the stories and creates a release plan to build the functionality brick by brick.
If estimating any of the stories is not possible, then spikes are introduced signaling that research is needed.
2. Design: The Designing phase is inclusive of the planning phase. However, it is excluded to stress its importance. It draws a connection to one of the XP values which is simplicity.
3. Coding: Coding is the phase where the code is created and implemented using standard XP practices like collective code ownership, pair programming, continuous integration, and coding standards. Collective code ownership encourages everyone to review code and all developers can add functionality, fix bugs, or refactor.
4. Testing: The team carries out unit tests or automated testing to assess if the system is working properly and acceptance testing or customer testing to determine if the entire system meets the initial requirements.
5. Feedback: The customers give feedback to the project managers and determine if the value expected is delivered.
Customers: Customers are actively involved in the project by drafting user stories, providing constant feedback, and creating the product backlog.
2. Developers: The developers build the product and perform unit testing and acceptance testing.
3. Trackers: Trackers are members who act as liaisons between the customers and the developers. Also called Managers, these trackers organize meetings, act as moderators, and track agile metrics such as velocity, burndown charts, and the like.
4. Coaches: Coaches play the role of mentors and guide the team by helping them implement the best practices of Extreme Programming. External agile coaches or consultants who have expertise in XP guide the team.
1. Simplicity: The team works on goals that are fixed and nothing beyond. Extreme Programming breaks the project into small phases making it easier for the team to produce the deliverables.
2. Seamless communication: The development team works as a close-knit unit where communication and collaboration are seamless. The team participates in the daily standup meetings where the progress of the project is discussed.
3. Timely feedback: XP is a subset of Agile where developers adapt to the customer requirements. The team delivers the software early in increments so that customer feedback is obtained faster so the final product is delivered as per customer requirements.
4. Respect: Extreme programming practices an “all-inclusive” policy where every member is valued and treated equally regardless of their designation. Their contributions, performance, and opinions are valued.
5. Courage: The fundamental principle of XP is to fail fast and learn early. Every team member is responsible for tasks and they need to be transparent about their progress. There is no need to sugarcoat things or be diplomatic.
Recommended reading: The Practical Guide To Writing Acceptance Criteria: Best Practices & Examples
1. Swift feedback: The team needs to collect feedback and act on it faster and not delay actions.
2. Assumed simplicity: The development team should work on the tasks that have the highest priority and not waste time on unnecessary tasks.
3. Incremental changes: Product increments perform better than building the entire project at once.
4. Welcomes change: If a customer wants changes, the developers should welcome the change and devise ways to incorporate the changes.
5. Quality deliverables: A team that works as a unit is always likely to deliver an optimum quality product.
1. Quick progress: XP builds products in increments which results in faster development in contrast to conventional methodologies that take years. XP projects at best take months because of the prioritization of tasks during each sprint. This enables continuous deployment and integration.
2. Transparency: Free flow of communication between team members means everybody is in the loop regarding the progress and development of a project. Daily Stand Up meetings are conducted so everyone is aware of their tasks and responsibilities.
This minimizes the chances of bugs and errors.
3. Saves costs: Since product development happens in increments, client feedback can be taken at the earliest and changes can be made. This saves a lot of developmental costs which is a drawback of the waterfall model.
4. Reducing unnecessary documentation: Extreme Programming focuses on creating user stories and less rigid and unwanted documentation.
5. Optimum quality deliverables: XP uses pair programming for development which provides less scope for bugs and failures. With collective code ownership, anyone can make changes to the code. All developers can add functionality, fix bugs, and refactor. This results in higher-quality deliverables.
6. Customer satisfaction: The customer is kept in the loop about the development process. Feedback is taken quickly and improvements are made which meet the customer’s expectations.
You might be interested in reading: Introduction to Acceptance Test Driven Development (ATDD)
1. Code overshadows design: Extreme Programming emphasizes programming where the design takes a backseat. This can be a problem if a product's USP is its design.
2. Not Remote Friendly: In Extreme Programming, the development team and the client must meet in person. This does not work where teams are geographically distributed.
3. Scarce documentation: While XP allows for making changes to the system, the changes aren’t documented properly. Without documentation, it is difficult to track failures and this has a cascading effect adversely affecting efficiency and productivity.
4. High stress on the developers: Extreme Programming has short deadlines which places developers under a lot of stress. The outcome is a suboptimal product filled with bugs and errors.
1. Test-Driven Development: Test-Driven Development(TDD) is a common practice for developing code that is simple, maintainable, and well-tested. The approach states that one should write “implementation code” only if there is a “failing test case”. It is an iterative approach for developing software products where –
The first step of exploration occurs during release planning, where the team and stakeholders decide what requirements and features they would like to put in their production. This is done by prioritizing requirements (those related to business needs) over features added based on estimations and risk factors of the team to deliver. Iteration planning follows a similar set-up only with iteration rather than release being the main focus in this phase.
3. Pair Programming: Pair Programming is an agile technique where two programmers work together in one workplace. While one developer writes the code, the other reviews the code, suggests corrections, and rectifies mistakes.
4. Refactoring: Refactoring refers to the improvement of the internal structure of a current program’s source code. Refactoring makes the code efficient and manageable. It minimizes technical debt as it is easy to clean as opposed to bearing heavy costs later. Refactoring makes the QA and debugging process complete without any impediments.
5. Continuous Integration: Continuous Integration is the practice of automating the merge of code changes from numerous developers into a single repository. Continuous integration ensures that all changes to the code are made in place so that in case of any problems, they can be fixed quickly instead of wasting time figuring out the fault.
6. Coding Standards: An agile team must have a common set of coding practices, formats, and styles. This enables all developers to read, share, and refactor without any difficulty and track who worked on a particular code.
This also promotes collective ownership.
7. Small Releases: Small Releases enable a minimum viable product for release. Small releases encourage projects to be broken down into smaller phases. The developers can work on tasks that are high priority and not waste time on unnecessary tasks.
8. System Metaphor: The system metaphor is defined as the visualization that every team member should be able to develop for a project when looking at high-level code, spotting bugs, and understanding how a system works.
One great way to design the system metaphor is by providing an overview of the codebase together with the other features such as microservices and projections that are used.
9. Collective Code Ownership: Collective Code Ownership refers to the authority of all the developers to make changes and review the code. It allows developers to evaluate and add bugs, and refactor.
10. Sustainable Pace: One of the principles of the Agile manifesto states sustainable development and healthy work-life balance. This not only improves happiness and productivity but also produces high-quality products.
11. On-site customer: Customer participation is important in extreme programming. The customer should provide feedback, determine priorities, and suggest improvements.
12. Simple Design: The best design is one that is simple and not complex. The design should pass all the tests and should be devoid of duplicate code. Refactoring of code is done at regular intervals which reduces technical debt. The simpler the design, the clearer the Definition of Done.
13. Automated Build: The team creates an automated build that compiles the code and runs automated tests and creates deployable packages. Regular and swift automated build helps in identifying the problems much faster.
You might be interested in reading: TDD vs BDD: Know The Difference
Should you need any help with Extreme Programming, we’re just a message away.