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