How strongly do I recommend Extreme Programming Explained?
8 / 10
This book surprised me. I expected an outdated and dogmatic instruction guide. Something extreme. Instead I found a solid primer to agile development based on principles and basic practices, written in a chill conversational tone.
Extreme Programming Explained is a good book for people and teams that want to embrace agile, know some of the practices, but struggle because they haven’t yet connected those practices to underlying principles.
Top Ideas in This Book
I expected XP to feel almost religious and perhaps in 1999 it did feel highly opinionated. But today, the areas XP embraces are just considered best practices.
Discrete project phases make us feel secure because they promise predictability. But that predictability is an illusion.
In practice, we want continuous flow of work through the system and that requires cross-functional teams with limited external dependencies.
The classic project management triangle includes Time, Cost, and Scope. At the center is quality.
The trouble comes when developers try to negotiate quality. Even senior level developers make this mistake. Instead they should focus on managing scope, time, and cost, in that order.
When projects are running behind or additional scope is added, teams express stress and frequently revert to past unsuccessful and unproductive behaviors.
In these stressful environments is when teams need to trust their training the most.
Construction is different from software in two major ways:
Unfortunately many practitioners and stakeholders still think about software development using the same mental model as construction, resulting in misalignment between the problem and approach.
Beck mostly argues for TDD but accepts either order. More important is ensuring that quality tests are written.
One disheartening fact is that developers will spend a significant portion of their lives building systems that nobody uses.
Although not a stated goal or principle, waste prevention and reduction is a secondary benefit of XP. In practice teams developing and releasing iteratively are less likely to build features nobody uses because the usage feedback loop hits earlier and more often.
Teams implementing XP or any agile framework should expect growth in waves with lulling periods between.
I’ve interviewed a lot of software engineering candidates who tell me they believe in automated testing, but have never really done it. That’s a good start. But doing it for real is what makes you a true believer.