The Art of Agile Development: Assess Your Agility
February 26, 2008
The second edition is now available! The Art of Agile Development has been completely revised and updated with all new material. Visit the Second Edition page for more information, or buy it on Amazon.
- Next: Chapter 5: Thinking
- Previous: Go!
- Up: Chapter 4: Adopting XP
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.
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.
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
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
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
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
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
- Next: Chapter 5: Thinking
- Previous: Go!
- Up: Chapter 4: Adopting XP