Praise for Extreme Programming Explained, Second Edition

My only beef is that our profession has gotten to a point where such common-sense ideas are labeled 'extreme'...

Do not be frightened by the name, it is not that extreme at all. It is mostly good old recipes ad common sense, nicely integrated together, getting rid of all the fat that has accumulated over the years.

The XP Series

(XP) is a discipline of the business of software development that focuses the whole team on common, reachable goals.

XP practices are chosen for their encouragement of human creativity and their acceptance of human frailty.

XP teams produce quality software at a sustainable pace.

XP aims to achieve these goals (accountability, transparency and outstanding results) by celebrating and serving the human needs of everyone touched by software development sponsors, managers, testers, users, and programmers.

Foreword to the First Edition

Delivering software is hard, and delivering quality software in time is even harder. To make it work requires the disciplined use of additional best practices.

Preface

The goal of Extreme Programming (XP) is outstanding software development.

Software can be developed at lower cost, with fewer defects, with higher productivity, and with much higher return on investment.

Chapter 1. What is XP?

Extreme Programming (XP) is about social change.

It is about letting go of habits an patterns that were adaptive in the past, but now get in the way of us doing our best work.

It is about being open about what we are capable of doing and then doing it.

You need both technique and good relationships to be successful. XP addresses both.

XP is a style of software development focusing on excellent application of programming techniques, clear communication and teamwork.

XP includes:

• A philosophy of software development based on the values of communication, feedback, simplicity, courage and respect.
• A body of practices proven useful in improving software development. The practices complement each other, amplifying their effects. They are chosen as expressions of the values.
• A set of complementary principles, intellectual techniques for translating the values into practice, useful when there isn't a practice handy for your particular problem.
• A community that shares these values and many of the same practices

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 last as 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 an the long-term interests of the project.

XP can be described this way:

• XP is lightweight. In XP you only do what you need to do to create value for the customers.
• XP is a methodology based on addressing constraints in software development. ... 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 dos XP differently with varying degrees of success.
• The values and principles behind XP are applicable at any scale.
• XP adapts to vague or rapidly changing requirements.

XP is my attempt to reconcile humanity and productivity in my own practice of software development and to share that reconciliation.

The pursuit of excellence in technique is critical in a social style of development.

If you can accurately estimate your work, deliver quality the first time, and create rapid feedback loops; then you can be a trustworthy partner.

XP teams play full out to win and accept responsibility for the consequences.

but it is always best to act as if there is going to be enough.

You can do your best work even when there are constraints. Fussing about the constraints distracts you from your goal. Your clean self does the best work no matter what the constraints are.

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.

How does XP address the risks in the development process?

• Schedule slips - XP calls for short release cycles, a few months at most, so the scope of any slip is limited. Within a release, XP uses one-week iterations of customer-requested features to create fine-grained feedback about progress. Within an iteration, XP plans with short tasks, so the team can solve problems during the cycle. Finally, XP calls for implementing the highest priority features first, so any features that slip past the release will be of lower value.
• XP always keeps the system in deployable condition.
• Defect Rate XP tests from the perspective of both programmers writing tests function-by-function and customers writing tests program-feature-by-program-feature.
• XP calls for business-oriented people to be first-class members of the team.
• XP shortens the release cycle, so there is less change during the development of a single release.
• XP insists that only the highest priority tasks are addressed.
• Staff turnover XP asks programmers to accept responsibility for estimating and completing their own work, gives them feedback about the actual time taken so their estimates can improve, and respects those estimates. The rules for who can make and change estimates are clear. Thus, there is less chance for a programmer to get frustrated by being asked to do the obviously impossible... New team members are encouraged to gradually accept more and more responsibility, and are assisted along the way by each other and by existing programmers.

XP assumes that you see yourself as part of a team, ideally one with clear goals and a plan of execution. XP assumes that you want to work together. XP assumes that change can be made inexpensive using this method. XP assumes that you want to grow, to improve your skills, and to improve your relationships. XP assumes you are willing to make changes to meet those goals.

What is XP?

• XP is giving up old, ineffective technical and social habits in favor of new ones that work.
• XP is fully appreciating yourself for total effort today.
• XP is striving to do better tomorrow.
• XP is evaluating yourself by your contribution to the team's shared goals.
• XP is asking to get some of your human needs met through software development.

My Summary

The XP is presented as a change of the practices applied in software engineering at the time of the book's publication. It proposes not only technical but also relationships lead to good businesses.

XP includes values, principles, practices and a community.

It's distinguished by waterfall methodologies due to its short cycles, incremental planning, responding to business changes, automated tests, evolutionary systems and close collaboration. To say only a few.

XP is lightweight and focused to do the simplest that delivers value to customers. It's a methodology that addresses constraints in software development. It's not a recipe, rather each team will apply XP differently with varying degrees of success. XP can be applied at any scale due to its values and principles. Even though XP works in situations where requirements don't change it shines in contexts with rapidly changing requirements.

It tries to boost productivity by recognizing the importance of humanity. Of course, the pursuit of technical excellence is critical in a social style of development. It proposes that if you can apply techniques that will accurately estimate work, deliver software with quality and create rapid feedback loops, and ultimately business value you'll be considered a trustworthy partner.

When applying XP you apply 100% of what you got, you act to achieve your best and you are able to achieve your best even when there are constraints.

XP addresses risk at all levels of software development:

• XP proposes release cycles ( a few months at most) to reduce time to market and get feedback earlier. Within a release the every week the team gets feedback about their progress. Short release cycles also reduce the changes during development and increase the flexibility for business changes.
• XP teams also prioritize work and focus on the highest value.
• The business is considered first-class member of the development to seek for the highest value delivers and help to refine the business.
• XP focus on quality to reduce defect rate and in automation to ensure the system is always in a ready to deploy state.
• XP teams are responsible for doing the estimate and for completing their work. This reduces frustration from missed impossible deadlines assigned top down to developers. Also, it's expected that a new team member will gradually accept more and more responsibilities.

XP assumes that you believe at teamwork, that changes shouldn't be expensive, that you are seeking technical excellence and to improve your relationships. You'll have to change to achieve this goals.

Section 1: Exploring XP

Chapter 2. nos livros da lista, mas achei os títulos com Learning to Drive

"...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.

Customer dive the content of the system. The whole team drives the development process. XP lets you adapt by making frequent, small corrections; moving towards your goal with deployed software at short intervals. You don't wait a long time to find out if you were going the wrong way.

Customers (internal or external) start with a general idea of what problems the system need to solve.

The customers on the team need to keep in mind where on the horizon they want to go even as they decide, week-by-week, where the software should go next.

As development continues, the team becomes aware of which of their practices enhance and which of their practices detract from their goals.

My Summary

Change will occur no matter what. We have to be ready to work with it. The author uses driving as an analogy for XP and changes. Stay aware. Adapt. Change.

This analogy works in two different levels:

• Customer: You start with an idea of what you want to build, and you adapt and apply small corrections in order to come closer to your goal.
• Development: Similarly for development, you start with a set of practices, and as the project evolves you improve these practices by understanding what you have to enhance in these practices.

Chapter 3. Values, Principles and Practices

Practices are the things you do day-to-day. Specifying practices is useful because they are clear and objective. You either write a test before you change code or you don't.

Call this level of knowledge and understanding values. Values are the roots of the things we like and don't like in a situation.

Making values explicit is important because without values, practices quickly become rote, activities performed for their own sake but lacking any purpose or direction.

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 elf-improvement as much as something else.

Values bring purpose to practices.

Just as values bring purpose to practices, practices bring accountability to values.

Principles are domain-specific guidelines for life.

It is a start but it isn't enough for you to master XP.

My Summary

Third chapter starts with an analogy about learning the basics about a skill and being a gardening master.

Level of understanding:

• Practice: Clear and objective. Either you do or you don't. A place to start. Value's accountability.
• Principles: The bridge between practice and value. It's domain specific.
• Values: The roots of the things we like and don't like in a situation. A highly developed sense of good and bad. Experience. Practice's purpose.

You are not an extreme programmer master because you read a book.

Chapter 4. Values

He knows in his bones what matters and what doesn't.

The difference between what I think is valuable and what is really valuable creates waste.

What actually matters is not how any given person behaves as much as how the individuals behave as part of a team and as part of an organization.

XP embraces five values to guide development: communication, simplicity, feedback, courage and respect.

Communication

What matters most in team software development is communication.

When problems arise in development, most often someone already knows the solution; but that knowledge doesn't get through to someone with the power to make the change.

However, motion without communication is not progress.

When you encounter a problem, ask yourselves if the problem was caused by a lack of communication.

Communication is important for creating a sense of team and effective cooperation.

Simplicity

To make a system simple enough to gracefully solve only today's problem is hard work.

Simplicity only makes sense in context.

Improving communication helps achieve simplicity enabling unneeded or deferrable requirements from today's concerns.

Feedback

Directions set in advance of experience have an especially short half-life. Change is inevitable, but change creates the need for feedback.

Being satisfied with improvement rather than expecting instant perfection, we use feedback to get closer and closer to our goals.

XP teams strive to generate as much feedback as they can handle as quickly as possible.

The sooner you know, the sooner you can adapt.

For example, suppose you move to quarterly releases and suddenly have more defect reports than you can respond to before the next quarter's release. Slow down releases until you can handle the defect reports and still develop new functionalities.

Courage

Courage is effective action in the face of fear.

It's how they handle their fear that dictates whether they are working as an effective part of a team.

If you know what the problem is, do something about it. Sometimes courage manifests as patience. If you know there is a problem but you don't know what it is, it takes courage to wait for the real problem to emerge distinctly.

Doing something without regard for the consequences is not effective teamwork.

The courage to speak truths, pleasant or unpleasant, fosters communication and trust. The courage to discard failing solutions and seek new ones encourages simplicity. The courage to eek real, concrete answers creates feedback.

Respect

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.

For software development to simultaneously improve in humanity and productivity, the contributions of each person on the team need to be respected.

Values don't provide concrete advice about what to do in software development. Because of the distance between values and practices, we need a way to bridge the gap between them. Principles are the tool we need.

My Summary

Communication is key in software development. The sum of knowledge of all the people in a project is a great solution/problem catalog.

If the problem is about not having the knowledge, then you can either learn with people that had similar problems or avoid that it become a recurring problem. Other than that there is nothing you can do.

Simplicity as the opposite of complexity. Do only what you need to do. It is different from taking shortcuts.

Our plans will change, feedback avoid generating too much waste. It helps to do small corrections in the direction of the right goal.

When building a solution:

• You might not know what the right is. Or there might be several right solutions.
• Time changes business requirements, or even technical requirements.
• Requirements change too often, at a certain point that would invalidate a right solution even before it's done.

Feedback is opinions, the implementation, if the code is testable, if tests pass, the solution in production. We seek as much feedback as we can handle. The shorter the feedback cycle the better, as long we can handle it.

Courage can be either acting in the face of fear, or taking action to wait for a real problem to emerge. It shouldn't be reckless. It's power together with the other values.

Respect lies below the surface of the other values. Without respect there isn't a team.

Chapter 5. Principles

Humanity

This isn't good for business either, with the costs and disruption of high turnover and missed opportunities for creative action.

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

Limiting work hours allows time for these other human needs and enhances each person's contribution while he is with the team.

Part of the challenge of team software development is balancing the needs of the individuals with the needs of the team.

The magic of great teams is that after the team members develop trust they find that they are free to be more themselves as a result of their work together.

Economics

Make sure what you are doing has business value, meets business goals and serves business needs.

The time value of money says that a dollar today is worth more than a dollar tomorrow.

Incremental design explicitly defers design investment until the last responsible moment in an effort to spend money later. Pay-per-use provides a way of realizing revenue from features as soon as they are deployed.

Another source of economic value in software development is its value as options for the future.

Mutual Benefits

Mutual benefit is the most important XP principle and the most difficult to adhere to.

There are always solutions to any problem that cost one person while benefiting another.

Mutual benefit in XP is searching for practices that benefit me now, me later, and my customer as well.

Self-Similarity

Try coping the structure of one solution into a new context, even at different scales.

Just because you copy a structure that works in one context doesn't mean it will work in another. It is good place to start, though. Likewise, just because a solution is unique doesn't mean it's bad.

Improvement

In software development, "perfect" is verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, prefect your process, your design, and our stories.

"Best is the enemy of good enough" suggests that mediocrity is preferable to waiting.

The cycle is to do the best you can today, striving for the awareness and understanding necessary to do better tomorrow.

The history of software development technology shows us gradually eliminating wasted effort.

Find a starting place, get started, and improve from there.

Diversity

Teams need to bring together a variety of skills, attitudes, and perspectives to see problems and pitfalls, to think of multiple ways to solve problems, and to implement the solutions. Teams need diversity.

Conflict is the inevitable companion of diversity.

Two ideas about a design present an opportunity, not a problem.

Every team has conflict. The question is whether they resolve it productively. Respecting others and maintaining myself smooths communication in time of stress.

Diversity is expressed in the practice of Whole Team, where you bring together on the team people with a variety of skills and perspectives.

Reflection

Good teams don't just do their work, they think about how they are working and why they are working.

Reflection comes after action. Learning is action reflected. To maximize feedback, reflection in XP teams is mixed with doing.

Flow

Flow in software development is delivering a steady flow of valuable software by engaging in all the activities of development simultaneously.

Opportunity

To reach excellence, problems need to turn into opportunities for learning and improvement, not just survival.

Part of being extreme is consciously choosing to transform each problem into an opportunity: an opportunity for personal growth, deepening relationships, and improved software.

Redundancy

The cost of the redundancy is more than paid for by the savings from not having the disaster.

While redundancy can be wasteful, be careful not to remove redundancy that servers a valid purpose.

Failure

If you're having trouble succeeding, fail.

(about waste) No, not if it imparts knowledge. Knowledge is valuable and sometimes hard to come by. Failure may not be avoidable waste.

(About the team the thought too much) They only used the time a couple of time, but they kept it around as a reminder to fail instead of talk.

When you don't know what to do though, risking failure can be the shortest, surest road to success.

Quality

Sacrificing quality is not effective as a means of control. Quality is not a control variable. Projects don't go faster bu accepting lower quality. They don't go slower by demanding high quality. Pushing quality higher often results in faster delivery; while lowering quality standards often results in later, less predictable delivery.

Time and cost are most often fixed. XP chooses scope as the primary means of planning, tracking, and steering projects. Since scope is never known precisely in advance, it makes a good lever.

If you don't know a clean way to do a job that has to be done, do it the best way you can. If you know a clean way but it wold take too long, do the job as well as you have time for now.

This often occurs during architectural evolution, where you have to live with two architecture solving the same problem while you transition from one to the other.

Baby Steps

Under the right conditions, people and teams can take many small steps so rapidly that they appear to be leaping.

Accepted Responsibility

Responsibility cannot be assigned; it can only be accepted

Similarly, the person responsible for implementing a story ultimately responsible for the design, implementation, and testing of the story.

You will create new practices occasionally to fill you specific need.

My Summary

Humanity, contemporaneously might be called as Developer Experience. The companies or teams that don't have humanity will have a high turnover and it will impact business. A developer needs belonging and growth to be a improve as developer. The developer shouldn't sacrifice its career for the company or the team. It should be a balance.

Economics, is about knowing that your company has bills to pay. You should spend their money wisely and focus on the highest business value as soon as possible. Incremental design, deferring technical decision until the last moment in a effort to spend money latter and Pay-per-use realizing revenue as early as possible.

Mutual Benefits, seeks to find win win situations, where both the XP team and its customer will gain. Mutual benefits seeks for you and your customers benefits now and later.

Self-Similarity, is about applying patterns that you found in a context in similar problems at different scales. It's not because a solution is rare that is bad, neither because it's widely used that is good (though is a good starting place).

Improvement, is about doing the best you can everyday, and bringing improvements over time. There's always place to improve, perfect is a verb not a noun. Good enough is preferable instead of waiting.

Diversity, the more different attitudes, perspectives the easier to see pitfalls. Diversity also brings conflicts which is an opportunity to improvement.

Reflection, XP teams consider the how and the why they work that way. Reflection comes after action. The best way to learn is to start doing something.

Flow, is about a continuous delivering value to customers, we do that by starting all the activities to deliver software together. The more frequent or delivers more feedback, more improvements and better the flow. We must avoid doing something that is problematic only because it has a problem, it's actually the opposite, we need to fix the problem.

Opportunity, is about turning problems into learning and improvement. It's about the attitude you face your challenges.

Redundancy, is important to prevent disaster when the first solution fails. The cost of redundancy pays off from not having the disaster.

Failure, it's best to try and fail than stagnation. If failure imparts knowledge, then it is valuable. Avoid over thinking when you can try and get real feedback. Accept failure.

Quality, projects don't go faster when sacrificing quality. When projects have time and cost fixed, use scope as a control mechanism.

Baby Steps, smalls steps are less wasteful. Test-first, continuous integration, constantly going to production are examples of XP baby steps.

Accepted Responsibility, responsibility cannot be assigned only accepted. It's about building ownership.

Chapter 6. Practices

Unless given purpose by values, they become rote.

The practices are a vector from where you are to where you can be with XP.

I have divided the practices into two chapters: "Primary Practices," Chapter 7, and "Corollary Practices," Chapter 9. The primary practices are useful independent of what else you are doing. They each can give you immediate improvement. You can start safely with any of them. The corollary practices are likely to be difficult without first mastering the primary practices.

My Summary

Practices need to be together with values otherwise they are empty. Only applying the practices without the values is going to be meaningless.

Practices are the XP vector that display where you are.

There are two types of practices: Primary and Corollary. Both of them are important, but you should start with the primary, since they are more independent and can provide a immediate improvement boost.

Chapter 7. Primary Practices

Sit Together

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.

"Sit together" predicts that the more face time you have, the more humane and productive the project.

Whole Team

Include on the team people with all the skills and perspectives necessary for the project to succeed. This is really nothing more than the old idea of cross-functional team.

An issue that often arises is ideal team size. The Tipping Point by Malcolm Gladwell describes two discontinuities in team size: 12 and 150.

Some organizations try to have teams with fractional people: "You'll spend 40% of your time working for these customers and 6% work for those customers". In this case, so much time is wasted on task-switching that you can see immediate improvement by grouping the programmers into teams. The team responds to the customers' needs.

Informative Workspace

Make your workspace about your work. An interested observer should be able to walk into the team space and get a general idea of how the project is going in fifteen seconds.

Use your space for important, active information.

Energized Work

Work only as many hour as you can be productive and only as many hours you can sustain. Burning yourself out unproductively today and spoiling the next two days' work isn't good for you or the team.

Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.

Pair Programming

Write all production programs with two people sitting at one machine. Set up the machine so the partners can sit comfortably side-by-side. Move the keyboard and mouse back and forth so you are comfortable.

Pair programming is a dialog between two people simultaneously programming (and analyzing and designing and testing) and trying to program better.

If you need to work on an idea alone, go do it. Then come back and check with your team.

Stories

Plan using units of customer-visible functionality. "Handle five times the traffic with the same response time.", "Provide a two-click way for user to dial frequently used numbers.". As soon as a story is written, try to estimate the development effort necessary to implement it.

Early estimation is a key difference between stories an other requirements practices. Estimation gives the business and technical perspectives a chance to interact, which creates value early, when an idea has the most potential.

One feature of XP style planning is that stories are estimated very early in their life. This gets everyone thinking about how to get the greatest return from the smallest investment.

Weekly Cycle

Plan work a week at a time. Have a meeting at the beginning of every week.

Planning is a form of necessary waste. It doesn't create much value all by itself.

Quarterly Cycle

Plan work a quarter at a time. Once a quarter reflect on the team, the project, its progress, and its alignment with larger goals.

Slack

In any plan, include some minor tasks that can be dropped if you get behind. You can always add more stories later and deliver more than you promised. It's important in an atmosphere of distrust and broken promises to meet your commitments.

I suggested to the middle manager that he encourage his teams to only sign up for what they were confident they could actually do.

You can structure slack in many ways. One week in eight could be "Geek Week". Twenty percent of the weekly budget could go to programmer-chosen tasks.

Ten-Minute Build

A shorter build doesn't give you time to drink coffee.

Continuous Integration

Integrate and test changes after no more than a couple of hours.

Integrate and build a complete product.

Test-First Programming

Test-first programming addresses many problems at once:

• Scope-creep: It's easy to get carried away programming and put in code "just in case". By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding.
• Coupling and Cohesion: If it's hard to write a test, it's a signal that you have a design problem, not a testing problem. Loosely coupled, higly cohesive code is easy to test.
• Trust: It's hard to trust the author of code that doesn't work.
• Rhythm: It's easy to get lost for hours when you are coding. When programming test-first, it's clearer what to do next: either write another test or make the broken test work.

Incremental Design

When your understanding of the best possible design leaps forward, work gradually but persistently to bring the design back into alignment with your understanding.

XP teams work hard to create conditions under which the cost of changing the software doesn't rise catastrophically. The automated tests, the continual practice of improving the design , and the explicit social process all contribute to keep the cost of changes low.

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.

As a direction for improvement, incremental design doesn't say that designing in advance of experience is horrible. It says that design done close to when it is used is more efficient.

My Summary

Sit Together, the whole team should sit together. The longer the team stays together more productive it will become.

Whole Team, same as cross functional teams. Teams are composed by a set of different skills from different people.

Informative Workspace, use space to conveys information about the project.

Energized Work, work must be sustainable. Work too many hours don't improve productivity. Software development is an insight game, the more tired you are less insight you have.

Pair Programming, is a dialogue. Programming, testing and designing between two persons. You can for sure spend some alone, and then regroup with your pair.

Stories, instead of planning each layer of development, focus on the functionality for the customer. Stories are short and convey the customer need. Estimate it after you understand the scope.

Weekly Cycle, at beginning of the week you plan the whole week. Focus on what delivers more value to customers.

Quarterly Cycle, similar to the weekly cycle, but quarterly. It's important to have a more high level understanding where you are going. Otherwise, you could a tunnel vision of the week by week delivers.

Slack, tasks that you can drop to avoid breaking not delivering what you promised. Could also be time for the developers to choose their highest problem and fix it.

Ten-Minute Build, building your software must be fast enough so you don't have time to get a coffee. The faster the build, the faster the developer feedback loop.

Continuous Integration, integrate your code frequently with the main. Avoid big chunks of code.

Test-First Programming, addresses scope creep, coupling and cohesion, trust, rhythm. Start to develop the your stories by creating the test. Then develop it's functionality.

Incremental Design, try to do the design as close as you need it, so you have the most knowledge about the solution. You should pay constant attention to the costs of change. Tests helps to maintain it under control.

Chapter 8. Getting Started

XP works best when it is done all together, but you need a starting place.

How do you decide what to change first? Look at what you are doing and what you want to achieve. Choose the first practice on that path.

Change begins with awareness. Awareness of the need for change comes from feelings, instincts, facts or feedback from outsiders. Feelings, while valuable, need to be cross-checked with facts or trusted opinions.

Metrics can lead to awareness. Trends in metrics can point to the need for change for change before the consequence of the trend becomes painful.

Change always starts at home. The only person you can actually change is yourself. No matter how functional or dysfunctional your organization, you can begin applying XP for yourself.

If there is one message I would like to communicate, whatever your job title and however your work is touched by software development it is this: software development is capable of much, much more than it is currently delivering.

My Summary

The change always start with yourself, the developer. Once you want to change, try one practice at time. Try, fail, improve until you have master it. Then, go to next practice.

To start to change you have to be aware. Metrics can help with that. Either way be conscious about your choices.

Chapter 9. Corollary Practices

The practices in this chapter seem to me to be difficult or dangerous to implement before completing the preliminary work of the primary practices.

Real Customer Involvement

Make people whose lives and business are affected by your system part of the team.

The point of customer involvement is to reduce wasted effort by putting the people with the needs in direct contact with the people who can fill those needs.

Generally, the closer customer needs and development capabilities are, the more valuable development becomes.

When you act trustworthy and have nothing to hide, you are more productive.

Incremental Deployment

When replacing a legacy system, gradually take over its workload beginning very early in the project.

Team Continuity

Value in software is create not just by what people know and do but also by their relationship and what they accomplish together.

Shrinking Teams

As a team grows in capability, keep its workload constant but gradually reduce its size. This frees people to form more teams. When the team has too few members, merge it with another too-small team.

Root-Cause Analysis

Every time a defect is found after development, eliminate the defect and its cause. The goal is not just that this one defect won't ever recur, but that the team will ever make the same kind of mistake again.

Shared Code

Anyone on the team can improve any part of the system at any time. If something is wrong with the system and fixing it is not out of scope for what I'm doing right now, I should go ahead and fix it.

There are other models of teamwork besides "every man for himself". The team members can collectively assume responsibility not just for the quality of what they deliver to users but also for the pride they take in their work along the way.

Code and Tests

Customer pay for the what the system does today and what the team can make the system to tomorrow.

What are we going to do? What aren't we going to do? and How are we going to do what we do ? Bringing those decisions together so they can feed each other smooths the flow of value.

Single Code Base

There is only one code stream. You can develop in a temporary branch, but never let it live longer than a few hours.

Daily Deployment

Put new software into production every night. Any gap between what is on a programmer's desk and what is in production is a risk.

As long as you don't change the user's experience of the system, you can deploy all the rest of that work. On the last day you put the "keystone", the change to the user interface, in place.

Negotiated Scope Contract

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.

Pay-Per-Use

Connecting money flow directly to software development provides accurate, timely information with which to drive improvement.

Conclusion

They are, however, what my observations lead me to believe are the core of excellence for software development teams.

My Summary

Real customer involvement, bringing real customer closer to development eases to build the right product. It reduces the chances of building something no one will use. Be transparent with the customer. Don't push away the customer because you think your product will too specific, or because you think they won't trust you.

Incremental Deployment, instead of a big bang, gradually replace a legacy system.

Team Continuity, keep effective teams together. Software is created not only by what people do, but also because of their relationship and how well they know each other.

Shrinking Teams, the team should focus on reduce waste so that they can reduce the team's size to create another teams. If eventually the team reduced so many waste that is too little, you can also regroup it.

Root-Cause Analysis, eliminate the defects in its root. Not only the defect should happen again but the mistake that created the defect as well. Apply the 5 whys to find the root cause analysis?

Shared Code, everyone is owner of the code, you be able to contribute to any part of the system. The team is collectively responsible for the quality of the system.

Code and Tests, code and test are the only artifacts. Ceremonies and anything else is a form of waste.

Single Code Base, use only one mainline of code. Avoid split code based on different versions simultaneously.

Daily Deployment, the faster you put in production earlier you get feedback. Avoid big diffs of code, they are riskier, deploy are harder and you don't get feedback. You can deploy daily, and only in the last day you can change the switch that impacts the customer.

Negotiated Scope Contract, projects have fixed time, cost and quality. you negotiate its scope. Use it to shape the project to deliver the best value.

Pay-per-Use, it's a great model that benefits both user and provider. The features more used are the one that you get more out of it.

These techniques are better once you have mastered primary practices.

Chapter 10. The Whole XP Team

The XP practice Whole Team suggests that a variety of people work together in interlinking ways to make a project more effective. They have to work together as a group for each to be successful.

The principle of flow suggests that more value is created in a smooth, steady stream of software than in occasional large deployments.

There was no happy ending to this story. You can't be convinced against your will.

It didn't really matter who was first . What the whole team was missing was a sense that they were roped together.

Testers

Testers on an XP team help customers choose and write automated system-level tests in advance of implementation and coach programmers on testing techniques.

The role of testers shifts to early in development, helping define and specify what will constitute acceptable functioning of the system before the functionality as been implemented.

Interaction Designers

Addressing the concerns of eventual users is a priority for the team. The tools of interaction design, such as personas and goals, help the team analyze and make sense of the world of the user, although they are no substitute for conversation with real people.

Architects

Making big architectural changes in small, safe steps is one of the challenges for an XP team.

The principle of the alignment of authority and responsibility suggests that it is a bad idea to give one person the power to make decisions that others have to follow without having to personally live with the consequences.

Another task for architects on an XP team is partitioning systems. Partitioning isn't an up-front, once-and-for-all task, though. Rather than divide and conquer, an XP team conquers and divides.

Project Managers

To remain accurate, the information changes frequently; which gives project managers the challenge of communicating changes helpfully.

Planning in XP is an activity, not a phase. Project managers are responsible for keeping plans synchronized with reality.

To facilitate communication, they introduce the right person on the team to the right person outside the team as needed, rather than act as a communication bottleneck.

Product Manager

A plan in XP is an example of what could happen, not a prediction of what will happen.

Product managers encourage communication between customers and programmers, making sure the most important customer concerns are heard and acted on by the team.

Executives

Another job for executives sponsoring or overseeing XP teams is monitoring, encouraging and facilitating improvement.

Executives should expect honesty and clear explanations of options from the team in any decision-making process.

I trust two metrics to measure the health of XP teams. The first is the number of defects found after development. An XP team should have dramatically fewer defects in its first deployment and make rapid progress from there.

The second metric I use is the time lag between the beginning of investment in an idea and when the idea first generates revenue.

Part of the executive's job is presenting the team positively to the rest of the organization.

Technical Writers

Explaining the system in prose and pictures is an important link in the chain that creates feedback for the team.

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 users never look at a certain kind of documentation, stop writing it. You can find better ways to invest that time.

Human Resources

The problem with reviews is that most reviews and raises are based on individual goals and achievements, but XP focuses on team performance.

Hiring for XP teams can differ from existing hiring practices. XP teams put much more emphasis on teamwork and social skills. Given the choice between an extremely skilled loner and a competent-but-social programmer, XP teams consistently choose the more social candidate.

Roles

The goal is not for people to fill abstract roles, but for each team member to contribute all he can to the team.

My Summary

The whole team must collaborate and work together in order to achieve the better results. A whole team is composed by a set of people with different skills each.

Testers, act together with the customers to identify scenarios and the expected behavior. They also help the team to achieve better quality in software.

Interaction designers, identify gaps in the system and try to improve it. Applying techniques that map the customer to personas, this role acts together with customer.

The role of the architect is to drive the architecture of the system. The architect must not be a wizard in the top of its white tower taking decisions. It must for sure include the team in the process of evolving the system. Having one person responsible for all the decisions is a bad idea. Also, keep with small changes rather than big changes.

The project manager acts as a facilitator as well as a the responsible for communicating the progress of the project. It's important they are together with the team to synchronize the plans with the reality.

The product manager encourages the team to talk to the customers. The product manager does the priorization based on what will deliver more value in the current iteration. The items to be worked are created with focus on the business, so you have since first week of development working software.

Executive's job is to sponsor XP for the whole organization. The role helps in the decision making and monitors the organization through the number of defects and the time between concept to production.

Technical writers are responsible for documenting the system. The documentation cannot be expensive to create and maintain, and will be available as soon as the software is out. Just enough documentation.

HR focuses in hiring and the performance review. Hiring must focus on the social part and the performance review must consider the whole team, not individual performance.

There are other roles, these are some few to demonstrate what are the roles in a whole team. The important part is to each team identify which role are more required to achieve better results.

Chapter 11. The Theory of Constraints

XP isn't intended to solve marketing, sales or management problems. Its not that non-software bottlenecks aren't important, it's just that XP doesn't spread that thin.

Theory of constraints says that in any system there is one constraint at a time (occasionally two). To improve the 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.

How do you find the constraint in a system? Work piles up in front of the constraint.

Micro-optimizations is never enough. To improve our results we must look at the whole situation before deciding what to change.

XP uses a "pull" model. Stories are specified in detail immediately before they are implemented. The tests are pulled from the specification. The programming interface is designed to match the needs of the test. The code is written to match the tests and the interface. The design is refined to match the needs of the code as written.

The theory of constraints shares with other theories of organizational change the assumption that the whole organization is focused on overall throughput, not on micro-optimizations.

If the bottleneck exists outside of software development, the answer must come from outside of software development.

Executive sponsorship and strong relationships with people outside the team are crucial to applying XP, precisely because applying XP will shift the structure of work in the rest of the organization as soon as software development gets its act together. If you don't have executive sponsorship, be prepared to do a better job yourself without recognition or protection.

My Summary

Chapter 12. Planning: Managing Scope

Planning in XP starts with putting the current goals, assumptions, and facts on the table. With current, explicit information, you can work toward agreement about what's in scope, what's out of scope, and what to do next.

Planning is complicated because the estimates of the cost and value of stories are uncertain. The information on which you base these decisions changes.

Plans are not prediction of the future. At best, they express everything you know today about what might happen tomorrow. Their uncertainty doesn't negate their value.

I learned three variables by which to manage projects: speed, quality and price. The sponsor gets to fix two of these variables and the team gets to estimate the third. If the plan is unacceptable, the negotiating starts.

This model doesn't work well in practice. Time and costs are generally set outside the project. That leaves quality as the only variable you can manipulate. Lowering the quality of your work doesn't eliminate work, it just shifts it later so delays are not clearly your responsibility.

Planning is something we do together. It requires cooperation. Planning is an exercise in listening, speaking and aligning goals for a specific time period.

To estimate a story, imagine, given everything you know about similar stories, how many hours or days it will take a pair to complete the story. "Complete" means ready for deployment; including all the testing, implementation, refactoring, and discussions with the users.

Estimates based on experience are more accurate.

When things aren't going well is when we most need to adhere to our values and principles and modify our practices to remain as effective as possible. Inaccurate estimates are a failure of information, not of values or principles.

It is the interaction around the stories that makes them valuable. The cards are a tool.

My Summary

Chapter 13. Testing: Early, Often and Automated