Adapt to the context
First of all, XP is a set of values, principles, and practices and the idea is not to give us some strict rules to apply in any given conditions: XP itself organize the practices in primary and secondary, but more important, Kent Beck itself suggests that we have to adapt practices to our context - we might even change them a bit or create a new one, as soon as we respect values and principles.
Each practice is the practical application of some principle - so my main suggestion is: to focus on values and principles, try to understand them in deep, then analyze where you think your team is suffering the most and try to introduce practices to improve that, picking one of the suggested practices.
Once you will have more confidence in the values, principles, and suggested practices you will be even able to create new practices and be sure that they respect values and principles (doing this too early is risky!).
My favorite practices
I want to help you the most I can and give you my full perspective on this while also sharing my experience when I tried to use XP as a reference to setup the work of the team, so here are some of my favorite practices of XP, related to the values/principles I think each of them express the most.
Of course, the practices I list below may express more values or principles than the one I will highlight, but I will stick to what I think is the most important based on my thoughts and experience.
- The whole team: The team should include people with all the skills necessary to succeed, AKA organizing your tech and product people in cross-functional teams, one for each product/business line you have. A team is ideally made by Product Manager, UX Designer, DevOps engineer, Backend engineer, and Frontend/Mobile engineer. Avoid old organization models such as UX separated from Operations separated from Backenders separate from Frontenders, etc - that’s because you need to empower the team and give it the ability to solve business problems without blockers or dependencies.
Values: Simplicity, communication
Principles: Mutual benefit, Diversity, Accepted Responsibility
- Pair programming: Suggest Pair Programming as the default way of working: all development tasks are worked by two people together, with live feedback to one another. Don’t limit that only to the coding process, but also favor pairing between UX and frontends, for example, or any other task. I wrote “suggest” because this practice doesn’t work if imposed, the team must agree on using it or it will be a pain: considering this, start exploring it in learning moments or small task to see how it goes.
Values: Feedback, Respect
Principles: Self-similarity, Quality, Redundancy
- Weekly cycle: Priorities should be always respected, and to be agile we want to adapt the faster way possible. Organize your work week by week, deciding which are the most important things to work on in the next 7 days, and force the team to deploy in production AT LEAST every week before the next planning (even better would be to deploy in production multiple times a day!)
Values: Feedback, Simplicity
Principles: Flow, Baby steps
- Quarterly cycle: The desire to be ready to adapt must not be confused with the total absence of a mid/long-term plan: having clear where we want to go is important for the company, and so it is for the software development team. A plan is not to be confused with a deadline, it must adapt to changes too, but it’s useful to share a common path to be followed.
Values: Feedback, Communication
Principles: Improvement, Flow
- Slack: 20% of the time the team should slack of free time: this time allows the team to work without negative pressure and can be invested in multiple productive ways: for example, it can be invested in learning (conferences, courses, workshops, etc), technical tasks or other tools that brings value but can be easily rescheduled if an emergency occurs. This slack time will allow the team to have a sustainable and reliable pace of work, no matter what, covering all kinds of unplanned work that might show up or situations like someone being sick.
Values: Respect, Simplicity
Principles: Mutual benefit, Reflection, Opportunity
Those were just small tips from my experience to help you with a reflection: if you want to have a positive impact, start with the practice that think might solve the worst problem you have, following the theory of constraints.
Go Deeper
Here are some resources you can check if you want to go deeper and learn more about eXtreme Programming practices.
Books
- eXtreme Programming: Explained - The book about XP has a small section about the remote work context
Online
- What is XP? - by Agile Alliance blog