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!
Do nearly all team members trust each other?
Do team members generally know what other team members are working on?
Are programmers nearly always confident that the code they've written recently does what they intended it to?
Do programmers use working code to give them information about technical problems?
Can any programmer on the team currently build a tested, deployable release with a single command?
Do all programmers agree that the code is at least slightly better each week than it was the week before?
Does the integration build currently complete in fewer than ten minutes?
Are any team members unsure about the quality of the software the team is producing?
Does the team have a plan for achieving success?
Are all important stakeholders currently happy with the team's progress?
Does the team's plan incorporate the expertise of both business people and programmers, and do nearly all involved agree the plan is achievable?
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?
Are nearly all of the line items in the team's plan customer-centric, results-oriented, and order-independent?
Does the team make delivery commitments prior to each time-boxed interval, then nearly always deliver on those commitments?
When a programmer gets the latest code, are they nearly always confident that it will build successfully and pass all of its tests?
Are on-site customers rarely surprised by the behavior of the software at the end of an iteration?
Do unexpected design changes require difficult or costly changes to existing code?
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 nearly all team members aware of their progress toward meeting team goals?
Do any programmers optimize code without conducting performance tests first?
Does the team provide a working installation of its software for stakeholders to try at least once per month?
Except for the occasional bad day, are team members focused and engaged at work?
Do programmers ever spend more than an hour optimizing code without customers' approval?
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?
Do programmers critique all production code with at least one other programmer?
Does the team improve their process in some way at least once per month?
Does the team nearly always deliver on its release commitments?
Do any problems recur more than once per quarter?
Do nearly all team members understand what they are building, why they're building it, and what stakeholders consider success?
Can any programmer build and test the software on any development workstation with nothing but a clean check-out from version control?
Are all programmers comfortable making changes to the code?
Does the team regularly seek out new information and use it to improve their plan for success?
Do all programmers integrate their work with the main body of code at least once per day?
Can any programmer on the team currently build and test the software, with an unambiguous success/fail result, with a single command?
Are fewer than five bugs per month discovered in the team's finished work?
Do programmers usually improve the code when they see opportunities, regardless of who originally wrote it?
Do programmers ever make guesses rather than getting answers to questions?
Do all team members use version control for all project-related artifacts that aren't automatically generated?
Does the team deliver customer-valued stories every iteration?
Does the team demonstrate its progress to stakeholders at least once per month?
Do all important stakeholders agree on what the team is building, why, and what the stakeholders jointly consider success?
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?
Do programmers have more than one debug session per week that exceeds ten minutes?
Do all important stakeholders currently trust the team's ability to deliver?
Do nearly all programmers share a joint aesthetic for the code?
Is there more than one bug per month in the business logic of completed stories?