Extreme Programming Self-Assessment

Derived from Shore, James. The Art of Agile Software Development. 1st ed. O'Reilly Media, 2007.1

Welcome to the XP Self-Assessment. Answer the questions below and get a glimpse of where your team needs to go next!
Does the team have a plan for achieving success?
Can any programmer on the team currently build and test the software, with an unambiguous success/fail result, with a single command?
Are nearly all of the line items in the team's plan customer-centric, results-oriented, and order-independent?
Does the team deliver customer-valued stories every iteration?
Do all important stakeholders agree on what the team is building, why, and what the stakeholders jointly consider success?
Do programmers usually improve the code when they see opportunities, regardless of who originally wrote it?
Do all programmers integrate their work with the main body of code at least once per day?
Does the team improve their process in some way at least once per month?
When a programmer gets the latest code, are they nearly always confident that it will build successfully and pass all of its tests?
Are all important stakeholders currently happy with the team's progress?
Do programmers critique all production code with at least one other programmer?
Does the team provide a working installation of its software for stakeholders to try at least once per month?
Does the team regularly seek out new information and use it to improve their plan for success?
Does the integration build currently complete in fewer than ten minutes?
Can any programmer build and test the software on any development workstation with nothing but a clean check-out from version control?
Is there more than one bug per month in the business logic of completed stories?
Do programmers ever spend more than an hour optimizing code without customers' approval?
Are on-site customers rarely surprised by the behavior of the software at the end of an iteration?
Do all important stakeholders currently trust the team's ability to deliver?
Do unexpected design changes require difficult or costly changes to existing code?
Are any team members unsure about the quality of the software the team is producing?
Are nearly all team members aware of their progress toward meeting team goals?
Except for the occasional bad day, are team members focused and engaged at work?
Do nearly all team members trust each other?
After a line item in the plan is marked "complete", do team members later perform unexpected additional work, such as bug fixes or release polish, to finish it?
Do programmers have more than one debug session per week that exceeds ten minutes?
Do nearly all programmers share a joint aesthetic for the code?
Are programmers nearly always confident that the code they've written recently does what they intended it to?
Do nearly all team members understand what they are building, why they're building it, and what stakeholders consider success?
Does the team's plan incorporate the expertise of both business people and programmers, and do nearly all involved agree the plan is achievable?
Do all programmers agree that the code is at least slightly better each week than it was the week before?
Do all team members use version control for all project-related artifacts that aren't automatically generated?
Do programmers ever make guesses rather than getting answers to questions?
Are programmers usually able to start getting information (as opposed to sending a request and waiting for a response) as soon as they discover their need for it?
Are all programmers comfortable making changes to the code?
Do any programmers optimize code without conducting performance tests first?
Do all team members consistently, thoughtfully, and rigorously apply all of the practices that the team has agreed to use?
Do team members generally communicate without confusion?
Does the team nearly always deliver on its release commitments?
Does the team make delivery commitments prior to each time-boxed interval, then nearly always deliver on those commitments?
Do team members generally know what other team members are working on?
Are fewer than five bugs per month discovered in the team's finished work?
Can any programmer on the team currently build a tested, deployable release with a single command?
Does the team demonstrate its progress to stakeholders at least once per month?
Do programmers use working code to give them information about technical problems?
Do any problems recur more than once per quarter?
Does the team compare their progress to the plan at predefined, time-boxed intervals, no longer than one month apart, and revise their plan accordingly?