I have been an advocate of Extreme Programming (XP) practices for well over a decade. To me, Agile software development means more than just an agile development process, it means that our code is agile and able to respond to change easily. This doesn’t happen by accident. It’s a result of following good programming principles and practices that support writing modular, maintainable, and changeable code.
It’s not enough to write software to make a computer do a specific task. The software that we write has to be agile. It has to be changeable without incurring a large amount of rework. It has to be safely extendable so that we’re not putting our systems and our users at risk as we add new features.
Many people even within the industry are unaware that we have solutions to most of these problems. We have well-defined methodologies that allow us to transform existing code into designs that allow us to accommodate new features and we are able to do these things in a safe and repeatable way. In other words, software engineering can be just like any other form of engineering in terms of having standards and practices that support us.
I found that many of the practices from Extreme Programming as well as the concepts from the design patterns movement, object-oriented programming and functional programming movements, software craftsmanship movements, as well as Scrum, Kanban, and Lean Software Development movements. All of these approaches are about addressing different aspects of software development and together they often form whole solutions to previously intractable problems.
Our industry has come a very long way in terms of being able to build reliable systems cost-effectively but the problem is that these ideas are not common knowledge throughout the industry and so the benefits of these practices that are used by some of the top corporations in the world haven’t really trickled down into the rest of the community of software development.
The whole discipline of software development is rapidly evolving and so it’s important not to just keep up with the latest tools and technologies but also to keep an understanding of the fundamentals fresh and top of mind so that we understand the reasoning behind the core practices and how to do things in standardized ways so that they’re straightforward to integrate with other people’s code.
We’re trying to build a discipline, after all. That means that the tools and techniques that we build have to work for all of us and we have to arrive at some level of consensus and agreement for what the standards and practices should be for developing software.
I think Extreme Programming offers a core set of developer disciplines that are highly valuable. I think our industry would be far better off if we paired more often and place more of an emphasis on refactoring code safely and writing good unit tests. I think these things raise the level of professionalism in our industry.
When I think about a minimum set of developer practices that really support an iterative process of software development that we do with Agile then it’s clear that the practices of Extreme Programming are essential when doing Scrum.
I find test-driven development to be invaluable for writing testable code that allows me to refactor my design safely. I find that refactoring is extremely valuable for allowing me to transform code from one design to another, which often is required when adding new features to a system. This is the kind of knowledge that makes us professionals and lets us build software in a consistent way.
So, many of the ideas that are embodied in Extreme Programming are some of the most valuable ideas in software development that I’ve ever come across. Even over a decade and a half later I still find that many of the ideas from Extreme Programming represent the best approaches that I found for object-oriented development.
{2 Comments }
Previous Post: « Scrum and XP
Next Post: Encapsulate Change »
A very good article !
It is a shame it may go unnoticed because of the publication date 🙁
To add to the debate, to me, the problem with XP is its (absence of) marketing.
That is, if you try to explain to someone how to build a software, and you are a scrum adept, conversation will go like :
“We are going to use SCRUM to build the software”
“Oh, what is it thing ?”
“Well, basically, it is a method where you have someone (entitled product owner) who is in charge of WHAT we are going to do; then you have the technical team who is in charge of the HOW and finally you have a coach (entitled scrum master) who is in charge to control that both cooperate adequately to deliver the best software they can in the minimum time possible”
“Oh fine, let’s do that”
Now, if you try to sell XP, you are in much more trouble
“We are going to use XP to build the software”
“”Oh, what is it thing ?”
“Well, basically, you trust the members of the team to organize themselves around well established practices to deliver a high quality software that match the needs at hand. This will also give us the ability to change the software easily later to adapt to new needs”
“Euh well, is that going to work if no one is in charge ?”
“Well, the team is in charge. They will adapt to …”
“Euh ok, but how are we sure it is going to work if no one is really named ?” (also found as “how are we sure it is going to work if no one tell them what and how to do ?”)
The rest of the conversation is not needed, you have already lost the battle if you try to explain that the team is going to adapt and that you have to be people oriented instead of process / tool oriented (as well as other agile manifesto principles).
In 90% of the cases, they will go SCRUM, as they find it more predictable and in accordance to their existing practices.
They will choose SCRUM even if the end result will be a disaster if the team does not use XP practices like minimum viable product, pair programming, TDD, code reviews, continuous integration, …
That is because the bad consequences of disrespect to these practices are not immediate and often come way later (when the team has been changed usually)
So that is why I always avoid to name XP (and I also avoid to name SCRUM, because so much people are doing a mess with that word nowadays). I basically gave up on the words agile and lean, except for “marketing” purposes.
If you ask me to build a software for you, I will say
“We will need someone who knows what to do and we need someone who knows how to build a software based on well established practices. Then, based on the knowledge of these 2 people, we will need a small team to build a small concept that we will test with real users. After you’ve done that and you have some customers, the rest will be obvious”
Sorry for such a long comment 🙂
Have fun
Hi Chris,
Thank you for the comment.
I think there’s a general misunderstanding about what Scrum is and isn’t. According to its creators, Scrum is a MINIMAL framework for finding problems when managing incremental development, like the kind we do when building software. Scrum does not say how to build the software and instead says we should use Extreme Programming (XP) practices when building software. Scrum was never intended to replace XP, it was always intended to complement XP.
But somehow people think that Scrum and XP are mutually exclusive. That’s crazy. When companies end up adopting Scrum without any technical practices they fail. It may take five years, but they accumulate so much technical debt that they often can’t respond to market demands.
Look at the Agile Manifesto. Every single one of the original authors of the Agile Manifesto are software developers. So, Agile was invented by software developers for software developers. Unfortunately, management in a lot of companies seemed to have forgotten this fact.
You said that 90% of the Scrum community don’t use XP practices and that is correct, according to all my research. Take it from someone who has worked with thousands of software developers, we are constantly reinventing the wheel. However, the teams that are doing Scrum and XP well together are reaping huge rewards and are consistently outcompeting those who don’t pay attention to the quality of the product they produce.
Ultimately, the market will sort out those whose code can’t compete from those who can. The ability to respond to last-minute changes will be a big part of that.
I hope this helps,
David.