Thumbnails 

This section includes short descriptions of all the patterns we have identified to date. Slight variations on these names are used in the text to elicit the ideas. Some of the alternate names, given in parentheses here) are used interchangeably. 

Acceptance Tests. Create a suite of Executable Tests that will be sufficient for the customer to accept the work. They are under control of the customer.

All Manager Scrum. (distributed project) Site managers have a frequent coordination meeting.

Ambassador. [5] (distributed project) A representative of a needed skill group visits the remote team.

Architecture Sprint. (large project) In a sufficiently large/complex project, it may be necessary to have an initial iteration that sets a starting overall architecture for the system. This architecture may need to evolve over time so simplicity here is a virtue as elsewhere.

Ask For More. When you know you will have extra time within an iteration, ask the customer for more work.

Be Human (Humane Workplace). Provide a Humane Workplace to maximize productivity.

Be Together. (distributed project) Adjust time schedules to overlap in time as much as possible.

Best Effort. The contract is not for features delivered on a given date. You want Best Effort and Full Communication.

Beyond Extreme. (distributed project, primarily) Push all practices to their most disciplined point.

Bonding. (distributed project) Provide funds for social Bonding within the team.

Bug Generates Test. When a bug appears in code, write a set of tests that will only pass when it is corrected.

Cards and Whiteboards. Things change too frequently to depend on elaborate documentation mechanisms.

Coding Standard. Everyone shares the same coding look and feel.

Collective Ownership. The team as a whole owns all of the created artifacts, especially the code.

Collective Responsibility. The team shares responsibility and rewards for all tasks.

Common Development Environment. [10] (distributed project, primarily) All developers use a common platform and agreed tools.

Constant Refactoring. The structure of the code is continuously improved to take account of all stories built to date.

Continuous Integration. Every task is integrated at completion and all unit tests are made to pass.

Cultural Awareness. [10] (distributed project) Develop resources to overcome cultural differences.

Customer Checks-Off Tasks. Only the customer knows when something is done.

Customer Obtains Consensus. The customer role is responsible for obtaining consensus among the stakeholders.

Customer-Tester Pair. (distributed project) The customer works at one location with an acceptance tester.

Daily Deployment. (tentative) Deploy new features daily.

Daily Scrum. See Stand Up Meeting.

Deliver Customer Value. Building things may be fun or not, but don't lose track of the real reason we are doing this.

Documentation Is Just Another Task.  Every story requires some kind of documentation. If it must be extensive, include it in estimates.

DTSTTCPW. Do the Simplest Thing that Could Possibly Work. Build the code to implement the story and nothing more. Pay for generality only when you know you need it.

Easy Does It (Don't Push Too Hard). As a customer, Don't Push Too Hard. It frustrates everyone. If you push too hard and "win," you lose if the iteration doesn’t complete successfully.

Effective Coach. A novice team depends fundamentally on a coach (ScrumMaster) to keep you to the discipline and help you see opportunities and problems.

End To End. The first release is an End To End version of the product.

Energized Work. Sustainable Pace. Management sets work conditions so that everyone can work at their optimum over extended periods. E.g. Forty Hour Workweek.

Estimate Whole Task. Estimates must include everything necessary for a story.

Executable Tests. Tests are run so frequently they must be executable.

Face Time. (distributed project) Schedule time for significant parts of the team to work periodically on one site, especially the customer and developers.

Feature Focused Teams. (distributed project primarily) Create teams around the features, not according to skill types. 

Flexible Velocity. Use velocity to allow for needed work that is not in the stories. But learn to get it into the stories.

Full Communication. The developers keep the customer apprised always of opportunities, costs, difficulties, etc. The customer keeps the developers in the loop on the business needs and thinking that may affect future directions.

Graceful Retreat. When you have overcommitted to an iteration, the customer chooses the work to complete.

Grow Out. (distributed project) The team begins co-located for an iteration or two.

Grow Up. Start with a small team and grow it to the required size by adding a few developers at iteration points. The other practices enable this: Promiscuous Programming...

Guiding Metaphor (Topos). Develop a Guiding Metaphor or story for the project that guides people as to the general direction.

Half a Loaf. If the team is new and there is resistance to the practices, try the ones you think will give you the most benefit and then review in a Retrospective. Consider adding more practices as you go.

High Discipline. No methodology will succeed if you don't actually do its practices faithfully. On the other hand, make sure they are the right practices or deal with the issue in a Retrospective.

High Value First. Customer selects highest value features at every point.

Humane Workplace. See Be Human.

Implementer Re-estimates Task. Tasks are best estimated by the person who will do the work.

Individual Stakeholder Budgets. When customer representatives can't come to a common understanding of priorities, they may need individual budgets of team resources.

Informative Workspace. The team room (Our Space) employs Information Radiators so that progress and impediments are visible to any visitor. Whiteboards, note boards, etc., need to have enough graphically displayed information that anyone can immediately see the progress of the current iteration as well as any bottlenecks.

Infrastructure. Before the project begins make sure the basic build, test, integrate, deploy infrastructure is in place.

Initial Velocity. The Initial Velocity, measured in story points, is a small fraction of what you estimate it is possible to do in the first iteration. Thereafter, it is just Yesterday's Weather.

Interfaces Are Just Another Story. (large project) If teams must coordinate over interfaces, write a high priority story to define the interface.

Just Do It. When faced with choices that are all feasible, just pick one and do it.

Just Start. Rather than talking and talking about how to do the project, Just Start it.

Kickoff. [5] (distributed project) Begin the project with a face to face meeting lasting some days.

Local Manager. (distributed project) Everyone has a manager local to their own site.

Multiple Communication Modes. (distributed project, primarily) Provide many modes of communication and high bandwidth if the team can't share much Face Time

My Story. Know the state of progress of the story you are working on.

Nano-Project. (large project, usually) A tiny project can quickly show the benefits of agile development to a reluctant stakeholder.

Negotiated Scope Contract. Scope is the dependent variable in an agile project, so plan for this when you write your development contracts.

Offer Alternatives. Developers offer alternatives to Customers when they recognize them. Conversely, customers offer alternatives on desired features to developers to get feedback on likely costs and consequences.

Once And Only Once. [2] Refactor code so that everything is said only once. But pay for generality only when you must.

One Project. Everyone works on only one project at a time.

Onsite Customer (Product Owner). The customer works in the team's room along with the rest of the Whole Team. Communication distance is very expensive.

Our Space. The Whole Team works together in an open workspace to optimize communication.

Pair Programming. No code is committed to the code base unless it is written by a pair.

Pay Per Use. (tentative). Write a contract with the customer that will pay you per use of the system. Take on the risk of failure and share in the success.

Personal Velocity. Each developer knows how much work she can do in an iteration. The Project Diary helps her keep records of past work. Individual estimates are too variable to be a management tool.

Planning Game (Sprint Planning Meeting). Once each iteration (every two weeks, say) the team spends time planning the iteration, including what stories will be immediately built. See the literature as this is a highly disciplined planning exercise.

Presence Indicator. (distributed project) Provide a way for everyone else's presence to be obvious to you when they are available.

Product Owner. See Onsite Customer. 

Project Diary. Each developer keeps a bound book for the project. It is private to the individual and contains things like estimates vs. actuals on stories built, who you paired with, ideas for the next Retrospective, etc.

Promiscuous Programming. Spread the knowledge of the project amongst the team members.

Question Implies Acceptance Test. When the customer answers a question from the developers, she captures the answer in an acceptance test.

Rapid Response Teams. (distributed project) Provide a matrix of skilled people to assist teams.

Re-estimate Periodically. Things change and estimates become obsolete.

Relative Estimates. Estimate quickly into a small number of estimation "bins." Don't spend time to be more precise than necessary in estimation.

Remote Pair [5] (distributed project) Find the tools to pair remotely and do it consistently.

Retrospective. Periodically hold a retrospective [14] of the team's practices.

Sacred Schedule. Time never slips in agile development. Features are the dependent variable.

Scrum of Scrums. (large project) ScrumMasters hold a periodic (daily) coordination meeting.

ScrumMaster. The ScrumMaster is responsible for process and for removing obstacles.

Self-Organizing Team. The team is responsible for its own internal process, practices, and management.

Sheltering Manager. A new team will depend on some shelter from those in the organization who don't readily accept change.

Shorten the Path. Shorten the communication distance between team members in any way possible.

Shrinking Teams. If team velocity is increasing it may be possible to shrink the team and maintain sufficient velocity. Those freed can initiate other projects.

Simple Design. Design only for the current stories. Simple logic, minimal generality, pass the tests.

Single Point Organization. [10] (distributed project) Everyone has a single reporting manager, and if that manager is at another site, a local manager to provide support.

Small Releases (Incremental Development). Software is released on short cycles, say monthly.

Social Tracker. The tracker must know how everyone is doing.

Spike. Do quick prototypes to learn how to build or estimate something.

Sprint. Iterations should be very short. A week to a month. Iterations deliver business value as determined by the Onsite Customer. They are strictly time-boxed.

Stand Up Meeting (Daily Scrum). Fifteen minutes every day, to keep everyone on the same page.

Stories (Project Backlog). All work is captured on story cards that form the basis of estimation, scheduling, and projection.

Sustainable Pace (40 hour week). Pace the team for the long haul, not a sprint. You want everyone working in top form all the time.

Team Continuity. Management commits to keeping the team together throughout the project. Team members make a similar commitment.

Team Owns Individual Velocities. Individual velocities are not a management tool.

Ten Minute Build. (Tentative) Do enough optimization (just enough) so that the system will build in ten minutes.

Test Card. If the customer cannot write Executable Tests herself, then she creates Test Cards in answer to each question. The card specifies an acceptance test that will then be written by the implementer of the story.

Test First. [2] No code without a failing test.

Think Small. (large project) Begin with the small, essential, project inside the larger one you think you need. Then grow from there if necessary. This assumes you start with a small team and grow it if and when necessary. See Grow Up.

Train Everyone. Initial training includes everyone, including customers and management.

Virtual Workspace. (distributed project) Provide a cyberspace home for the team with effective communication tools.

Whole Team. The team includes everyone with an essential skill. In particular, it includes the customer as a full team member.

YAGNI. You Ain't Gonna Need it.  Don't anticipate what might not occur. Don’t scaffold speculatively.

Yesterday's Weather. The velocity of the next iteration is exactly the work successfully completed in the previous one. Of course this assumes that the time and personnel are fixed.