Activities

• Coding
• Testing
• Listening
• Designing

Artifacts

• Acceptance tests
• Code
• Iteration plan
• Release and iteration plans
• Stories
• Story cards
• Statistics about the number of tests, stories per iteration, etc.
• Unit tests
• Working code every iteration

12 Practices

Here’s the 12 XP practices:

• Coding Standards
• Collective Ownership
• Continuous Integration
• On-Site Customer
• Pair Programming
• Planning Game
• Refactoring
• Short Releases
• Simple Design
• Sustainable Pace
• System Metaphor
• Test-Driven Development

For a visual of the XP practices, see a picture of the Practices and Main Cycles of XP.

5 Values (Extreme Programming Explained)

• Communication
• Courage
• Feedback
• Respect
• Simplicity

Phases

The following are phases of an XP project life cycle.

• Exploration Phase
• Planning Phase
• Iteration to Release Phase
• Productionizing Phase
• Maintenance Phase

For a visual overview, see Agile Modeling Throughout the XP Lifecycle.

12 Principles (Agile Manifesto)

These are the 12 Agile principles according to the  Agile Manifesto:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development.   The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

4 Values (Agile Manifesto)

These are the four Agile values according to the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Additional Resources

• Using an Agile Software Process with Offshore Development (Martin Fowler)
• Extreme Programming (Ward Cunningham’s Wiki)
• XProgramming.com (Ron Jeffries)
• Agile Manifesto
• Extreme Programming (Wikipedia)
• Practices and Main Cycles of XP (Ron Jeffries)
• Extreme Programming Core Practices (Ward Cunningham’s Wiki)

My Related Posts

• MSF Agile at a Glance
• Rational Unified Process (RUP) at a Glance
• Microsoft Solution Framework (MSF) at a Glance

Artifacts

Envisioning

• Vision/scope document.
• Risk assessment document.
• Project structure document.

Planning

• Functional specification
• Risk management plan
• Master project plan
• Master project schedule

Developing

• Prototype
• Source code
• Executables
• Installation scripts and configuration settings for deployment
• Frozen functional specification
• Performance support elements
• Test specifications
• Test cases

Stabilizing

• Golden release
• Release notes
• Performance support elements
• Test results and testing tools
• Source code and executables
• Project documents
• Milestone review

Deploying

• Operation and support information systems
• Procedures and processes
• Knowledge base, reports, logbooks
• Documentation repository for all versions of documents, load sets, and code developed during the project
• Project close-out report
• Final versions of all project documents
• Customer/user satisfaction data
• Definition of next steps

Additional Resources

• Microsoft Solutions Framework (TechNet)

My Related Posts

• MSF at a Glance
• Rational Unified Process (RUP) at a Glance

Principles

• Partner with customers
• Foster open communications
• Work toward a shared vision
• Quality is everyone’s job every day
• Stay agile, adapt to change
• Make deployment a habit
• Flow of value

Mindsets

• Quality Is Defined By Customer
• Pride of Workmanship
• Team of Peers
• Frequent Delivery
• Willingness to Learn
• Get Specific Early
• Qualities of Service
• Citizenship

Workstreams

• Capture Project Vision
• Create a Quality of Service Requirement
• Create a Scenario
• Guide Project
• Plan an Iteration
  Guide Iteration
• Create a Solution Architecture
• Build a Product
• Fix a Bug
• Implement a Development Task
• Close a Bug
• Test a Quality of Service Requirement
• Test a Scenario
• Release a Product

Activities By Workstream

Capture Project Vision

• Write Vision Statement
• Define Personas
• Refine Personas

Create a Quality of Service Requirement

• Brainstorm quality of Service Requirements
• Develop Lifestyle Snapshot
• Prioritize Quality of Service Requirements List
• Write Quality of Service Requirements
• Identify Security Objectives

Create a Scenario

• Brainstorm Scenarios
• Develop Lifestyle Snapshot
• Prioritize Scenario List
• Write Scenario Description
• Storyboard a Scenario

Guide Project

• Review Objectives
• Assess Progress
• Evaluate Test Metric Thresholds
• Triage Bugs
• Identify Risk

Plan an Iteration

• Determine Iteration Length
• Estimate Scenario
• Estimate Quality of Service Requirements
• Schedule Scenario
• Schedule Quality of Service Requirement
• Schedule bug Fixing Allotment
• Divide Scenarios into Tasks
• Divide Quality of Service Requirements into Tasks

Guide Iteration

• Monitor Iteration
• Mitigate a Risk
• Conduct Retrospectives

Create a Solution Architecture

• Partition the System
• Determine Interfaces
• Develop Threat Model
• Develop Performance Model
• Create Architectural Prototype
• Create Infrastructure Architecture

Build a Product

• Start a Build
• Verify a Build
• Fix a Build
• Accept Build

Fix a Bug

• Reproduce the Bug
• Locate the Cause of a Bug
• Reassign a Bug
• Decide on a Bug Fix Strategy
• Code the Fix for a Bug
• Create or Update a Unit Test
• Perform a Unit Test
• Refactor Code; Review Code

Implement a Development Task

• Cost a Development Task
• Create or Update a Unit Test
• Write Code for a Development Task
• Perform Code Analysis
• Perform a Unit Test
• Refactor Code
• Review Code
• Integrate Code Changes

Close a Bug

• Verify a Fix
• Close the Bug

Test a Quality of Service Requirement

• Define Test Approach
• Write Performance Tests
• Write Security Tests
• Write Stress Tests
• Write Load Tests
• Select and Run a Test Case
• Open a Bug
• Conduct Exploratory Testing

Test a Scenario

• Define Test Approach
• Write Validation Tests
• Select and Run a Test Case
• Open a Bug
• Conduct Exploratory Testing

Release a Product

• Execute a Release Plan
• Validate a Release
• Create Release Notes
• Deploy the Product

Artifacts (Work Products)

• Vision Statement
• System Architecture (See DSI and Whitehorse)
• Test Plan (see Context-Driven Testing)
• Personas
• Scenarios
• Storyboards
• Development Tasks
• Interface Models
• Architectural Prototypes
• Unit Tests
• Classes
• Change Sets
• Check In Notes
• Test Cases
• Bug Reports

Disciplines

• Requirements
• Planning
• Architecture
• Development
• Test

Who Does What

Business Analyst

• Capture Project Vision
• Create a Quality of Service Requirement
• Create a Scenario

Project Manager

• Guide Project
• Plan an Iteration
• Guide Iteration

Architect

• Create a Solution Architecture

Developer

• Build a Product
• Fix a Bug
• Implement a Development Task

Tester

• Close a Bug
• Test a Quality of Service Requirement
• Test a Scenario

Release Manager

• Release a Product

Cycles and Iterations

• Product definition, development, and testing occur in overlapping iterations resulting in incremental completion of the project.
• Different iterations have different focus as the project approaches release.
• Small iterations allow you to reduce the margin of error in your estimates and provide fast feedback about the accuracy of your project plans.
• Each iteration should result in a stable portion of the overall system.

Iterations

Iteration 0

• Project Setup
• Plan

Iteration 1

• Plan
• Develop and test
• Feedback

Repeat as needed

• Plan
• Develop and test
• Feedback

Iteration N

• Develop and test
• Release product

Team Model

Advocacy Groups

• Architecture.
• Development
• Product Management
• Program Management
• Release Management
• Test
• User Experience

Who Advocates What

• Architecture - advocates for the System in the Large.
• Development - advocates for the Technical Solution.
• Product Management - advocates for the Customer Business.
• Program Management - advocates for Solution Delivery.
• Release Management - advocates for the smooth delivery and deployment of the solution into the appropriate infrastructure.
• Test - advocates for Solution Quality from the Customer Perspective.
• User Experience - advocates for the most effective solution in the eyes of the intended users

Team Principles

• Team of Peers.  A team of peers with clear accountability, shared responsibility and open communications. Each role is accountable for a specific share of the quality of the overall solution.
• Advocacy for All Key Constituencies.  Advocacy for all key constituencies who must be represented on a successful software project. Every perspective is represented to provide the checks and balances that prevent errors of omission and lopsided decisions.
• Stretch to Fit.  Stretch to fit to the scale necessary for the specific project. Constituencies may be combined in small teams or further refined as teams scale for larger projects.

Governance

Concerns the control of time and money relative to the flow of value:

• Are we doing the right thing?
• Can we do it within time and budget?
• Are we ready to integrate?
• Are we ready to deploy?
• Are we realizing the value?

Additional Resources

• Microsoft Solutions Framework (Wikipedia)

My Related Posts

• Rational Unified Process (RUP) at a Glance

Six Key Principles

• Adapt the process
• Balance stakeholder priorities
• Collaborate across teams
• Demonstrate value iteratively
• Elevate the level of abstraction
• Focus continuously on quality

Activities

Analysis and Design

• Assess viability of Architectural Proof-of-Concept (Architect)
• Architectural Analysis (Architect)
• Identify Design Mechanisms (Architect)
• Identify Design Elements (Architect)
• Construct Architectural Proof-of-Concept (Architect)
• Incorporate Existing Design Elements (Architect)
• Describe the Run-time Architecture (Architect)
• Describe Distribution (Architect)
• Capsule Design (Capsule Designer)
• Database Design (Database Designer)
• Use-Case Analysis (Designer)
• Use-Case Design (Designer)
• Subsystem Design (Designer)
• Class Design (Designer)
• Design Testability (Designer)
• Elements (Designer)
• Design the User-Interface (User-Interface Designer)
• Prototype the User Interface (User-Interface Designer)
• Review the Architecture (Technical Reviewer)
• Review the Design (Technical Reviewer)

Implementation

• Structure the (Software Architect)
• Implementation Model (Software Architect)
• Implement Developer Test (Implementer)
• Execute Developer Test (Implementer)
• Analyze Runtime Behavior (Implementer)
• Implement Design Elements (Implementer)
• Implement Testability Elements (Implementer)
• Develop Installation Artifacts (Implementer)
• Plan System Integration (Integrator)
• Plan Subsystem Integration (Integrator)
• Integrate Subsystem (Integrator)
• Integrate System (Integrator)
• Review Code (Technical Reviewer)

Artifacts

Analysis and Design

• Deployment Model
• Software Architecture Document
• Analysis Model
• Design Model
• Architectural Proof-of-Concept
• Reference Architecture
• Interface
• Signal
• Event
• Protocol
• Capsule
• Testability Class
• Design Class
• Analysis Class
• Use-Case Realization
• Design Subsystem
• Design Package
• Navigation Map
• User-Interface Prototype
• Data Model
• Test Design

Implementation

• Implementation Element
• Implementation Subsystem
• Testability Element
• Test Stub
• Integration Build Plan
• Build
• Implementation Model

Phases

• Inception Phase
• Elaboration Phase
• Construction Phase
• Transition Phase

Disciplines

Development Disciplines

• Business Modeling
• Requirements
• Analysis & Design
• Implementation
• Test
• Deployment

Support Disciplines

• Configuration Management & change management
• Project management
• Environment
• Operations & support

Enterprise Disciplines

• Enterprise business modeling
• Portfolio management
• Enterprise architecture
• Strategic reuse
• People management
• Enterprise administration
• Software process improvement

Additional Resources

• IBM Rational Unified Process (Wikipedia)
• Rational Unified Process Home (IBM)

System Architecture

Beck writes:

Architecture is just as important in XP projects as it is in any software project.  Part of the architecture is captured by the system metaphor.  If you have a good metaphor in place, everyone on the team can tell about how the system as a whole works.

The First Iteration Must Be a Functioning Skeleton of the System as a Whole

Beck writes:

The next step is to see how the story turns into objects.  The rules of the Planning Game state that the result of the first iteration must be a functioning skeleton of the system as a whole.  But you still have to do the simplest thing that could possibly work.  How can you reconcile these two?

Pick a Set of Stories that Force You to Create the Whole Architecture

Beck writes:

For the first iteration, pick a set of simple, basic stories that you expect will force you to create the whole architecture.  Then narrow your horizon and implement the stories int eh simplest way that can possibly work.  At the end of the exercise you will have your architecture.  It may not be the architecture you expected, but then you will have learned something.

Put as Much Architecture as You Need or Put the Whole Architecture in Place on Speculation

Beck writes:

What if you can’t find a set of stories that force you to create the architecture you know, you absolutely know, you are going to need?  Either you can put the whole architecture in place on speculation, or you can put as much architecture in place now as you need to meet your current needs, and trust that you can put more in later.  I put in the architecture I need now and trust my ability to change it later.

Key Take Aways

Here’s my key take aways:

• Have a system metaphor.
• Pick a set of stories that force you to build a skeleton of the system as a whole.
• If you can’t find the right stories, then either base the architecture on speculation or put as much architecture in place as you need for now.

Additional Resources

• System Metaphor (C2.com)

My Related Posts

• Periodic Design Refactoring
• Architectural Styles, Patterns, and Metaphors
• Architectural Patterns vs. System Metaphors

Fixed Price / Fixed Date / Roughly Variable Scope

Beck writes:

Folks seem to have the most trouble running a fixed price contract extreme.  How can you do a fixed price / fixed date / fixed scope contract if you play the Planning Game?  You will end up with a fixed price / fixed date / roughly variable scope contract.

The Requirements Weren’t Clear

Beck writes:

Every project I’ve worked on that had fixed price and scope ended with both parties saying, “The requirements weren’t clear.”  And the typical fixed price and scope project pulls the two parties in exactly opposite directions.  The supplier wants to do as little as possible and the customers wants to demand as much as possible.  Within this tension, both parties want a successful project, so they back off of their primary goals, but the tension is always there.

Nobody Complains If They Get Something More Valuable

Beck writes:

Within XP, the relationship changes in a subtle but important way.  The initial scope is a “for instance.”  For example, for 5,000,000 deutsche marks we think we could produce the following stories in 12 months.”  The customer has to decide if those stories would be worth 5,000,000 DM.  If those initial stories are what the team ends up producing, great.  Chances are that the customer will replace some of the stories with even more valuable ones.  Nobody complains if they get something more valuable.  Everybody complains if they get what they asked for but it isn’t what they now know that they want.

It’s More Like a Subscription

Beck writes:

Instead of fixed price / date / scope, the XP team offers something more like a subscription.  The team will work at top speed for the customer for a certain amount of time.  They will track the customer’s learning.  At the beginning of every iteration the customer has a formal chance to change direction, to introduce entirely new stories.

Small Releases

Beck writes:

Another difference XP introduces is caused by small releases.  You would never do an XP project for 18 or even 12 months without being in production.  Once the team has signed up to do 12 month’s worth of stories, they will play the Planning Game with the customer to determine the scope of the first release.  So a 12-month contract might put the system into production after three or four months, with monthly or bimonthly releases thereafter.  Incremental delivery builds in the opportunity for the customer to terminate the contract if progress is slower than initially estimated, or if business conditions make the whole project nonsense, and it gives the customer natural points to change the direction of the project.

Key Take Aways

Here’s my key take aways:

• Fix the schedule and price, but flex the scope.
• Reduce risk by fixing schedule and cost.
• Flex the scope so you can continuously deliver whatever the customer decides is more valuable as the project progresses.
• Deliver incremental value.
• Think of it like a subscription where the customer subscribes to your development services.

In practice, I’ve found fixing the time and cost, but flexing the scope to be the most effective way to manage projects across a variety of scenarios.  While there’s exceptions, the worst scenario I hit is fixed time and fixed scope where the assumption is you can buy your way to a faster solution.  It reminds me of the saying, no matter how many people are involved, it still takes nine months to make a baby.

Gradually Replace Team Members with the Customer

Beck writes:

The “big thump” delivery of outsourcing violates the incremental change principle.  There is a slight twist on outsourcing that XP can deliver.  What if you gradually replaced the members of the team with technical folks from the customer?  I call this “insourcing.”

Gradually Shift Responsibility for the System

Beck writes:

It has many of the advantages of outsourcing.  For example, it lets the supplier give the customer the benefit of detailed technical knowledge.  By gradually shifting responsibility for the system, insourcing doesn’t give the customer the risk that they will inherit a program they can’t sustain.

Example Insourcing Arrangement

Beck writes:

Let’s look at a sample insourcing arrangement provided by the supplier of  a 10-person team.  The contract is for 12 months.  Initial development lasts three months, followed by deliveries once a month for 9 months.  The customer supplies one technical person for the initial development.  Thereafter, every other month the customer brings in one new person, and the supplier takes off one person.  At the end of the contract, half the team are customer employees, ready to support the program and continue development, albeit at a slower pace.

Adjust How Much You Commit To

Beck writes:

XP supports insourcing by having the team constantly measure their speed.  As team members shift around, the team as a whole is bound to go faster and slower.  By constantly measuring achieved productivity, the team can adjust how much they commit to get done in the iteration of the Planning Game.  As experts leave and less experienced people replace them, the team can reestimate the remaining stories.

Key Take Aways

Here’s my key take aways:

• To insource, gradually swap out the development team with technical members from the customer.
• Insourcing helps reduce the risk of a customer inheriting a system they can’t sustain.
• Consider insourcing to reduce the risk of shifting responsibility of the system to the customer.
• Using XP, you can adjust how much you commit to get done as you shift team members around.

In patterns & practices, we’ve used a process similar to “insourcing” but we called it co-development.  The customer would provide heads and/or budget.  in return, they would learn hands on and help shape the deliverable.

Now You Are Ready to Learn

Beck writes about a student learning to become a swordsman.  The master strikes the student each time his attention slips.  The student becomes paranoid about getting whacked and eventually gives up:

Soon he sat down and cried in frustration.  “I just can’t take it.  I’m not cut out to be a swordsman.  I’m going home.”  At that moment, without understanding exactly why, he drew his sword and whirled, blocking the master’s stroke.  The master said, “Now you are ready to learn.”

We’re Vulnerable to the Eventualities We Can’t Imagine

Beck writes:

We can drive ourselves crazy with expectation.  But by preparing for every eventuality we can think of, we leave ourselves vulnerable to the eventualities we can’t imagine.

Expect Nothing and You Can No Longer Be Surprised

Beck writes:

There is another way.  The team can be perfectly prepared at any moment to go in whatever direction the business or the system demands.  By giving up explicit preparation for change, paradoxically they become entirely prepared for any change.  They expect nothing.  They can no longer be surprised.

Key Take Aways

I’m a fan of having a fallback position, but the point here is to be more adaptable to change over trying to anticipate every possibility.  Here’s my key take aways:

• Expect nothing and you can no longer be surprised.
• Expect the unexpected, but don’t over engineer for it.
• Make the most of the situation.
• Don’t spend time planning for exceptions that you could spend taking action.
• Rather than explicit preparation for change, be adaptable and flexible in your approach.

The Full Value of XP Comes When All the Practices are in Place

Beck writes:

The full value of XP will not come until all the practices are in place.  Many of the practices can be adopted piecemeal, but their effects will be multiplied when they are in place together.

The 20-80 Rule

Beck writes:

Software programmers are used to dealing with the 20-80 rule — 80% of the benefit comes from 20% of the work.  XP makes use of this rule itself - put the most valuable 20% of functionality into production, do the most valuable 20% of the design, rely on the 20-80 rule to defer optimization.

The 20-80 Rule Applies Where Controls are Relatively Independent

Beck writes:

For the 20-80 rule to apply, the system in question must have controls that are relatively independent of each other.  For example, when I tune the performance of a program, each possible place I could tune generally has little effect on the other places I could tune.  I never find myself in a situation where I tune the biggest time hog, only to find that because of that tuning I can’t tune the next one.  In a system with independent controls, some of them are bound to be more important than others.

Greater Than the Sum of the Parts

Beck writes:

The practices and the principles work together with each other to create a synergy that is greater than the sum of the parts.  It’s not just that you do testing, it’s that you are testing a simple system, and it got simple because you had a pair programming partner who challenged you to refactor and reminded you to write more tests and patted you on the back when you got rid of complexity and ….

You Gain the Most When You Put All the Pieces in Place

Beck writes:

Is XP all or nothing?  Do you have to follow these practices to the letter or risk not seeing any improvement?  Not at all.  You can get significant gains from parts of XP.  It’s just that I believe there is much more to be gained when you put all the pieces in place.

Key Take Aways

Here’s my key take aways:

• You can adopt XP piecemeal.
• The 20-80 Rule applies where controls are relatively independent.
• You gain more from XP when you put all the pieces in place.

Architectural Exploration

Beck writes:

The programmers should also experiment with architectural ideas — how do you build a system for multiple levels of undo?  Implement it three different ways for a day and see which one feels best.  These little architectural explorations are most important when you find the user coming up with stories that you have no idea how to implement.

My Thoughts

I’m a fan of testing multiple paths to find the best fit.  I tend to call these “architectural spikes.”  That said, before you test technical risk, make sure you first test the user experience.  Nothing’s worse than implementing something that’s tough, only to find out nobody wants it.   You can use slides or whiteboard walkthroughs to test user experience.

It’s also important to pick your battles.  You won’t have time to test everything three ways, so ruthlessly prioritize your highest risks.

Key Take Aways

Here’s my key take aways:

• Implement three variations and pick the one that feels right.
• First nail the user experience, then nail the technical risk.
• Ruthlessly prioritize your highest risks.

My Related Posts

• User, Business, and Tech
• What are the User, Business, and System Goals