Xtreme Vibing: values, principles, and practices

The values, principles, and practices of Xtreme Vibing. The last table shows where each XP practice went.

Values #

Value	What we mean
Build for users #	Value is the experience of the person using the software. Understanding users and creating value for them is the job of everyone on the team. Work that is not for their good is refused.
Be empirical #	We decide from evidence of real use, not from what we expect. A decision about what the user experiences is void without a recent session with users or a packet from real use. Prototypes are run and compared, not argued. Standards are earned by misses. Budgets are corrected by what the work actually spent. The process itself is a hypothesis: we start with the best we know and refine it as we work. Everyone on the team is learning, by doing.
Invest in trust #	The team must trust each other and the system they use to build the system. The people who fund the software must trust the team with the product. Trust is earned, and it is necessary for speed.

Discipline is not a value. It is what XV is: discipline at speed. Some of it is enforced by agents and the pipeline. The rest is owned by the people.

Two things exist before the work starts and are not values. The mission says why we are here. The vision says what the solution is becoming. The team is responsible for knowing both, and uses them to refuse work. The business's goals enter there and stop there. The business does not decide details.

Shareholder return was set by the people who funded the software, before this team. It does not affect the ranking of work.

A stakeholder is not a user. A product owner is one user, at best, and is most likely a proxy. Sitting with either one is not sitting with the people who use the system.

Principles #

Principles are the bridge between the values and the practices, as they were in XP. They say how a person decides, whatever the practice. Every practice feeds one of the first two. Go and see says where the evidence comes from. Ship at will opens the gate. Own the result closes the loop.

Principle	What it is
Decide from evidence #	Two or more people work through the same packet and decide. This is the pair programming of XV. They name which difference mattered or which cost is worth paying. The decision is written down short, with who took part, and binds later agents. This covers a usability prototype pick, a shape change that adds an abstraction, and an edit that changes what the system is for. The shape conversation's standing moments (before a burst and as it ends) can open it. Contact and Parallel prototypes feed it. The guardian identifies a shape change and produces the packet. The packet always includes access to the raw data. The form stays the team's. There is no approve button.
Lead with conviction #	One person who is accountable decides from experience, responsibility, and judgment. They are data-informed. The engineer making a change has the right and the duty to make it alone, unless the guardian, or they themselves, call for a second human. Typical cases: ranking the value queue, where evidence from use feeds the ranking and rarely settles the order, so the order is the ranking person's conviction (no separate recorded reasons; a ranking with no recent session or packet behind it is still void); a performance or narrow approach on the change being made, when the choice stays inside the current shape; an old test that changed, when the shape did not; a change to the shared operating picture that is not a shape or pitch change. This is collective ownership in XV. Anyone may change what a scenario requires. No one personally owns a file or subsystem. Agents build. The person who set the work going accepts it and ships it to production. Any teammate may do that in their place. The decision is not written down unless it will make a future job easier. If the guardian flags a shape change, it escalates to Decide from evidence. Generating axes for Parallel prototypes does not require a second human.
Go and see #	Lean's genchi genbutsu: go to the real place and look at the real thing before you decide. In software the real place is where the system is used. It is not the code, and it is not the factory. A decision about what the user experiences is void without a recent session with users or a packet from real use. That is the ranking, a prototype pick where the axis was the interaction, an edit to the pitch, and a shape change justified by what the user needs. The packet says what the raw data means, and carries the raw data with it: the diff, the telemetry, the session recordings. A person reads the meaning first, and may go into the raw, with an agent's help if they like. A report that cannot be checked against the real thing does not count. A packet alone may rank a small slice. It may not harden a shape or rewrite the pitch. A meeting is not contact.
Ship at will #	The gate is released to the person. The harness sets the conditions: red before green, the test wall, the three agents, and a build that returns in minutes. When they are met, the person who set the work going merges and picks the moment. Any teammate may do it in their place. Nobody else approves. A required approval is the right gate for strangers, which is why open source needs it. On a team it becomes the process, and collaboration moves to the fence.
Own the result #	A person is responsible for the consequences of every change, including one made entirely by agents. This is why the harness may stop and may not decide. When it sees a shape change, a pitch contradiction, a spent budget, changed tests, or a changed picture, it stops and puts the decision in front of a person, and that person answers. When production raises its hand, the person who set the work going answers first. Nobody hands a result to the machine.

Practices #

Of the team #

Practice	What it is
The shared operating picture #	The team's current understanding, written down: the users, what the system is right now, and ideas for how it can better represent the vision. It does not repeat what the code says. It is enough for a new person, or an agent, to understand the context: the shape, the names, the decisions that bind, who the users are, what is in motion. Agents pull it, or parts of it, when needed. It is not loaded by default. Yesterday's change is part of today's picture, and that change rides in the packet, accepted by the person who set the work going. A change to the shape or the pitch still takes two people. The name comes from the common operating picture of military and emergency operations.
The shape #	The structure of the system as the team can observe it: design concerns such as coupling, and runtime concerns such as response time budgets. A change to the shape is decided by people in conversation, not with an approve button. A cleanup that adds an abstraction is a shape change, not a cleanup. Work tends to come in bursts, and the shape is rethought before a burst and as it ends.
The value queue #	One person ranks the work by customer value, so the ranking is a decision and the product stays one product. Any teammate may take the next task. Responsibility for ranking work does not make customer value that person's job alone. A conflict between the user and the people paying gets escalated.
The pitch #	A short page in the repo: what the system does, why, and for whom. An agent may not invent a second purpose. A change to it lands when a second person agrees.
Contact #	Sit with the people who use the software, or with data about how they actually use it. A meeting with a stakeholder is not contact with a user.
Parallel prototypes #	For a change where the scenario does not settle the design, and a wrong design would be felt in use. Have agents build three running versions that differ on one named axis. At least two people choose between them by naming which difference mattered. One is chosen, or none. When the evaluated set points at a combination, or at a new direction, run another round. Involve real users whenever possible. A prototype may run in production for a few real users when that is the only way to learn. It is still discarded at the pick.
Attention #	A person who is too tired or spread too thin does not make the call today. A teammate who is not fit to decide today is told so. Agents may run while a person is away. Decisions do not pile up. The pace stays human even while going fast. When the chief engineer is away, one designated person holds the value queue and the pitch; the duty does not become consensus. Decide from evidence requires a synchronous conversation, so the team keeps overlap in working hours.

Of the machine #

The harness enforces these. The harness is the agents, the test suite, and the pipeline.

Practice	What it is
The test wall #	A scenario shown to fail before the fix. The existing suite is the wall. The maker may move an old test only when the scenario forces it, and records why. The guardian lists every changed test in the packet for the change. The person who set the work going accepts them, and decides whether to talk it through or ship. A shape change always goes to two people.
The budget #	A budget on the task, including an expectation of shape change and its breadth (none, narrow, or wide). Spent without the tests passing, the work stops, and a person decides whether the task was the wrong one. Learnings from estimate versus actual become team-wide; agents update an estimation guide. An individual may increase the budget and continue under Lead with conviction, up to a team-agreed limit; beyond that, or if the shape change is wider than expected, Decide from evidence.
The three agents #	Three separate contexts. The maker makes it work behind the test wall. It may move an old test when the scenario forces it, and records why. The cleaner makes it right: fixes structure and style, commits the fix, keeps changes to old tests small, and rejects a real test turned fake. A structural change and a behavior change do not ride in the same pass. It maintains a file of rules earned by repeated misses and applies them. The guardian checks for a shape change, a pitch contradiction, a changed test, and what the change does to the shared operating picture. A shape change or a pitch contradiction stops the change for Decide from evidence. Changed tests and picture changes alone go in the packet to the person who set the work going, who may opt into Decide from evidence. Under Lead with conviction an engineer may send work through to production unless the guardian stops it. The team may run additional agents or multiples of each role. The three contexts stay separate.
The fast build #	The merge waits on the pre-merge suite (the commit stage) that returns in minutes. A skipped suite is a failed build. Slow checks run post-merge; their failure reverts the main line and raises a new defect. Ten minutes is the inherited proxy, not a law. A slow suite is a defect in the suite.
Ship #	An increment that cannot be used by a user is not done. The person who set the work going merges when the suite is green and the three agents have found no break that requires a person. Any teammate may do that in their place. No second person approves the merge. When production raises its hand, the person who set the work going answers first.

The original twelve practices #

XP practice	What it was for	XV practice
Planning game #	Rank the next work by customer value, with the people who will do it	The value queue
Small releases #	Put a thin slice in front of real use, often	Ship
Metaphor #	One shared story of what the system is	The pitch
Simple design #	The simplest thing that could work, for the need known today	The shape
Testing #	Feedback from the system, with the dial turned up to test-first	The test wall
Refactoring #	Keep the design fit to change, apart from new behavior	The three agents
Pair programming #	A second mind on the work, all the time	Decide from evidence
Collective ownership #	Anyone may change any part	Lead with conviction
Continuous integration #	Integrate many times a day, so the trunk is the system	The fast build
Sustainable pace #	The team can do this again tomorrow	Attention
On-site customer #	A real user with the team, accepting the work	Contact
Coding standards #	One team can read one another's work	The three agents

Slack, from the 2004 edition, is The budget. Parallel prototypes are ours. They have no single parent in the twelve. Pair programming and collective ownership went to principles, not practices: the second mind and the right to change any part are now rules about how a person decides.