A thorough introduction to Xtreme Programming
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:
- Schedule slips: short release cycles decrease the amount of possible slippage and provide a fast feedback loop.
- Project cancelled is handled by the MVP philosophy.
- System goes sour is handled by an extensive suite of tests
- Defect rate is decreased through feature and spec level tests
- Business misunderstood: business people are first class members of the team.
- Business changes are handled by shortening the release cycle and thus decreasing the impact of each change
- False feature rich is handled though prioritization of tasks.
- Staff turnover is handled by having developers accept responsibility for estimating, producing, etc of their work which gives them control over their destiny. New team members are gradually asked to accept more responsibility.
- letting go of the familiar for the effective
- evaulating yourself based on effort and contribution to team goals
- continuous improvement
- meeting sociological needs while developing software.
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
Are clear and objective things that you do everyday. They are a good place to start when working to develop values and principles.
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 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.
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 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 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.
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:
- We may not know how to do it “right”
- What’s right today might be wrong tomorrow
- Doing everything “right” might take so long that it becomes unnecessary before its even used.
Be satisfied with improvement rather than instant perfection. Use feedback to continually get closer to the goals.
- How easily the code reads
- How easy the tests are to write
- Do the tests pass?
- How it works once deployed
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 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.
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”.
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
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.
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.
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.
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.
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.
You need many perspectives to proactively and effectively solve a problem. Opinions should be valued.
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.
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.
Survival leads to just enough problem solving to get by. Problems need to turn into opportunities for learning and improvement and not just survival.
Two is one and one is none. Try not to remove redundancy that serves a valid purpose.
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.
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.
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.
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
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.
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.
Make your workspace about your work: important and active information. Also needs to provide for other human needs.
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.
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.
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.
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.
Use quarterly planning to:
- Identify bottlenecks
- start repairs
- Plan the themes for the quarter (collections of stories)
- Pick a quarter’s worth of stories to fulfill those themes
- Focus on the big picture
Separation of themes from stories.
Habitual overcommitment causes a number of issues including increasing defefct loads, bad morale, bad relationships. Consider using 20% time to improve and develop skills.
Integrate every couple of hours or after each pair programming episode.
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.
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.