Extreme Programming (xp) prescribes a dozen practices that reinforce each other so as to allow teams to make software development decisions. We examine the distribution of responsibilities required for, and means to arrive at, good decisions within this framework.
Velocity provides a rough measure of this complex social process. Achieving and maintaining the process is more important for long term success than any goal one might set for velocity
# Process
Programs consist of many thousands of statements about how a computer should usefully work in the future. We call individuals who make these statements programmers and those who decide what would be useful, customers.
Extreme programming exploits the modularity that became available in the '80s to allow programmers to make and remake decisions in a closed loop with the customer.
Programmers deliver to their customer new functionality at a regular tempo and simultaneously deliver to their future selves opportunity to further expand the program in unforeseen ways. Various counting strategies allows reporting a working "velocity".
# Technique
Programmers must master and apply techniques that preserve flexibility within their code. We say code is "clean" when decisions already made are expressed with appropriate abstraction and inconsequential decisions have been removed or avoided entirely.
Code cleanliness itself requires judgement decisions that improve with experience. Extreme programming expects mastery here and will allow the team whatever time they need to achieve it to their own satisfaction. The customer is not qualified to pass judgement regarding the code.
The customer has their own decisions to make about the future functionality. Developers can offer complexity estimates in the units of past velocity so that customers can prioritize the work they ask of developers.
# Responsibility
Thus, in a professional setting, the customer orders work to be done while developers do that work with full knowledge that there is more work to come and an expectation that progress will continue at pace.
Velocity is a measure of decisions only developers can make. Developers will strive to reach an optimal velocity where functionality and opportunity produced reach a sustainable balance.
A customer who asks for less work can save investment. However, a customer who asks for faster work, sub-optimal velocity, is asking for a process that will stall.
# Consensus
A team of developers can be effective for the long term to the degree that they can make the good decisions regarding code cleanliness that extreme programming reserves for them.
Individual experience varies widely even among skilled developers. Only shared experience in a particular codebase will lead to consensus. Reading each other's code helps but cannot duplicate that of programming together while discussing the present and future impact of every decision made.
Test-driven development enables pair-programming by sequencing new experience based more on recent experience than on deep personal experience unavailable to a companion.
# Norms
Extreme programming produces exceptional results when both programmers and their customers understand these relationships and allow them to grow with the codebase.
A development team's ability to make routinely good decisions determines the velocity a customer has to live within while making their own best utility decisions.
.
See Core Agile for a more concise description of the responsibility distribution described here.
See Creativity Before and After Agile within ages defined by methods and the systems to which they apply.
See Infected with ROI and Marginal Distinction for alternative perspective on velocity.
See Writer's Burden and Writing with Strangers for similar shifts in another creative work.
.
Extreme Programming position statement reviewed in light of Woods Criteria.