Welcome to the The Art of Agile Development website. Here, you'll find a cornucopia of bonus material, such as downloadable posters, behind-the-scenes material, and new insights.

For more, see the table of contents.

 Print

The Art of Agile Development: Assess Your Agility

27 Feb, 2008

in 99 words

Suppose you've been using XP for a few months. How can you tell if you're doing it properly? The ultimate measure is the success of your project, but you may wish to review and assess your approach to XP as well.

This quiz helps you do so. It focuses on five important aspects of agile development. It examines results rather than specific practices, so you can score well even if you've customized XP. It also works if you aren't using XP.

The quiz assesses sources of risk. Your goal should be to achieve the maximum score in each category.

'Assess Your Agility' worksheet

Download this worksheet!

Inside This Section

This section of the book has a self-assessment quiz for your team to take. Sort of like the quizzes you find in fashion magazines, but more sophisticated. (I hope.)

The goal of the quiz isn't to tell you if you're "agile" or not--it's hard enough for a human to do that, let alone something printed on dead trees--but to give you an idea of where you could improve, and what your biggest sources of risk are.

Anyway, as a special treat this week, I'm including the whole quiz online so you and your team can try it. I suggest taking the quiz individually and then graphing all of your answers together, on a single worksheet. The result will not only tell you about opportunities for improving your agile practices, it will also help you see where you have potential misunderstandings on your team.

To take the quiz, answer the questions below. Don't give partial credit for any question, and if you aren't sure of the answer, give yourself zero points. The lowest score identifies your risk, as follows:

  • 75 points or less: immediate improvement required (red)
  • 75 to 96 points: improvement necessary (yellow)
  • 97, 98, or 99: improvement possible (green)
  • 100: no further improvement needed

The point values for the questions come from an algorithm that ensures correct risk assessment of the total score. A 75-point question is not actually 75 times more important than a one-point question--we just had to use such wide variances to get the totals to come out right. Shane and I snuck a little in-joke in there, too, at the risk of getting flamed... see if you can spot it.

The quiz is now online! Thanks to the hard work of Sebastian Hermida, you can take the quiz online, record your results, and share them with your team. Check it out at abetterteam.org.

Note: abetterteam.org comes to us thanks to the hard work and initiative of Sebastian Hermida. My only involvement was to give my blessing and provide a few small suggestions. Please direct kudos and critiques to Sebastian.

Self-Assessment Quiz

Thinking:

Question Yes No XP Practices
Do programmers critique all production code with at least one other programmer? 5 0 PP
Do all team members consistently, thoughtfully, and rigorously apply all of the practices that the team has agreed to use? 75 0 PP, RCA, R
Except for the occasional bad day, are team members focused and engaged at work? 5 0 EW
Are nearly all team members aware of their progress toward meeting team goals? 4 0 IW
Do any problems recur more than once per quarter? 0 5 RCA, R
Does the team improve their process in some way at least once per month? 5 0 R

Collaborating:

Question Yes No XP Practices
Do programmers ever make guesses rather than getting answers to questions? 0 75 XPT
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? 4 0 ST
Do team members generally communicate without confusion? 4 0 ST, UL
Do nearly all team members trust each other? 4 0 XPT, ST
Do team members generally know what other team members are working on? 1 0 SUM
Does the team demonstrate its progress to stakeholders at least once per month? 4 0 ID, R
Does the team provide a working installation of its software for stakeholders to try at least once per month? 1 0 ID
Are all important stakeholders currently happy with the team's progress? 3 0 R, ID, RCI
Do all important stakeholders currently trust the team's ability to deliver? 3 0 T, R

Releasing:

Question Yes No XP Practices
Can any programmer on the team currently build and test the software, with an unambiguous success/fail result, with a single command? 25 0 TMB
Can any programmer on the team currently build a tested, deployable release with a single command? 5 0 TMB
Do all team members use version control for all project-related artifacts that aren't automatically generated? 25 0 VC
Can any programmer build and test the software on any development workstation with nothing but a clean check-out from version control? 25 0 VC
When a programmer gets the latest code, is he nearly always confident that it will build successfully and pass all of its tests? 5 0 CI
Do all programmers integrate their work with the main body of code at least once per day? 4 0 CI
Does the integration build currently complete in fewer than ten minutes? 4 0 TMB
Do nearly all programmers share a joint aesthetic for the code? 1 0 CS
Do programmers usually improve the code when they see opportunities, regardless of who originally wrote it? 4 0 CCO, R
Are fewer than five bugs per month discovered in the team's finished work? 1 0 NB

Planning:

Question Yes No XP Practices
Do nearly all team members understand what they are building, why they're building it, and what stakeholders consider success? 25 0 V
Do all important stakeholders agree on what the team is building, why, and what the stakeholders jointly consider success? 25 0 V
Does the team have a plan for achieving success? 4 0 RP, FR
Does the team regularly seek out new information and use it to improve their plan for success? 2 0 RP
Does the team's plan incorporate the expertise of both business people and programmers, and do nearly all involved agree the plan is achievable? 3 0 PG
Are nearly all of the line items in the team's plan customer-centric, results-oriented, and order-independent? 4 0 S
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? 4 0 I
Does the team make delivery commitments prior to each time-boxed interval, then nearly always deliver on those commitments? 4 0 I, DD, S, E
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? 0 25 DD
Does the team nearly always deliver on its release commitments? 3 0 RM

Developing:

Question Yes No XP Practices
Are programmers nearly always confident that the code they've written recently does what they intended it to? 25 0 TDD
Are all programmers comfortable making changes to the code? 25 0 TDD
Do programmers have more than one debug session per week that exceeds ten minutes? 0 3 TDD
Do all programmers agree that the code is at least slightly better each week than it was the week before? 25 0 R, IDAA
Does the team deliver customer-valued stories every iteration? 3 0 I, IDAA
Do unexpected design changes require difficult or costly changes to existing code? 0 3 SD
Do programmers use working code to give them information about technical problems? 1 0 SS
Do any programmers optimize code without conducting performance tests first? 0 3 PO
Do programmers ever spend more than an hour optimizing code without customers' approval? 0 3 PO
Are on-site customers rarely surprised by the behavior of the software at the end of an iteration? 4 0 IR
Is there more than one bug per month in the business logic of completed stories? 0 3 CT
Are any team members unsure about the quality of the software the team is producing? 0 1 ET, ID, RCI