Xp Self Assessment

As a tool for evaluating an XP project, this self assessment is intended to help team members and management identify areas of strength and weakness.

The assessment is designed as a set of several statements, which may be rated on a simple scale indicating how well the statement describes the project. In a sense, these statements might be thought of as a "test suite" for an XP project.

The numbers following the statement, if any, are page numbers from Kent Beck's Extreme Programming Explained book.

Refinements and annotations are welcome, as always.

- JeffMantei

ExtremeProgrammingPrinciples are the way to assess an XP project for its XPness.

Overall Principles

The important things, like testing, understanding the customer, and improving the system are continually practiced as if there is always enough time (“mentality of sufficiency”). xix

Team members respect each other and care about what they are doing. 35

Everyone produces the best quality work, and enjoys doing so. 38

The team practices are opportunities for learning and improving rather than dogmatic one-size-fits-all statements. 39

The team practices acknowledge and support what members want for themselves (doing a good job, learning, working with a team, being trusted and empowered). 41

The team practices support the long-term goals (adding business value, maintaining team knowledge, staying on schedule and within budget). 41

The team practices are adapted for local conditions. 42

Initial resources for the project are just enough to create something interesting. 39

The project goal is to add business value (“play to win”), not just holding the line or going by the book (“playing not to lose”). 40

Team members work no more than 40 hours a week as a rule. 54

Overtime is never required a second week in a row. 54

The team has the courage to fix what is broken when it is discovered. 33

Anybody who sees an opportunity to add value to any portion of the code does so at any time. 59

Overall Principles / Change

The practices’ artifacts (e.g. project documentation, processes) are lightweight to make it easier to change with shifting conditions (requirements, business, team, technology, …). 42

Early warning of problems is seen as an advantage and an opportunity to steer, not a sign of a weak or complaining project team. 154

The business culture is open to steering rather than “pointing the car.” 156

The team embraces change instead of anticipation and explicit preparation. 166

Communication

Team members frequently share knowledge about goals and solutions. xvii

Team members frequently work together to accomplish goals. xviii

Concrete tests are used to debate and capture system goals. 40

Every abstract assumption or decision made during a discussion of requirements or a design is backed up by a concrete test or experiment. 40

Team members feel free to share concerns and ideas openly and honestly. 40, 152

Developers listen to the real goals of the business customer. 47

Communication is actively encouraged by management and coach. 29

The facilities layout supports an XP style of working. 79

Team members are able to freely admit when they don’t know something. 152

Feedback

Tests are used to determine the current status of the development effort. 32

Developers estimate stories to understand them better and help customers define what they want. 31

Project velocity is reviewed every iteration to ensure the release is still on track. 32

The system is put into production as soon as enough stories are completed, to get feedback from the business as soon as possible. 32

Designs are kept simple and realized quickly to maximize feedback. 104

Feedback is available, interpreted and applied back into the system, project and team as quickly as possible. 38

Measurements on the project are practical and realistic in their precision. 42

Metrics are communicated through nothing more complicated than a Big Visible Chart. 72

The team tracks no more than three or four metrics at a time. 73

The chosen metrics have a useful range, e.g. not always nearly 100% 73

Metrics are a tool to illuminate and communicate the need for change, not managed for the sake of achieving certain values. 73

Team members listen to their intuition to determine what areas need attention. 73, 107

The technical and business environment support rapid feedback cycles. 157

Team / Responsibilities

Team members identify risks in their own areas and raise issues along with constructive suggestions. 147

Responsibilities are accepted, not assigned. 41

Business and development work together in an environment of mutual trust. 87

Developers take responsibility for estimating and completing their own work. 92, 153

Programmers first and foremost communicate with others, through tests and simple, clear code. 141

Programmers hold the line on simplicity, both in terms of the scope and the solution. 142

Programmers with a lot of ability give up the “guessing right” approach for close communication and continuous evolution. 157

The project team is no larger than about a dozen people 157

Specialist consultants are used to teach the team how to solve their own problems, not to solve things themselves in isolation. 147

Requirements / Customer

Customers take responsibility for bringing requirements to the level of concrete scenarios and functional (acceptance) tests. 118, 143

The customer maintains an up-to-date and prioritized set of user stories as requirements. 143

The customer is free to change the set of requirements or priorities. xvi

A real, live user is on the team, available full-time to answer questions, resolve disputes and set small-scale priorities. 54, 60

The customer is as much a part of the team as a programmer. 83

Customers decide on technology platform, with input on consequences from technical people. 84

The entire team understands the basic business goals and criteria for the project success.

The customer is willing to make tough decisions to prioritize and postpone features. 143

Management

The project manager is actively involved in identifying and managing risks. 147

Management provides guidance all along, not a big policy manual at the beginning. 72

Management is aware of and finds ways to resolve misfits between XP and local conditions. 72

Management does not impose a lot of overhead (long meetings, status reports, etc.) 72

Management gathers realistic and practical metrics. 72

Management collects metrics and makes sure they are seen by those whose work is being measured. 72

Management only occasionally intervenes, in situations that can’t be resolved in a distributed way, such as necessary personnel changes or ending a project. 72

The coach gets everybody else on the team to make good decisions, rather than making most of the decisions him or herself. 73

The coach works through indirection, encouraging self-reliance. 145

The tracker gathers the current crop of metrics and communicates the results to the team, along with the predicted or planned values. 75

Tracking is done without a lot of overhead. 75

Exploration / Planning

Detailed planning is done only to the next horizon. 85

The person responsible for implementing gets to estimate. 86

Planning is simplified by ignoring the dependencies between features. 86

Planning for mapping out customer priorities (releases) is done at a lower resolution than planning for development (iterations). 86

Problems are solved with a series of the smallest changes that make a difference. 38

Scope is actively managed by the entire team (business, development, management). 18

The project moves quickly into production, with few pre-production activities. 131

Exploration is used by developers to understand the nature of their tools and to practice estimating. 132

Exploration is used by customers to practice writing stories and find enough requirements to make a good first release. 132

The first release takes from two to six months, not longer. 133

Deviations from the plan lead to corrective action, such as reducing scope and/or changing the team or process. 134

Maintenance is the normal state of the project. 135

Programmers are rotated through production support duties. 136

Releases / Planning

A simple system is put into production quickly. 54

New production versions are released on a very short cycle 54

Release plans are updated as reality overtakes the plans 54

Release scope is quickly determined by combining business priorities and technical estimates. 54

Business determines which feature is more valuable to have first. 55

Business determines how much of a problem must be solved for the system to be valuable in production. 55

Business determines how much or how little needs to go into a release, that the business is better off with the system than without it. 55

Business determines the timing of a release, when it would make the most difference. 55

Technical people determine how long it will take to implement a feature. 55

Technical people explain the consequences of strategic business and technical decisions (such as the choice of database, middleware, or programming language). 55

Technical people determine how the work and team will be organized. 55

Technical people determine the detailed scheduling within a release 56

Programmers have the freedom to schedule the riskiest segments of development first, while keeping business priorities up front. 56

The release makes sense as a whole to the business (not shipped with half a feature). 56

The team is successfully balancing new functionality and modifications to existing functionality. 32

Every release begins with an exploration phase 135

Iterations / Planning

Development proceeds in short focused iterations. xv

Iterations maintain their focus over their duration.

Each iteration tackles only the most important user stories at that time. 19

Each iteration produces a completely tested, integrated, end-to-end functional system, no matter how simple. 91

The customer is directly involved in planning iteration scope.

The customer gives concrete, practical feedback on the iteration’s outcome.

Iteration plans focus on the immediate period. 85

Stories and tasks scheduled for an iteration are adjusted to keep the iteration useful.

Lessons about estimating and productivity on each iteration are applied to future iterations to make better estimates and plans. 19

Significant development tasks (such as upgrading the environment) are scheduled and prioritized along with story-related tasks. 94

Progress is tracked every other day or so on a task level to enable the team to react to schedule problems. 94

Team members are encouraged to commit to exactly what they are actually able to do with quality. 95

Iterations always deliver business value according to the customer’s priorities, not just technical improvements.

The first iteration contains a set of stories that cover the system’s conceptual framework (architecture). 113

Testing / Unit Tests

Unit tests are developed to exercise every feature of a component.

Unit tests cover the most important uses of a component.

All maintained code is covered by one or more up-to-date tests.

The tests are automated to facilitate frequest testing. 25, 116

Tests are run almost continuously as a measure of the completion of the system. xv

Development is driven by tests. 9

Tests are written before the main implementation is written.

Defects are caught early by testing. xvii

Each newly discovered defect is “remembered” by creating new tests to reveal it. 118

Programmers continually write unit tests 54

Tests are written for every production method that could possibly break. 58

Tests are isolated; they don’t interact with other tests 116

Unit tests are written for unusual circumstances which the code should handle. 118

Unit tests are written to confirm that behavior still works as expected across refactoring. 118

Unit tests are written to clarify uncertain component interfaces and their expected use. 117

Unit tests are written to validate complicated implementations. 117

Unit tests run at 100% all the time because they are maintained by the same team that develops the code. 54, 118

Functional Testing

Functional tests are developed for every important aspect of a user story.

Functional tests cover the most important uses of the system.

Functional tests capture the intent of their corresponding user stories. xvii

Customers are directly involved in creating the functional tests. xv, 143

The functional tests correctly reflect all customer requirements.

The tests are as real and end-to-end as possible.

Customers write tests demonstrating that features are finished. 54

Software features that aren’t demonstrated by automated tests “don’t exist.” 45, 57

Integration Testing

Integration and deployment are automated to facilitate frequent testing. 98

The system is integrated and built many times a day, every time a task is completed. xv, 54

No code sits unintegrated for more than a few hours. 97

Changes to the system are integrated and tested one at a time. 60

Development is a rhythm of learn/test/code/release, the completion of one task freeing attention for the next task. 99

Iteration code is integrated into the production system as you go along, at least at the end of each iteration. 136

Design / Change / Refactoring

Code is continuously being considered for refactoring. xv

When implementing a new feature, programmers look for ways to change the existing system to make adding that feature simpler. 58

After adding a feature, programmers try to make the program simpler while still running all the tests. 58

Refactoring is done “when the system asks you to,” not on speculation. 58

Changing the system is easy.

Team members get lots of practice changing the system. 25

There is a source code control system in place to facilitate shared ownership of code and revert unsuccessful changes.

Design and redesign do not end when the first release is delivered. xvii

Tests are refactored as freely as system code. 8

Big refactoring is done in incremental steps. 107

Design is not done once up front (“pointing the car”) but by incremental changes in scope and depth. 108

Changes to legacy systems and code is done in small steps, not all at once. 127

Anyone can change any code anywhere in the system at any time. 54

Refactoring / Design Principles

Methods have meaningful names. 141

Methods are short and focused. 98

Fields have meaningful names. 141

Fields are present only to support the functionality of the class.

Every piece of logic in the system has one and only one home. 48

Classes are simple and focused. 98

Data is located near the logic that manipulates it. 48

Changes in one part of the system don’t always require changes in another part. 48

Extension of the system can easily be made in just one place. 48

The source code succinctly shows the structure of the chosen system solution.

Programmers refactor (restructure the system without changing its behavior) to remove duplication. 54

Programmers refactor to improve communication 54

Programmers refactor to simplify 54

Programmers refactor to add flexibility as needed for the second or subsequent use of a component. 54, 106

Code is designed to be easy to test.

Frameworks and reusable abstractions arise from extended usage and evolution within an application, not from up front development. 163

Visual diagrams are only temporary aids for understanding the design, not maintained separately from the code. 112

Performance optimization is done after the system is running correctly. 134

Simplicity / Design

The current implementation is “the simplest thing that could possibly work”. xv, 54

Classes and logic are added strictly to support current functionality commitments. 24

Interfaces and designs start with the specific case, not the general case. 31, 106

Every problem is treated as if it can be solved with ridiculous simplicity. 38

Extra levels of indirection are not used without a clear functional or explanatory purpose. 48

Extra complexity is removed as soon as it is discovered. 54

The team has the courage to remove or simplify code that is complex or unnecessary. 33

The system design runs all of its tests successfully. 57

The system design has no duplicated logic. 57, 109

The system code (including tests) states every intention important to the programmers. 57, 109

The system design has the fewest possible classes and methods (after fulfilling the goals of communication and no duplication). 57, 109

Design decisions do not anticipate the future. 104

The business and technical environment, including legacy systems, do not force a complicated design. 157

Architecture

Development is guided by a simple shared story of how the whole system works. 54

Everyone understands the basic conceptual framework (metaphor) of the system. xv

Everyone is welcome to define and refine the conceptual framework as new insights arise. xv

Coding / Pair Programming

The code is the only authoritative source for information about the solution. 44

Programmers write all code in accordance with simple rules, acceptable to the team, which emphasize communication. 54, 61

All of the current code base, including tests, is known to at least two members of the team. 100

New production code is always immediately reviewed by another developer. xv

All production code is written with two programmers at one machine. 54

One pair partner (driving) thinks about the best implementation of the current method under consideration. 58

One pair partner thinks strategically, about the rightness of the approach, other test cases that might not work yet, and ways to simplify the system to take care of the current problem. 58

Pairing is dynamic. 59

Pairs write tests together to align their understanding before tackling the meat of the implementation. 67

Complex code does not last long because collective ownership discourages it and works to simplify it. 99

No code is exempt from change as long as tests are kept running. 99

No one is prevented from accomplishing a task because they cannot change code someone else wrote. 100

Pair partners keep each other accountable to following the core practices of the team, such as writing tests, refactoring, and integrating. 102