Extreme Programming

This post is about my basic understanding of Extreme Programming, in short XP. After joining Thoughtworks, I came to know about XP. The team I joined is upholding the XP practices very proudly and ensuring that it remains as much followed as possible. Having said that, I was trying to connect the dots between different aspects of XP including pair programming, quick feedback, shorter iterations, test-driven development and so and so forth.

All the new joiners in Thoughtworks are given the following book so that they can start exploring XP in more detail and be able to relate to it when added to the XP Team.

After reading this book I realized multiple things about XP which I want to share with you. I'm still exploring more about it, yet decided to share whatever I understood from this interesting book. 

Extreme programming is a guideline for effective collaboration and ensured quality. It's a methodology to improve not just as an individual but mainly as a team.

Extreme programming is "extreme" because it takes the effectiveness of principles, practices, and values to its extreme. It asks you to do your best and then deal with the consequences, that's extreme. Programmers get past with "I know better than everyone else and all I need is to be left alone to be the greatest." 

Further in the post, I will use the abbreviation XP for Extreme Programming.

XP is based on the 4Ps,

• Philosophy of communication, courage, respect, feedback, and simplicity.
• Principles of translating values to practices.
• Practices to express the values correctly.
• People share values and practices.

XP is about

• Estimating your work accurately
• Creating a rapid feedback loop
• Delivering quality the first time

XP says Stay Aware. Adapt. Change.

XP includes three major components, Values, Principles, and Practices. 

We will talk about each in detail.

Values 

Roots of things we like and don't like in any situation. 

XP embraces five values,

1. Communication
• Effective communication between people involved in the project whether internal or external. 
• Choosing the right medium for communication. Creating lengthy unmanageable documents for everything is not effective all the time, quick team meetings and one on one discussions may suffice in many cases.
• Ensuring inclusivity and respect while communicating for better outcomes.
2. Simplicity
• Simplicity needs to be planned while complexity is accidental. 
• Many engineers fall into this rabbit hole of making things complex rather than simply showing off or pretending to be experts. When it comes to Software, keeping things simple rewards very well in the long run to the team and organization. 
• Thinking in a direction to avoid wasted complexity as much as possible.
3. Feedback
• Keep sharing and receiving feedback.
• Feedback about your day-to-day work, involvement in the team, and overall effectiveness as a team member.
• Giving genuine feedback is equally important, be honest and respectful.
4. Courage
• Choose to do the right thing even when feel afraid.
• The team should create an environment to ensure everyone feels safe to speak on any aspect of work during meetings.
5. Respect
• Everyone on the team is important for the success of the project.
• I am an important member, so as you. Remember always.
• Ensuring respect in case of difficult situations by focusing on problem rather than person.

Principles 

The principles are a bridge between practices and values. 

XP embraces principles like, 

• Humanity 
• Create an environment where team members feel safe to speak up.
• Each member feels included.
• When it comes to accomplishment, rather focus on the team's accomplishment compared to individual-level accomplishment.
• Economics 
• Software development is even more valuable when it actually earns money.
• Focusing on quality but keeping focus on generating values economically will help team and organization to grow.
• Mutual Benefit 
• Values and practices must benefit the team now and future as well.
• The benefits of XP should not be limited to the team but should be extended to the customer.
• Self-Similarity
• Avoid reinventing the wheel, try to see if your existing setup or structure can be replicated for some other use or not.
• The more it gets replicated, the more feedback you will get for improving it in the long run.
• Improvement 
• Perfection is the enemy of good.
• XP focuses on delivering important things in smaller iterations. 
• Rather than giving everything perfect after months or years, XP recommends iteratively delivering things for better feedback and less overhead.
• Diversity
• Work together as a team for a given problem, ensuring each opinion and thought of all team members are taken into account.
• The team should comprise all required skillsets.
• Reflection 
• After every iteration, reflect and find what went well and what can be improved.
• Appreciate good work and discuss the area of improvement.
• Flow 
• Create a flow of deploying smaller increments of value frequently with the best quality.
• Opportunity 
• Problems are opportunities, defects or failures can be treated as an opportunity to find the gaps and correcting.
• Ensure the root cause of the problem is fixed. Fix the defect and ensure it should never resurface again.
• Redundancy 
• Do not remove redundancy that serves a valid purpose. 
• Some of the practices may sound redundant but keeping them running would still help. For example, pair programming and continuous integration give early feedback and help to avoid silly errors, which don't reduce the importance of any of the practices individually.
• Failure 
• When you don't know what to do, go for risking failure.
• You are stuck at the point where you have to choose one of the two possible approaches for the implementation and can't figure out which one is better suitable. Go ahead and try both.
• Have the courage to try and fail rather than play safe.
• Quality 
• You won't be able to figure out the best possible way every time.
• Do whatever best you can to deliver quality. 
• Keep looking for better and embrace change.
• Baby Steps
• Shorter cycles are like baby steps, which help to quickly correct and get early feedback.
• Small steps ensure minimum overhead and faster rollback if needed.
• Accepted Responsibility
• XP focuses more on accepting the required responsibility rather than enforcing it to any of the team members. 

Practices

Things you objectively do day to day. Practices are situation-dependent you may need to adapt to new practices based on the situation, values on the other hand do not have to change like practices. 

XP introduces the following primary practices,

• Sit Together 
• The more face time the more humane and productive the project.
• Sitting together embraces belonging and effective collaboration.
• Whole Team 
• Include people with all the skills and perspectives necessary.
• Informative Workspace 
• Your workspace should reflect your work.
• Someone walking into your team's space should get clarity about what's going on by looking at cards on the wall.
• Energized work 
• Work as many hours as you can genuinely productive.
• Do not work more to complete more, work effectively to accomplish necessary for the given day.
• More work doesn't mean great work.
• Pair Programming 
• Collaborate in pairs for effective efforts and better quality.
• Be open-minded while pairing, listen more. 
• Learn to get the opinions and perspectives of your pair attentively. 
• Stories 
• Divide major releases into smaller releases.
• Divide each release into smaller stories.
• If required divide stories into smaller tasks.
• Ensure to pick the most important items after discussing them with the customer.
• Early estimation of stories will help to plan well in iteration.
• Weekly cycle 
• Start with writing automated system tests and work during the week to make them pass.
• Quarterly cycle 
• Identify bottleneck, and find a theme(s) for the quarter. 
• Reflect and plan with the big picture.
• Mostly project manager should do this activity.
• Slack 
• Few met commitments go a long way toward rebuilding relationships.
• Deliver what you can with ensured quality and value rather than delivering n number or things with compromised quality and bugs.
• Ten-Minute Build 
• The automated build must finish within 10 minutes for rapid feedback.
• Continuous integration 
• Continuously integrating your changes with automated builds.
• Test First Programming (TDD) 
• Write system-level tests first for better quality and implementation.
• Your tests should depict the story and requirements. Making them pass should ensure completion.
• Incremental Design 
• Invest in the design of the system every day, and keep improving.
• Design decisions are subjective and depend on the nature of the project as well.

These are primary practices, there are certain corollary practices that may and may not be applicable in all cases but still adds a lot of value to your software development. We may talk about it in separate blog post.

XP iteration may look like the following,

• Identify and estimate high-priority items to be delivered in this iteration.
• Convert the requirements into stories
• Effectively estimate the stories
• Start with writing failing tests which likely going to pass by the end of the iteration.
• Work in pair to make failing tests pass.
• Continuously integrate and get feedback
• Reflect after each iteration

This is just the beginning of XP, however, the more your team will practice it the more effective and fruitful it will going to be in the longer run. 

Remember in XP,

"Make a change, observe the effects; then digest the change, turning it into a solid habit."