The quiz contains 5 sections with ~10 questions each. If you are unsure of the answer, just respond 'No' and take no partial credit!
Remember: it's the conversation that matters

Thinking

Sometimes the biggest gains in productivity come from stopping to think about what you're doing, why you're doing it, and whether it's a good idea. This section of the quiz reflects on the following concepts:

Energized work acknowledges that developers do their best, most productive work when they're energized and motivated.
An informative workspace gives the whole team more opportunities to notice what's working well and what isn't.
Pair programming doubles the brainpower available during coding, and gives one person in each pair the opportunity to think about strategic, long-term issues
Root-cause analysis is a useful tool for identifying the underlying causes of problems and preventing the same mistakes in the future.
Retrospectives provide a way to analyze and improve the entire development process.

Do programmers critique all production code with at least one other programmer?: Yes; No

Do all team members consistently, thoughtfully, and rigorously apply all the practices that the team has agreed to use?: Yes; No

Are team members generally focused and engaged at work?: Yes; No

Are nearly all team members aware of their progress toward meeting team goals?: Yes; No

Do any problems recur more than once per quarter?: Yes; No

Does the team improve its process in some way at least once per month?: Yes; No

Collaborating

Collaboration is essential for a project to succeed. How is your team collaborating efficiently and effectively?

Trust is essential for the team to thrive.
Sitting together leads to fast, accurate communication.
Real customer involvement helps the team understand what to build.
An ubiquitous language helps team members understand each other.
Stand-up meetings keep team members informed.
Coding standards provide a template for seamlessly joining the team's work together.
Iteration demos keep the team's efforts aligned with stakeholder goals.
Reporting helps reassure the organization that the team is working well.

Do programmers ever make guesses rather than getting answers to questions?: Yes; No

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?: Yes; No

Do team members generally communicate without confusion?: Yes; No

Do nearly all team members trust each other?: Yes; No

Do team members generally know what other team members are working on?: Yes; No

Does the team demonstrate its progress to stakeholders at least once per month?: Yes; No

Does the team provide a working installation of its software for stakeholders to try at least once per month?: Yes; No

Are all important stakeholders currently happy with the team's progress?: Yes; No

Do all important stakeholders currently trust the team's ability to deliver?: Yes; No

Releasing

It's often easy to underestimate how long it takes to take software into production. The longer we wait, the harder it becomes. A product that is difficult to release loose value and reduce our opportunities to react to the market needs.

'done done' ensures that completed work is ready to release
No bugs allows you to release your software without a separate testing phase.
Version control allows team members to work together without stepping on each other's toes.
A ten-minute build creates a tested release package in under 10 minutes.
Continuous integration prevents a long, risky integration phase.
Collective code ownership allows the team to solve problems no matter where they may lie.

Can any programmer on the team currently build and test the software, and get an unambiguous success/fail result, using a single command?: Yes; No

Can any programmer on the team currently build a tested, deployable release using a single command?: Yes; No

Do all team members use version control for all project-related artifacts that aren't automatically generated?: Yes; No

Can any programmer build and test the software on any development workstation with nothing but a clean check-out from version control?: Yes; No

When a programmer gets the latest code, is he nearly always confident that it will build successfully and pass all its tests?: Yes; No

Do all programmers integrate their work with the main body of code at least once per day?: Yes; No

Does the integration build currently complete in fewer than 10 minutes?: Yes; No

Do nearly all programmers share a joint aesthetic for the code?: Yes; No

Do programmers usually improve the code when they see opportunities, regardless of who originally wrote it?: Yes; No

Are fewer than five bugs per month discovered in the team's finished work?: Yes; No

Planning

The larger your project becomes, the harder it is to plan everything in advance. The more chaotic your environment, the more likely it is that your plans will be thrown off by some unexpected event. Yet in this chaos lies opportunity.

Vision reveals where the project is going and why it's going there.
Release Planning provides a roadmap for reaching your destination.
The Planning Game combines the expertise of the whole team to create achievable plans.
Risk Management allows the team to make and meet long-term commitments.
Iteration Planning provides structure to the team's daily activities.
Slack allows the team to reliably deliver results every iteration.
Stories form the line items in the team's plan.
Estimating enables the team to predict how long its work will take.

Do nearly all team members understand what they are building, why they're building it, and what stakeholders consider success?: Yes; No

Do all important stakeholders agree on what the team is building, why, and what the stakeholders jointly consider success?: Yes; No

Does the team have a plan for achieving success?: Yes; No

Does the team regularly seek out new information and use it to improve its plan for success?: Yes; No

Does the team's plan incorporate the expertise of business people as well as programmers, and do nearly all involved agree the plan is achievable?: Yes; No

Are nearly all the line items in the team's plan customer-centric, results-oriented, and order independent?: Yes; No

Does the team compare its progress to the plan at predefined, timeboxed intervals, no longer than one month apart, and revise its plan accordingly?: Yes; No

Does the team make delivery commitments prior to each timeboxed interval, then nearly always deliver on those commitments?: Yes; No

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?: Yes; No

Does the team nearly always deliver on its release commitments?: Yes; No

Developing

Programmers are often called 'Developers' but in reality everyone on the team is part of the development effort. These are nine practices that keep the code clean and allow the entire team to contribute to development:

Incremental Requirements allows the team to get started while customers work out requirements details.
Customer Tests help communicate tricky domain rules.
Test-Driven Development allows programmers to be confident that their code does what they think it should.
Refactoring enables programmers to improve code quality without changing its behavior.
Simple Design allows the design to change to support any feature request, no matter how surprising.
Incremental Design and Architecture allows programmers to work on features in parallel with technical infrastructure.
Spike Solutions use controlled experiments to provide information.
Performance Optimization uses hard data to drive optimization efforts.
Exploratory Testing enables testers to identify gaps in the team's thought processes.

Are programmers nearly always confident that the code they've written recently does what they intended it to?: Yes; No

Are all programmers comfortable making changes to the code?: Yes; No

Do programmers have more than one debug session per week that exceeds 10 minutes?: Yes; No

Do all programmers agree that the code is at least slightly better each week than it was the week before?: Yes; No

Does the team deliver customer-valued stories every iteration?: Yes; No

Do unexpected design changes require difficult or costly changes to existing code?: Yes; No

Do programmers use working code to give them information about technical problems?: Yes; No

Do any programmers optimize code without conducting performance tests first?: Yes; No

Do programmers ever spend more than an hour optimizing code without customers' approval?: Yes; No

Are on-site customers rarely surprised by the behavior of the software at the end of an iteration?: Yes; No

Is there more than one bug per month in the business logic of completed stories?: Yes; No

Are any team members unsure about the quality of the software the team is producing?: Yes; No

Name this quiz, so you can identify it later: Optional, but useful if you want to tag this exercise to a special retrospective, team, etc...

Hosted on a cloud | Managed by Sebastian Hermida | Feedback | Quiz by The Art of Agile Development