My first exposure to anything Agile was with eXtreme Programming (XP) back in 1999. While it had many process steps similar to what Scrum and Kanban offer today, the thing that really differentiated XP was it’s focus on technical practices. It’s those technical practices that we are usually referring to when we talk about XP today.
Yet, the practices themselves weren’t intended to be end-states. They were merely the best practices that we knew about at the time, and today we know about a number that are even better. Continuous delivery and ensemble/mob programming weren’t even a thing at that time and yet they’re both completely in line with what XP advocates.
The really important thing about XP is really in understanding where the “extreme” in the name comes from. The basic idea is that if we believe that a practice or approach is good then instead of doing it a little bit, let’s turn it up to extreme levels and do it all the time.
- If we think that testing is a good thing then let’s do it all the time, by writing the tests first. (TDD, BDD)
- If we think that talking to the customer is a good thing then let’s get them on the team so we can talk to them all the time. (Onsite customer)
- If we think that keeping the code integrated is a good thing then let’s do it constantly. (continuous integration)
When we introduce some of these practices today, we often get push-back on the specific practices, while missing the intention behind it. If you don’t like the specific practice that we’re doing, then find a different way to turn the good up to extreme levels.
XP is “extreme” because it doesn’t settle for “good enough”. That seems like a positive to me.