Abstract

A thorough introduction to Xtreme Programming

Lessons

1 - What is XP

XP attempts to handle several of the sociological issues in software development. It does this by emphasizing relationships as much as the technical. It asks you to accept vulnerability through preparing for success and accepting responsibility for the consequences. You thereby leave yourself exposed but you have the knowledge that you did your best and you can thus feel good about yourself. It emphasizes a mentality of sufficiency: “How would you do it if you had enough time?”.

XP is a philosophy, a body of practices, a set of complimentary principles, and a community.

It’s characteristics include: short development cycles, incremental planning, flexible scheduling, automated testing, preference for oral communication, evolutionary design, close collaboration, and practices that work with the long-term and short-term interests of the project.

XP is lightweight, a methodology that isn’t rigid but flexible, works with teams of varying sizes, and seeks to adapt to uncertainty and change. It seeks to reconcile humanity and productivity: the more humanely I treat myself and others the more productive we’ll become.

Deadlines need not be a terror since it’s not our job to manage someone else’s expectations.

How XP addresses risk in the SDLC:

XP is:

2 - Learning to Drive

The paradigm for XP is: “Stay aware, adapt, and change.” It means maintaining situational awareness and correcting your actions based on the feedback from the awareness. Everything in software changes. Therefore most problems stem from our inability to cope with change and uncertainty.

In XP, the whole team drives the development process and, likewise, the customer drives the content.

3 - Values, Principles, and Practices

Practices

Are clear and objective things that you do everyday. They are a good place to start when working to develop values and principles.

Values

Values are the roots of things that we like and don’t like in a given situation. They are the large-scale criteria we use to judge what we see, think, and do. Without values, practices become rote. Bringing values together with practices means that we can perform a practice at effective times and for good reasons.

Values bring purpose to practices. Practices are the evidence of values. Practices are clear. What you really value is fuzzy.

Values bring purpose to practices, practices bring accountability to values.

Values and practices are an ocean apart. Values are universal while practices are intensely situated.

Principles

Principles bridge the gap between values and practices. They are domain-specific guidelines for life.

4 - Values

The difference between what we believe to be valuable and what is valuable is waste.

It ain’t what you don’t know that gets you in trouble. It’s what you know that ain’t so.
–Will Rogers

The biggest problem with people who “just know” is that they are focused on individual action. What actually matters is how individuals behave as part of a team and as part of an organization. The most important “style” issue is that the team chooses to work toward a common style. Individual freedom at all costs, doesn’t help the team succeed.

Communication

Communication is what matters most on software development teams. Sometimes problems are a result of a lack of knowledge rather than a lack of communication. Regardless, when surprises present themselves then communication can help to solve the problem.

Motion without communication is not progress.

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

Simplicity

Simplicity is the most intensely intellectual of the XP values. Ask the question: “what is the simplest thing that could probably work?”

Bias your thinking toward eliminating wasted complexity but that also means that the solution need not be too simple to work. Simplicity only makes sense in context. Achieving simplicity gives you that much less to communicate about.

Feedback

Planning and direction made in advance of experience have a short half-life. Change is inevitable and creates the need for constant feedback.

It would be better to do it the “right way” the first time except that:

Be satisfied with improvement rather than instant perfection. Use feedback to continually get closer to the goals.

Feedback forms:

Generate as much feedback as the team can handle but slow things down (such as deploys) if it becomes too much. A heuristic for this is if the team is ignoring important feedback.

Feedback is a crititcal part of communication that aids with simplicity. The simpler the system, the easier it is to get feedback about it.

Courage

Courage is effective action in the face of fear.

Can be manifested as a bias to action or patience. Courage is dangerous without counterbalancing values. When it is coupled with other values, it is powerful.

The courage to speak truths, pleasant or unpleasant, fosters communication and trust.

Respect

Every person whose life is touched by software development has equal value as a human being. No one is intrinsically worth more than anyone else. The contributions of everyone on the team need to be respected. “I am important and so are you”.

Others

These aren’t all of the values for software development. These are just the ones that are important to XP. Other important values include: safety, security, predictability, and quality-of-life. What is most important is aligning team behavior to team values.

5 - Principles

Humanity

Acting like software isn’t written by humans extracts a large toll on teams. People need the following to be a good developer: Basic Safety, Accomlishment, Belonging, growth, and intimacy. These don’t all need to be met in the work environment. Balance the needs of the individual with the needs of the team. Teams will find that they can be more themselves after developing trust.

Economics

What we work on as developers must meet business goals, has business value, and servers business needs. There’s a couple of measures of that: time value of money and option value of systems and teams. Incremental design defers design investment (time value of money) while keeping options open and flexible (option value of systems and teams) while not delving into speculative flexibility.

Mutual Benefit

Every activity should benefit all concerned. Unbalanced agreements tear down relationships that we need to value. We’re in a people business and maintaining working relationships is important. Extensive internal documentation is an example of a violation. You need to solve more problems than you create.

Self-similarity

Try copying the structure of one solution into a new context, even at different scales. The basic rhythm of software development is that you write a test that fails and then you make it work. The rhythm works at all different scales: quarter, week, hours, etc. Writing system tests before unit is beneficial. Just because a solution is unique doesn’t mean that it is bad or wrong.

Improvement

Best is the enemy of good enough. Do the best you can today but strive to do better tomorrow. Improve tech has lead to greater efficiencies but increased rigidity in organizations has lead to waste.

Diversity

You need many perspectives to proactively and effectively solve a problem. Opinions should be valued.

Reflection

Good teams think about what and why they are doing things. Reflection isn’t purely intellectual since it can come from the gut as well. It can be taken too far.

Flow

The practices of XP are biased towards a continuous flow of activities rather than discrete phases. Less feedback makes the problem worse leading to a tendency for even bigger chunks. Deploy smaller increments of value ever more frequently.

Opportunity

Survival leads to just enough problem solving to get by. Problems need to turn into opportunities for learning and improvement and not just survival.

Redundancy

Two is one and one is none. Try not to remove redundancy that serves a valid purpose.

Failure

If you’re having trouble succeeding, fail. Failure is not wasteful if it imparts knowledge. One tact is to limit design discussions to fifteen minutes and then go implement and fail to see how things work in practice. When you don’t know what to do , risking failure can be the shortest road to success.

Quality

Projects don’t go faster by accepting lower quality and vice versa. You can’t control projects by controlling quality. Time and cost are often fixed. XP chooses to use scope as the primary means of planning, tracking, and steering projects.

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. Architectural evolution.

Baby steps

Momentous change taken all at once is dangerous and unsettling to people. People and teamns can take small steps so rapidly that they appear to be sprinting.

Accepted responsibility

Authority and responsibility go hand in hand and must be accepted by the person.

6 - Practices

Practices are not meaningful without attendant values to drive them. Practices are situation dependent and are a choice as to when to implement them. Experiment with the primary practices and add new ones to see which ones work and which ones don’t.

7 - Primary Practices

Sit Together

Develop in an open space big enough for the whole team. Increase the level of interactions. No matter what people say is the problem, the problem is always a people (sociological) problem.

Teams can be distributed and do XP but more facetime is always better.

Whole Team

People need a sense of “team” meaning that: * we belong * we’re in this together * we support each others’ work, growth, and learning

The tipping points for the number of people who can comfortably interact and trust each other in a group is 12 and 150. Fractional people are less effective.

Informative Workspace

Make your workspace about your work: important and active information. Also needs to provide for other human needs.

Energized Work

Burning yourself out is unproductive in the long term and can be counter-productive in the short-term. Work only as many hours as you can be productive and only as many hours as you can sustain.

Turning to long work hours is a means of grabbing control. When sick, rest up and get well.

Stay at work the same amount of time but manage that time better.

Pair Programming

Write all production programs with two people. Pair programming includes keeping each other on task, brainstorming refinements, clarifying ideas, taking initiative when their partner is stuck, and holding each other accountable.

Doesn’t mean that you can’t think alone. Pairing means both companionship and privacy. You can prototype alone and still pair but bring the resulting idea and not the code.

It is tiring. Rotate pairs frequently. Respect personal space and personal differences. If unfortable pairing with someone, talk about it with someone safe.

Stories

Are units of customer-visible functionality. Estimate the development effort early which gets eveyone thinking about how to get the greatest return from the smallest investment. Requirements aren’t always true requirements.

Weekly Cycle

A weekly meeting at the start of the week to review progress, have the customer select stories to complete, and break the stories into tasks.

Start the week by running automated unit tests and spend the rest of the week completing the stories.

If things aren’t being completed, work on improving estimates and or interruptions. Planning is a form of necessary waste that should get better over time.

Individuals should take time for estimates and completion. Ownership of tasks goes a long way to satisfying the human need for ownership.

Quarterly Cycle

Use quarterly planning to:

Separation of themes from stories.

Slack

Habitual overcommitment causes a number of issues including increasing defefct loads, bad morale, bad relationships. Consider using 20% time to improve and develop skills.

Ten-minute Build

Continuous Integration

Integrate every couple of hours or after each pair programming episode.

Test-First Programming

Testing helps with scope creep by stating explicitly what the program is supposed to do. It also helps with coupling. And last, it helps with trust and rhythm (easier to know what to do next). Consider continuous testing.

Incremental Design

Big design upfront came from Barry Boehm study in 1960s of defense contractors.

XP strives to keep the cost of changing software from rising catastrophically. Without daily attention to design, the cost of changes skyrockets.

Keep design investment in proportion to the needs of the system thus far. The question is when to design and the most effective time is when experience has been gained. Where is most often answered by eliminating duplication.

8 - Getting Started

There is no one right place for people to start. Start by changing one thing at a time. Change doesn’t have to be slow but new habits do take time to solidify. Change begins with awareness but metrics can lead to awareness. The primary practices are on a continuum of behaviour. Change always starts at home.

Dictating practices destroys trust and creates resentment. Encourage responsibility and accountability instead. Raise your expectations for those to elicit change. Help your team through the anxiety that comes with change.

Mapping Practices Exercise

No right answers. Discussion should be centered around what is attached to the practice is one valuable side effect of the exercise. Once you have potential changes to make, make some of them.

9 - Corollary Practices

Real Customer Involvement