Embrance Change, Second Edition
By Kent Beck.
- It's about social change.
- Don't protect yourself from success by holding back. Do your best and then deal with the consequences.
- It's a style of software development focusing on excellent application of programming techniques, clear communication, and teamwork.
- It's a path of improvement to excellence for people coming together to develop software. It is distinguished by:
- Its short development cycles.
- Its incremental planning approach.
- Its ability to flexibly when the business needs change.
- Its reliance on automated tests.
- Its reliance on oral communication.
- Its reliance on an evolutionary design process.
- Its reliance on the close collaboration.
- Its reliance on practices that work with both the short-term instincts of the team members and the long-term interests of the project.
- XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.
- In XP you only do what you need to do to create value for the customer.
- The values and principles behind XP are applicable at any scale.
- It's a methodology based on addressing constraints in software development.
- XP demands that participants learn a high level of technique in service of the team's goals.
- The risks in the development process:
- Schedule slips.
- It calls for short release cycles, 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. XP calls for implementing the highest priority features first, so any features that slip past the release will be of lower value.
- Project canceled.
- It asks the business-oriented part of the team to choose the smallest release that makes the most business sense, so there is less to go wrong before deploying and the value of the software is greatest.
- System goes sour.
- It creates and maintains a comprehensive suite of automated tests, which are run and rerun after every change to ensure a quality baseline. XP always keeps the system in deployable condition. Problems are not allowed to accumulate.
- Defect rate.
- It tests from the perspective of both programmers writing tests function-by-function and customers writing tests program-feature-by-program-feature.
- Business misunderstood.
- The specification of the project is continuously refined during development, so learning by the customer and the team can be reflected in the software.
- Business changes.
- It shortens the release cycle, so there is less change during the development of a single release. During a release, the customer is welcome to substitute new functionality for functionality not yet completed. The team doesn't even notice if it is working on newly discovered functionality or features defined years ago.
- False feature rich.
- 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. XP also encourages human contact among the team, reducing the loneliness that is often at the heart of job dissatisfaction. New team members are encouraged to gradually accept more and more responsibility.
- Schedule slips.
- XP paradigm: Stay aware. Adapt. Change.
- The problem isn't the change, because change is going to happen; the problem, rather, is our inability to cope with change.
- 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.
- Values are the roots of the things we like and don't like in a situation.
- Values bring purpose to practices.
- Values are universal.
- Practices are evidence of values.
- Practices bring accountability to values.
- Practices are intensely situated.
- Principles are domain-specific guidelines for life.
- First you have to garden, then join the community of gardeners, then teach others to garden. Then you are a gardener.
- 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.
- When you encounter a problem, ask yourselves if the problem was caused by a lack of communication.
- What communication do you need now to address the problem?
- What communication do you need to keep yourself out of this trouble in the future?
- When you need to change to regain simplicity, you must find a way from where you are to where you want to be.
- Improving communication helps achieve simplicity by eliminating unneeded or deferrable requirements from today's concerns.
- Achieving simplicity gives you that much less to communicate about.
- Change is inevitable, but change creates the need for feedback.
- Feedback comes in many forms:
- Opinions about an idea, yours or your teammates'.
- How the code looks when you implement the idea.
- Whether the tests were easy to write.
- Whether the tests run.
- How the idea works once it has been deployed.
- XP teams strive to generate as much feedback as they can handle as quickly as possible.
- 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 seek real, concrete answers creates 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.
- 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 value of money: a dollar today is worth more than a dollar tomorrow.
- Software development is more valuable when it earns money sooner and spends money later.
- If I can redeploy my media scheduling program for a variety of scheduling-related tasks, it is much more valuable than if it can only be used for its originally intended purpose.
- It's about searching for practices that benefit me now, me later, and my customer as well.
- Extensive internal documentation of software is an example of a practice that violates mutual benefit. I am supposed to slow down my development considerably so some unknown person in a potential future will have an easier time maintaining this code. I can see a possible benefit to the future person should the documentation still happen to be valid, but no benefit now.
- XP solves like this:
- I write automated tests that help me design and implement better today. I leave these tests for future programmers to use as well.
- I carefully refactor to remove accidental complexity, giving me both satisfaction and fewer defects and making the code easier to understand for those who encounter it later.
- I choose names from a coherent and explicit set of metaphors which speeds my development and makes the code clearer to new programmers.
- Just because you copy a structure that works in one context doesn't mean it will work in another.
- Having the system-level tests before you begin implementation simplifies design, reduces stress, and improves feedback.
- To do the best you can today, striving for the awareness and understanding necessary to do better tomorrow.
- It doesn't mean waiting for perfection in order to begin.
- The history of software development technology shows us gradually eliminating wasted effort.
- Teams where everyone is alike, while comfortable, are not effective.
- 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.
- Two ideas about a design present an opportunity, not a problem.
- Good teams don't just do their work, they think about how they are working and why they are working.
- They don't try to hide their mistakes, but expose them and learn from them.
- Reflection moments:
- Official: do pair programming and continuous integration.
- Non-official: conversation with a spouse or friend, vacation, non-software-related reading and activities, shared meals and coffee breaks.
- Reflection comes after action.
- Learning is action reflected.
- To maximize feedback, reflection in XP teams is mixed with doing.
- It's delivering a steady flow of valuable software by engaging in all the activities of development simultaneously.
- It 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.
- Turning problems into opportunities takes place across the development process.
- It maximizes strengths and minimizes weaknesses.
- Defects corrode trust and trust is the great waste eliminator.
- Defects are a critical, difficult problem.
- Defects are addressed in XP by many of the practices:
- pair programming
- continuous integration
- sitting together
- real customer involvement
- daily deployment
- Failure is not a waste if it imparts knowledge.
- Knowledge is valuable and sometimes hard to come by.
- Failure may not be avoidable waste.
- Projects don't go faster by accepting lower quality.
- Pushing quality higher often results in faster delivery.
- Quality isn't a purely economic factor. People need to do work they are proud of.
- A concern for quality is no excuse for inaction.
- 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 would take too long, do the job as well as you have time for now. Resolve to finish doing it the clean way later.
- You have to live with two architectures solving the same problem while you transition from one to the other.
- Then the transition itself becomes a demonstration of quality: making a big change efficiently in small, safe steps.
- It's always tempting to make big changes in big steps.
- Baby steps acknowledge that the overhead of small steps is much less than when a team wastefully recoils from aborted big changes.
- Responsibility cannot be assigned, it can only be accepted.
- If someone tries to give you responsibility, only you can decide if you are responsible or if you aren't.
- With responsibility comes authority.
- When a process expert can tell me how to work, but doesn't share in that work or its consequences, authority and responsibility are misaligned.
- Use principles to understand the practices better and to improvise complementary practices when you don't find one that suits your purpose.
- The principles give you a better idea of what the practice is intended to accomplish.
- They are kind of things you'll see XP teams doing day-to-day.
- If the situation changes, you choose different practices to meet those conditions.
- Your values do not have to change in order to adapt to a new situation.
- Some new principles may be called when you change domains.
- They are a vector from where you are to where you can be with XP.
- No matter what the client says the problem is, it is always a people problem. Technical fixes alone are not enough.
- How important it is to sit together, to communicate with all our senses.
- Tearing down the cubicle walls before the team is ready is counterproductive.
- A team that knows that physical proximity enhances communication and that has learned the value of communication will open up their own space, given the chance.
- Include on the team people with all the skills and perspectives necessary for the project to succeed. - Cross-functional teams.
- People need a sense of team:
- We belong.
- We are in this together.
- We support each others' work, growth, and learning.
- What constitutes a “whole team” is dynamic.
- If a set of skills or attitudes becomes important, bring a person with these skills on the team.
- If someone is no longer necessary, he can go elsewhere.
- Make your workspace about your work.
- Walk into the team space and get a general idea of how the project is going in 15 seconds.
- Work only as many hours as you can be productive and only as many hours as you can sustain.
- It's easy to remove value from a software project; but when you're tired, it's hard to recognize that you're removing value.
- When you're sick, respect yourself and the rest of your team by resting and getting well. Taking care of yourself is the quickest way back to energized work.
- You can make incremental improvements in work hours.
- Declare a two-hour stretch each day as Code Time. Turn off the phones and email notification, and just program for two hours.
- It's a dialog between two people simultaneously programming (and analyzing and designing and testing) and trying to program better.
- Keep each other on task.
- Brainstorm refinements to the system.
- Clarify ideas.
- Take initiative when their partner is stuck, thus lowering frustration.
- Hold each other accountable to the team's practices.
- Pair programming is tiring but satisfying.
- Rotate pairs can be a good idea, switching at natural breaks in development.
- Different individuals and cultures are comfortable with different amounts of body space.
- Personal hygiene and health are important issues when pairing.
- Ideally, emotions at work will be about work.
- It is important to respect individual differences when pairing.
- If you aren't comfortable, the team isn't doing as well as it could.
- As soon as a story is written, try to estimate the development effort necessary to implement it.
- Stories are estimated very early in their life.
- Get the greatest return from the smallest investment.
- You can't make a good decision based on image alone.
- You need to know your constraints, both cost and intended use.
- The nice thing about a week as opposed to two or three is that everyone is focused on Friday.
- The team's job—programmers, testers, and customers together—is to write the tests and then get them to run in five days.
- If you get to Wednesday and it is clear that all the tests won't be running, that the stories won't be completed and ready to deploy, you still have time to choose the most valuable stories and complete them.
- Planning is a form of necessary waste.
- Using a quarter as a planning horizon synchronizes nicely with other business activities that occur quarterly.
- They're comfortable for interaction with external suppliers and customers.
- They're good for team reflection, finding gnawing-but-unconscious bottlenecks.
- You may have to begin slack with yourself, telling yourself how long you actually think a task will take and giving yourself time to do it, even if the rest of the organization is not ready for honest and clear communication.
- Automatically build the whole system and run all of the tests in ten minutes.
- A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback.
- Team programming is a divide, conquer, and integrate problem.
- The integration step is unpredictable, but can easily take more time than the original programming.
- The longer you wait to integrate, the more it costs and the more unpredictable the cost becomes.
- Continuous integration should be complete enough that the eventual first deployment of the system is no big deal.
- It addresses many problems.
- Scope creep: if you really want to put that other code in, write another test after you've made this one work.
- 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, highly cohesive code is easy to test.
- Trust: writing clean code that works and demonstrating your intentions with automated tests, you give your teammates a reason to trust you.
- Rhythm: it's clearer what to do next: either write another test or make the broken test work. Code, refactor, test, code, refactor.
- Continuous testing reduces the time to fix errors by reducing the time to discover them.
- It says that design done close to when it is used is more efficient.
- Refactoring is a discipline of design that codifies these recurring patterns of changes.
- They can occur at any level of scale.
- Few design decisions are difficult to change once made.
- The result is systems that can start small and grow as needed without exorbitant cost.
- They provide a foundation of respect, communication, and feedback that fosters simplicity and courage.
- The team members can use their increasing confidence and competence to build relationships inside and outside the team.
- One option is to use XP-style planning.
- Write stories about improving your software development process.
- Automate the build, Test first all day, Pair program with Joe for two hours.
- Estimate how long each will take.
- Figure out your budget for process improvement.
- Pick a story to work on first.
- Adapt as you discover what is easy or valuable and what is difficult.
- Write stories about improving your software development process.
- Change always starts at home.
- Programmers can start writing tests first.
- Testers can automate their tests.
- Customers can write stories and set clear priorities.
- Executives can expect transparency.
- An exercise for discovering what each practice means for you and your team.
- In the middle is the practice.
- Directly below that is the purpose of the practice as I see it: to keep my work and my life in balance.
- Attached to the practice are factors that affect it and, in this case, symptoms that the practice isn't going well.
- Map whatever issues come to mind when you think about a practice.
- SW development is capable of much more than it is currently delivering.
- Defects should be notable because they are rare.
- Major scope adjustments because of lack of progress should only need to occur in the first half of schedules.
- Initial deployment of software should come after a small percentage of the project budget is spent.
- Teams should be able to grow and shrink without catastrophic consequences.
- 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.
- When you are ready with accurate estimates and low defect rates, including customers in the development process fosters trust and encourages continued improvement.
- Big deployments have a high risk and high human and economic costs.
- Find a little piece of functionality or a limited data set you can handle right away. Deploy it.
- You'll have to find a way to run both programs in parallel, splitting and merging files or training some users to use both programs.
- This scaffolding, technical or social, is the price you pay for insurance.
- 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.
- Toyota Production System:
- 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.
- Figure out how many stories the customer needs each week.
- Strive to improve development until some of the team members are idle.
- Then you're ready to shrink the team and continue.
- Write an automated system-level test that demonstrates the defect, including the desired behavior. This can be done by the customer, by customer support, or by developers.
- Write a unit test with the smallest possible scope that also reproduces the defect.
- Fix the system so the unit test works. This should cause the system test to pass also. If not, return to the previous point.
- Once the defect is resolved, figure out why the defect was created and wasn't caught. Initiate the necessary changes to prevent this kind of defect in the future.
- 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.
- Until the team has developed a sense of collective responsibility, no one is responsible and quality will deteriorate.
- People will make changes without regard for the team-wide consequences.
- Some techniques like pair programming and continuous integration are interesting to try to avoid selfish conducts.
- Maintain only the code and the tests as permanent artifacts.
- Generate other documents from the code and tests.
- Rely on social mechanisms to keep alive important history of the project.
- The valuable decisions in software development are:
- What are we going to do?
- What aren't we going to do?
- How are we going to do what we do?
- Multiple code streams are an enormous source of waste in software development.
- 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.
- 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.
- A programmer out of sync with the deployed software risks making decisions without getting accurate feedback about those decisions.
- There are technical, psychological or social and business-related barriers.
- Working to remove it and then letting more frequent deployment come as a natural consequence will help you improve development.
- Reduce risk by signing a sequence of short contracts instead of one long one.
- They're a mechanism for aligning the interests of suppliers and customers to encourage communication and feedback.
- They give everyone the courage to do what looks right today, not do something ineffective just because it is in the contract.
- Money is the ultimate feedback.
- Connecting money flow directly to software development provides accurate, timely information with which to drive improvement.
- If you can't implement pay-per-use, you might be able to go to a subscription model.
- The primary and corollary practices are the core of excellence for software development teams.
- Much of the responsibility for catching trivial mistakes is accepted by the programmers.
- Test-first programming results in a suite of tests that help keep the project stable.
- The role of testers is to help defining and specifying what will constitute acceptable functioning of the system before the functionality has been implemented.
- They choose overall metaphors for the system, write stories, and evaluate usage of the deployed system to find opportunities for new stories.
- THey look for and execute large-scale refactorings, write system-level tests that stress the architecture, and implement stories.
- Making big architectural changes in small, safe steps is one of the challenges for an XP team.
- They help choose the most appropriate fracture lines and then follow the system as a whole.
- They keep the big picture in mind as the groups focus on their smaller section.
- They facilitate communication inside the team and coordinate communication with customers, suppliers, and the rest of the organization.
- They are responsible for keeping plans synchronized with reality.
- They facilitate communication within the team, increasing cohesiveness and confidence.
- They help the team decide priorities by analyzing the differences between actual and assumed requirements.
- They adapt the story and theme to what is really happening now.
- Stories should be sequenced for business, not technical, reasons.
- The goal is a working system from the first week.
- They encourage communication between customers and programmers, making sure the most important customer concerns are heard and acted on by the team.
- They provide an XP team with courage, confidence, and accountability.
- They articulate and maintain large-scale goals.
- They have a right to see not just good software coming from the team, but continuing improvement as well.
- They are free to ask for explanations about any aspect that makes sense.
- Two metrics to measure the health of XP teams:
- Number of defects found after development. Each is an opportunity for the team to learn and improve.
- The time lag between the beginning of investment in an idea and when the idea first generates revenue.
- They provide early feedback about features and to create closer relationships with users.
- They create closer relationships with users.
- They help them learn about the product, listening to their feedback, and addressing confusion with further publications or new stories.
- They help write and pick stories and make domain decisions during development.
- They estimate stories and tasks, break stories into tasks, write tests, write code to implement features, automate tedious development process, and gradually improve the design of the system.
- They need to develop good social and relationship skills.
- Two challenges:
- Reviews.
- Hiring.
- Valuable employees in XP:
- Act respecful.
- Play well with others.
- Take initiative.
- Deliver on their commitments.
- XP teams put much more emphasis on teamwork and social skills.
- The best interviewing technique is to have the candidate work with the team for a day.
- Pair programming provides an excellent test of technical and social skills.
- The goal is to have everyone contribute the best he has to offer to the team's success.
- As the team matures, keep in mind the alignment of authority and responsibility.
- Everyone on the team can recommend changes, but they should be prepared to back up their concerns with action.
- In any system there is one constraint at a time.
- To improve overall system throughput you have to:
- Find the constraint.
- Make sure it is working full speed.
- Find ways of either increasing the capacity of the constraint, offloading some of the work onto non-constraints, or eliminating the constraint entirely.
- The Theory of Constraints says there is always a constraint.
- When we eliminate one constraint we create another.
- Micro-optimization is never enough.
- To improve our results we must look at the whole situation before deciding what to change.
- Software development is a human process not a factory.
- It 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.
- Lowering the quality can create the illusion of progress this way, but you pay in reduced satisfaction and damaged relationships.
- There is a limit to how much work can be done in a day.
- More time at the desk does not equal increased productivity for creative work.
- It's open and accessible, that reflects the kind of relationships that make for the most valuable software development.
- Defects destroy the trust required for effective software development.
- Without trust, people spend much of their time defending themselves against the possibility that someone else may have made a mistake.
- Defects are expensive when they occur.
- The direct costs of fixing the defects.
- The indirect costs because of damaged relationships, lost business, and lost development time.
- Acceptable level is to reduce the occurrence of defects to an economically sustainable level.
- Software testing is double-checking.
- You say what you want a computation to do once when you write a test.
- You say it quite differently when you implement the computation.
- If the two expressions of the computation match, the code and the tests are in harmony and likely to be correct.
- Beta testing is a symptom of weak testing practices and poor communication with customers.
- If you can generate value without feedback, designing sooner makes more sense.
- If experience creates most of the value, designing just enough today to get going and then designing mostly in the light of experience makes more sense.
- The shift to XP-style design is a shift in the timing of design decisions.
- Design is deferred until it can be made in the light of experience and the decisions can be used immediately.
- Deploy software sooner.
- Make decisions with certainty.
- Avoid living with bad decisions.
- Maintain the pace of development as the original design assumptions are superseded.
- Appropriate for the intended audience: it doesn't matter how brilliant and elegant a piece of design is; if the people who need to work with it don't understand it, it isn't simple for them.
- Communicative: every idea that needs to be communicated is represented in the system. Like words in a vocabulary, the elements of the system communicate to future readers.
- Factored: duplication of logic or structure makes code hard to understand and modify.
- Minimal: within the above three constraints, the system should have the fewest elements possible. Fewer elements means less to test, document, and communicate.
- Conquer-and-divide strategy instead of a divide-and-conquer:
- First solve a small part of the problem with a small team.
- Divide the system along its natural fracture lines and begin working on it with a few teams.
- Partitioning introduces the risk that the pieces won't fit on integration, so integrate frequently to reconcile differing assumptions between teams.
- There is interesting work to be done outside the scope of XP in rethinking a mutually beneficial relationship between accounting and software development.
- The project manager presents the information in a form the organization can absorb.
- The story cards on the wall are still “the truth”.
- Anyone who wants to learn to read them is welcome to come in, look at them, and ask questions.
- The project manager makes sure that the organization's expectations are met.
- It can be differente inside the XP team and inside other teams.
- Respect the others in the organization.
- Don't push your newfound knowledge and power on others for your own benefit.
- Projects that start and stop frequently, with the team scattered at each shutdown, are more difficult to maintain over time.
- Rosseta Stone:
- This brief guide to future maintainers tells how to run the build-and-test process and points to interesting starting places from which to learn the system.
- The tests included in the build prevent maintainers from falling into pits while they learn their way around the system.
- XP is suited to projects requiring the close cooperation of specialists.
- Getting everyone to work in concert while learning a bit about each others' specialities.
- Chip away at the complexity while continuing to deliver.
- One objection is that this “extra” cleanup takes too long.
- The team is likely wasting time on interruptions to fix defects.
- Cleaning up helps reduce the overhead of work.
- Visible planning can make it easier for every one to see where the time is already going.
- It is easier to accept the estimates necessary to do the job right.
- A system isn't certifiably secure unless it has been built with a set of security principles in mind and has been audited by a security expert.
- These practices have to be incorporated into the team's daily work.
- The basic values and principles apply at all scales.
- The practices can be modified to suit your situation.
(It's just an interview.)
(It's a personal tale about Kent Beck's beginnings with XP.)
- Things usually go according to plan.
- Micro-optimization leads to macro-optimization.
- People are mostly interchangeable and need to be told what to do.
- We have unconsciously inherited this social structure and it is bizarrely unsuited to software development.
- The first step of social engineering in Taylorism is the separation of planning from execution.
- The second step of Taylorist social engineering is the creation of a separate quality department.
- 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.
- Documentation no one reads until it is irrelevant or misleading.
- TPS has strong parallels to software development.
- Cross-training workers.
- Organizing the factory into cells.
- Writing gain-sharing contracts between customers and suppliers.
- The way to begin organizational change is still to start with yourself.
- It is the one change you have control over.
- First develop your skills, then put them into service.
- Leading by example is a powerful form of leadership.
- Conditions that facilitate sudden turnarounds are:
- Aligned values: The team and organization are willing to accept and work with the XP values.
- Pain: Clear memory of recent pain makes people more willing to try dramatic changes.
- He should be aligned enough with your existing values to be effective, but firm enough in the XP values to keep leading in that direction.
- He should have enough technical skill to teach what people can't easily learn on their own.
- He should encourage independence, not dependence.
- A good one moves on a little before you think you're ready and leaves behind a team that finds itself firmly on a path to sustainable, profitable, stable, fast, fun software development.
- If an organization's actual values are secrecy, isolation, complexity, timidity, and disrespect; suddenly expressing the opposite values through a new set of practices will cause trouble rather than create improvement.
- It's worse to fail with an XP team than to succeed with a pure waterfall team.
- The goal is successful and satisfying relationships and projects, not membership in the XP Club.
- Your team is extreme sets other people's expectations for your style of communication, your development practices, and the speed and quality of your results.
- Software development could stay on its current path of creeping increments. Without dramatic improvement, though, the global market for software will stagnate as more attractive investments are found in manufacturing and biotechnology.
- The expanding market will more than make up for losses in any one location because of increased efficiency and multi-site development.
- Tools and techniques change often, but they don't change a lot.
- People, however, change slowly but deeply.
- The challenge of XP is
- to encourage deep change,
- to renew individual values and mutual relationships
- to give software a seat at the table for the next fifty years.
- Participate in communities, local and global.
- Look for communities that encourage you to be your best self.
- If you can't find such a community, start one yourself.
- As a community we can accomplish more than we ever could in isolation.
- There is no improvement without first improving myself.
- XP is a way of thinking about and acting on your ideals.