Extreme Programming by Kent Beck

Extreme Programming: Embrace Change by Kent Beck with Cynthia Andres

Who should read this book?

Developers who are looking to refine their Agile practices and gain deeper satisfaction from their work.

Agile coaches seeking to understand the fundamental principles behind popular Agile frameworks like Scrum—and how Agile connects to Lean.

Why You Should Read This Book

This book is a return to the roots of Agile. Like many, I was first introduced to frameworks like Scrum without much exposure to Extreme Programming (XP). Actually, this book served as my first deep dive into XP, and I was pleasantly surprised by what I discovered.

Here are a few reasons why I found it impactful:

• Connection between values, principles, and practices: The book expertly links these three foundational aspects, and the lessons apply far beyond XP and Agile. From an Operational Excellence perspective, which is a personal passion of mine, these insights were particularly meaningful.
• Understanding Scrum’s origins: If you’ve ever wondered where Scrum draws its influences from, this book provides that clarity, tracing Agile back to its roots in XP and Lean practices.
• Lean and Taylorism connections: As someone with a Lean Six Sigma background, I appreciated how the book integrates elements of Lean, Taylorism, and the Toyota Production System (TPS). It’s a refreshing look at Agile from a process improvement standpoint.
• Balanced perspective: Kent Beck does a brilliant job of addressing the needs of both developers and shareholders, preventing the material from becoming overly dogmatic or one-sided.
• Challenging assumptions: The book encourages readers to think critically about their current practices. Beck is candid about the assumptions and limitations of Agile practices, which helps avoid rigid adherence to any one framework.

Reading this book prompted me to reconsider how I support teams and organisations. It’s given me new perspectives on adapting or designing practices. In particular, this is helpful when frameworks like Scrum or SAFe don’t quite fit the context.

However, don’t expect a step-by-step manual. This book is more conceptual and abstract. While it was first published in 1999, the majority of its ideas remain relevant today. And for those that have evolved, Kent Beck’s keynote (linked below) provides a great update on his thinking.

Interesting extracts

• “No matter the circumstance you can always improve.
• You can always start improving with yourself.
• You can always start improving today.”

“XP is a path of improvement to excellence for people coming together to develop software. It is distinguished from other methodologies by:

• Its short development cycles, resulting in early, concrete, and continuing feedback.
• Its incremental planning approach, which quickly comes up with an overall plan that is expected to evolve through the life of the project.
• Its ability to flexibly schedule the implementation of functionality, responding to changing business needs.
• Its reliance on automated tests written by programmers, customers, and testers to monitor the progress of development, to allow the system to evolve, and to catch defects early.
• Its reliance on oral communication, tests, and source code to communicate system structure and intent.
• Its reliance on an evolutionary design process that lasts as long as the system lasts.
• Its reliance on the close collaboration of actively engaged individuals with ordinary talent.
• Its reliance on practices that work with both the short-term instincts of the team members and the long-term interests of the project.”

“Methodology is often interpreted to mean “a set of rules to follow that guarantee success.” Methodologies don’t work like programs. People aren’t computers. Every team does XP differently with varying degrees of success.”

“Driving is not about getting the car going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way. This is the paradigm for XP. Stay aware. Adapt. Change. Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn’t change, because change is going to happen; the problem, rather, is our inability to cope with change.”

“Values are the large- scale criteria we use to judge what we see, think, and do.

Making values explicit is important because without values, practices quickly become rote, activities performed for their own sake but lacking any purpose or direction. When I hear a programmer brush off a defect, I hear a failure of values, not technique. The defect itself might be a failure of technique, but the reluctance to learn from the defect shows that the programmer doesn’t actually value learning and self- improvement as much as something else. This is not in the best interest of the program, the organization, or the programmer. Bringing values together with practices means that the programmer can perform a practice, in this case root-cause analysis, at effective times and for good reasons. Values bring purpose to practices.

Practices are evidence of values. Values are expressed at such a high level that I could do just about anything in the name of a value. “I wrote this one-thousand-page document because I value communication. Maybe yes and maybe no. If a fifteen minute conversation once a day would have communicated more effectively than producing the document, then the document doesn’t show that I value communication. Communicating in the most effective way I can shows I value communication.

Practices are clear. Everyone knows if I’ve attended the morning standup meetings. Whether I really value communication is fuzzy. Whether I maintain practices that enhance communication is concrete. Just as values bring purpose to practices, practices bring accountability to values. Values and practices are an ocean apart. Values are universal. Ideally, my values as I work are exactly the same as my values in the rest of my life. Practices, however, are intensely situated.

Bridging the gap between values and practices are principles. Principles are domain-specific guidelines for life. Paul’s knowledge as a gardener exceeds mine at the level of principles as well. I might know to plant marigolds next to strawberries, but Paul under- stands the principle of companion planting where adjacent plants make up for each others’ weaknesses. Marigolds naturally repel some of the bugs that eat strawberries. Planting them together is a practice. Companion planting is the principle. In this book I present the values, principles, and practices of XP.”

“What do people need to be good developers?

• Basic safety – freedom from hunger, physical harm, and threats to loved ones. Fear of job loss threatens this need.
• Accomplishment – the opportunity and ability to contribute to their society.
• Belonging – the ability to identify with a group from which they receive validation and accountability and contribute to its shared goals. ◇ Growth-the opportunity to expand their skills and perspective.
• Intimacy – the ability to understand and be understood deeply by others.”

“Economics. Somebody has to pay for all this.”

“Where does the penchant for long hours come from? I’m often asked for “scientific” evidence for the practices in XP, as if science could somehow bear the responsibility for project success or failure. Work hours are one area where I wish I could turn this argument around. Where is the scientific evidence that members of a software team produce more value in eighty hour weeks than in forty hour weeks? Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.”

“Keep effective teams together. There is a tendency in large organizations to abstract people to things, plug-compatible programming units. Value in software is created not just by what people know and do but also by their relationships and what they accomplish together. Ignoring the value of relationships and trust just to simplify the scheduling problem is false economy.”

“Tests can provide a measure of progress. If I have ten tests broken and I fix one, then I’ve made progress. That said, I try to have only one broken test at a time. If I am programming test-first, I write one failing test, make it work, and then write the next failing test. My experience with getting the first test to work often informs my writing of the second. If I write tests based on unvalidated assumptions, I have to modify them all when the assumptions turn out to be wrong. System-level tests give me a sense of certainty that the whole system is working at the end of the week. “

“When picking descriptive names, it helps to pick a name whose opposite is unappealing. Who could possibly be for “unscientific” management? What Taylor meant by “science” was that to improve factory productivity, he would apply the methods of science: observation, hypothesis, and experimentation. He would observe a worker at a task, devise alternative ways of performing the task, observe these, and pick the best way to do the task. (One of his mottoes was “The One Best Way”.) All that was left was to standardize the execution of that task through the whole factory to guarantee improvement.

I don’t have space here to describe all the technical, social, and economic impacts of Taylorism, as it came to be called. The bibliography gives you several opportunities for further reading. While Taylorism has some positive effects, it also has some serious shortcomings. These limitations come from three simplifying assumptions:

1. Things usually go according to plan.
2. Micro-optimization leads to macro-optimization.
3. People are mostly interchangeable and need to be told what to do.”

“Their alternative social structure of work is critical to the success of TPS. Every worker is responsible for the whole production line. If anyone spots a defect he pulls a cord that stops the whole line. All the resources of the line are applied to finding the root cause of the problem and fixing it. At first, American workers can’t believe this. Chet Hendrickson told me the story of his brother-in-law who worked at a Toyota plant in Kentucky. He saw a defective door go by. His buddy said, “Pull the cord.” Nah, he didn’t want to get in trouble. Another defective door. Another. Finally, he pulled the cord. He was praised for telling the truth and pointing out flaws. Unlike mass-production lines where some- one “down the line” is responsible for quality, in TPS the goal is to make the quality of the line good enough that there is no need for downstream quality assurance. This implies that everyone is responsible for quality.”

“Software development is full of the waste of overproduction: fat requirements documents that rapidly grow obsolete; elaborate architectures that are never used; code that goes months without being integrated, tested, and executed in a production environment; and documentation no one reads until it is irrelevant or misleading. While all of these activities are important to software development, we need to use their output immediately in order to get the feedback we need to eliminate waste.”

“I don’t like the political and racial overtones of the word “offshore”: high-paid white people taking advantage of low-paid dark people and then complaining about “them” taking “our” jobs. “Offshore” implies an imbalance of power, the kind of imbalance that can easily derail soft- ware development. I use the term “multi-site” here because XP applies similarly to all geographically dispersed teams.

There are lots of reasons to run a project at multiple sites. Salary differential is only one of these reasons. The database people may be in Toronto and the telecom people in Denver. No matter the reason for considering multi-site development, it always comes down to a business decision: weighing whether the waste created by not sitting together is more than offset by other advantages.”