Extreme Programming Explained Quotes

“Cards on a wall is a way of practicing transparency, valuing and respecting the input of each team member. The project manager has the task of translating the cards into whatever format is expected by the rest of the organization.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Without the adjustment, you are working under a lie. Everyone knows it and has to hide to protect themselves. This is no way to get good software done and deployed;”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Inaccurate estimates are a failure of information, not of values or principles. If the numbers are wrong, fix the numbers and communicate the consequences.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“The constraint has shifted out of software development. Here's a sad but repeated story: a development team begins applying XP, dramatically improves quality and productivity, but then is disbanded, its leaders fired and the rest of the team scattered.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“First a small team writes a small system. Then they find the natural fracture lines and divide the system into relatively independent parts for expansion. The architects help choose the most appropriate fracture lines and then follow the system as a whole, keeping the big picture in mind as the groups focus on their smaller section.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“To achieve this his team had a sophisticated stress testing environment. When they wanted to improve the architecture they would first improve the stress tests until the system broke. Then they would improve the architecture just enough to run the tests. I suggested this strategy to an architect at another company. He complained of spending all of his time writing specifications and then explaining them to developers.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Customers may have a good idea of the general behavior they want to see, but testers are good at looking at "happy paths" and asking what should happen if something goes wrong. "Okay, but what if login fails three times? What should happen then?" In this role testers amplify communication.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“A team using the information provided by pay-per-use should be able to do a more effective job than a team relying for feedback only on license revenues.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Write contracts for software development that fix time, costs, and quality but call for an ongoing negotiation of the precise scope of the system. Reduce risk by signing a sequence of short contracts instead of one long one.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Don't make more versions of your source code. Rather than add more code bases, fix the underlying design problem that is preventing you from running from a single code base.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Change is not necessarily slow. A team eager or desperate for improvement can progress quickly. It doesn't need to wait long to assimilate one change before moving on to the next practice. If you change too fast, though, you risk slipping back into old practices and values. When this happens, take time to regroup. Remind yourself of the values you want to hold. Review your practices and remind yourself why you chose them. New habits take time to solidify.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“If I have the same logic in two places, I work with the design to understand how I can have only one copy. Designs without duplication tend to be easy to change.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Some of the teams who read and applied the first edition of this book didn't get the part of the message about the last responsible moment. They piled story on story as quickly as possible with the least possible investment in design. Without daily attention to design, the cost of changes does skyrocket. The result is poorly designed, brittle, hard-to-change systems.”
― Kent Beck, Extreme Programming Explained: Embrace Change