POSTS

Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series) Review

By Carlos Buenosvinos

January 1, 2014 - 12 minutes read - 2480 words

Happy new year to everyone! Today it’s January, 1st and I have finished reading “Extreme Programming Explained: Embrace Change, 2nd Edition”. If you love software development and agile practices, this book was the rules changer in the agile methodologies and software development in general. As I have done with other book reviews, here are my remarks. Buy it, seriously. You will fill the gaps about agile practices, so if you are doing Xp, Scrum, Kanban, Lean, etc. everything will gear together.

First of all, you should check the sum up article from http://xprogramming.com/what-is-extreme-programming</a>, then read the book. Enjoy my remarks.

My book remarks

Continuous integration—The latest code is built every night. The nightly builds provide us with insights about cross-component integration problems. Once per week we do an integration build where we ensure integrity across all components.
XP practices. In particular, they help us to reduce our development stress!
Having to make change your friend is a survival skill
Finally, we continuously improve existing code with refactoring.
The goal of Extreme Programming (XP) is outstanding software development.
Good teams are more alike than they are different.
No matter the circumstance you can always improve. You can always start improving with yourself. You can always start improving today.
It is about getting past our adolescent surety that “I know better than everyone else and all I need is to be left alone to be the greatest.” It is about finding our adult place in the larger world, finding our place in the community including the realm of business/work. It is about the process of becoming more of our best selves and in the process our best as developers. And, it is about writing great code that is really good for business.
You can’t control others’ expectations. You can tell them what you know about the project so their expectations have a chance of matching reality. My terror of deadlines vanished when I learned this lesson. It’s not my job to “manage” someone else’s expectations. It’s their job to manage their own expectations. It’s my job to do my best and to communicate clearly.
Defect rate—XP tests from the perspective of both programmers writing tests function-by-function and customers writing tests program-feature-by-program-feature.
During a release, the customer is welcome to substitute new functionality for functionality not yet completed.
XP assumes that you see yourself as part of a team, ideally one with clear goals and a plan of execution.
You can start writing tests before changing code, and gain benefit from doing so, long before you understand software development in a deeper way.
Values are the roots of the things we like and don’t like in a situation.
Just as values bring purpose to practices, practices bring accountability to values.
Bridging the gap between values and practices are principles. Principles are domain-specific guidelines for life.
The difference between what I think is valuable and what is really valuable creates waste.
XP embraces five values to guide development: communication, simplicity, feedback, courage, and respect.
Simplicity is the most intensely intellectual of the XP values. To make a system simple enough to gracefully solve only today’s problem is hard work.
Change is inevitable, but change creates the need for feedback.
If members of a team don’t care about each other and what they are doing, XP won’t work. If members of a team don’t care about a project, nothing can save it.
Other important values include safety, security, predictability, and quality-of-life.
At any time you should be able to trace a path from the work done back to an explicitly expressed need from the users.
People develop software.
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.
Time away from the team gives each individual more energy and perspective to bring back to the team.
Part of the challenge of team software development is balancing the needs of the individual with the needs of the team.
The time value of money says that a dollar today is worth more than a dollar tomorrow.
Mutual benefit is the most important XP principle and the most difficult to adhere to.
The same principle applies to software development: try copying the structure of one solution into a new context, even at different scales.
In software development, “perfect” is a verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, perfect your process, your design, and your stories.
“Best is the enemy of good enough” suggests that mediocrity is preferable to waiting.
Good teams don’t just do their work, they think about how they are working and why they are working. They analyze why they succeeded or failed. They don’t try to hide their mistakes, but expose them and learn from them. No one stumbles into excellence.
In contrast, the principle of flow suggests that for improvement, deploy smaller increments of value ever more frequently.
To reach excellence, problems need to turn into opportunities for learning and improvement, not just survival.
Knowledge is valuable and sometimes hard to come by.
When you don’t know what to do though, risking failure can be the shortest, surest road to success.
Projects don’t go faster by accepting lower quality. They don’t go slower by demanding higher quality. Pushing quality higher often results in faster delivery; while lowering quality standards often results in later, less predictable delivery.
Quality isn’t a purely economic factor. People need to do work they are proud of.
Responsibility cannot be assigned; it can only be accepted.
The person responsible for implementing a story is ultimately responsible for the design, implementation, and testing of the story.
Develop in an open space big enough for the whole team. Meet the need for privacy and “owned” space by having small private spaces nearby or by limiting work hours so team members can get their privacy needs met elsewhere.
No matter what the client says the problem is, it is always a people problem. Technical fixes alone are not enough. The other lesson I took was how important it is to sit together, to communicate with all our senses.
People need a sense of “team”: – We belong. – We are in this together. – We support each others’ work, growth, and learning.
Twelve is the number of people who can comfortably interact with each other in a day.
Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.
Declare a two-hour stretch each day as Code Time.
The ten-minute build is an ideal. What do you do on your way to that ideal? The statement of the practice gives three clues: automatically build the whole system and run all of the tests in ten minutes.
Team programming isn’t a divide and conquer problem. It is a divide, conquer, and integrate problem.
Invest in the design of the system every day.
Incremental design suggests that the most effective time to design is in the light of experience.
If I have the same logic in two places, I work with the design to understand how I can have only one copy.
The only person you can actually change is yourself.
Dictating practices to a team destroys trust and creates resentment.
Once you see an idea for improvement that makes sense to you, do it. If you can do it as a team, so much the better. If not, do it alone until you can share what you’ve learned with someone you trust.
No customer at all, or a “proxy” for a real customer, leads to waste as you develop features that aren’t used, specify tests that don’t reflect the real acceptance criteria, and lose the chance to build real relationships between the people with the most diverse perspectives of the project.
Software reflects the organization that builds it.
Keep effective teams together.
The XP practice Whole Team suggests that a variety of people work together in interlinking ways to make a project more effective.
On XP teams much of the responsibility for catching trivial mistakes is accepted by the programmers.
In Weekly Cycle, the first thing that happens to the chosen stories is that they are turned into automated system—level tests.
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?”
Interaction designers on an XP team choose overall metaphors for the system, write stories, and evaluate usage of the deployed system to find opportunities for new stories.
On an XP team, interaction designers work with customers, helping to write and clarify stories. Interaction designers can use all their usual tools during this process. They also analyze actual usage of the system to decide what the system needs to do next.
While the system is little the architect makes sure the system has just the right little architecture.
Architects sign up for programming tasks just like any programmer. However, they are also on the lookout for big changes that have big payoffs.
Project managers on an XP team facilitate communication inside the team and coordinate communication with customers, suppliers, and the rest of the organisation.
Planning in XP is an activity, not a phase. Project managers are responsible for keeping plans synchronized with reality.
In XP, product managers write stories, pick themes and stories in the quarterly cycle, pick stories in the weekly cycle, and answer questions as implementation uncovers under-specified areas of stories.
Both post-development defects and investment-to-return are indicators of team effectiveness much as a speedometer is an indicator of speed.
The better the team, the later it is willing to make big changes. This leaves technical publications always playing catch-up.
What would be the perfect documentation? It would be done exactly when the features it documents are done. It would be trivial to update when it was found in need of improvement. It would be cheap. It wouldn’t add any time to the basic development cycle. It would be valuable to the users. The writing of it would be valuable to the team.
If the manuals are online at your site, then you can monitor usage. If users never look at a certain kind of documentation, stop writing it.
In XP, valuable employees: – Act respectful. – Play well with others. – Take initiative. – Deliver on their commitments.
Hiring for XP teams can differ from existing hiring practices. XP teams put much more emphasis on teamwork and social skills.
Roles on a mature XP team aren’t fixed and rigid. The goal is to have everyone contribute the best he has to offer to the team’s success.
A programmer may be a bit of an architect. A user may grow into a product manager. A technical writer can also test. The goal is not for people to fill abstract roles, but for each team member to contribute all he can to the team.
XP isn’t intended to solve marketing, sales, or management problems.
The Theory of Constraints says that in any system there is one constraint at a time (occasionally two). To improve overall system throughput you have to first find the constraint; make sure it is working full speed; then find ways of either increasing the capacity of the constraint, offloading some of the work onto non-constraints, or eliminating the constraint entirely.
When we eliminate one constraint we create another.
The reward system and culture need to align with overall throughput instead of individual productivity for the change to stick.
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.
If you don’t have executive sponsorship, be prepared to do a better job yourself without recognition or protection.
Planning is a daily, weekly, and quarterly activity in XP. The plan can change to fit the facts as they emerge.
Plans are not predictions of the future.
Lowering the quality of your work doesn’t eliminate work, it just shifts it later so delays are not clearly your responsibility.
Satisfaction comes from doing quality work.
As you negotiate, don’t change the estimates or the budget.
I prefer to work with real time estimates now, making all communication as clear, direct, and transparent as possible.
Inaccurate estimates are a failure of information, not of values or principles. If the numbers are wrong, fix the numbers and communicate the consequences.
Good work and good teamwork build morale and confidence. If you can respect and trust your colleagues, you can be more productive and enjoy your work more.
Software testing is double-checking. You say what you want a computation to do once when you write a test.
Defect Cost Increase (DCI) is the second principle applied in XP to increase the cost-effectiveness of testing. DCI is one of the few empirically verified truths about software development: the sooner you find a defect, the cheaper it is to fix.
One is that the same people who make the mistakes have to write the tests.
With automated testing, running the tests themselves is a stress-reliever. The more stressed the team, the more tests it runs.
In XP, testing is as important as programming.
The question is not whether to design, but when to design.
The most powerful design heuristic I know is Once and Only Once: data, structure, or logic should exist in only one place in the system.
XP teams prefer simple solutions where possible.
Projects that move toward simplicity improve both the humanity and productivity of their software development.
Software development scales along many dimensions: Number of people, Investment, Size of the entire organisation, Time, Problem complexity, Solution complexity and Consequence of failure
If you are fixing a defect in an area, clean up while you are there. One objection is that this “extra” cleanup takes too long.
“End-to-end is further than you think”
No one walks around a development shop with a clipboard and a stopwatch.
Taiichi Ohno, the spiritual leader of TPS, says the greatest waste is the waste of overproduction. If you make something and can’t sell it, the effort that went into making it is lost.
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.
Beware of abandoning practices just because they seem difficult.