1 Iterative Development and Adaptation

1. Does your project deliver useful content for business review every 1-4 weeks? [Yes +1, No -1]
2. Generally do you feel the Change Management Process that is in place tends to: A) Encourage worthwhile change submissions [+1] B) Suppress most change submissions [-1]
3. Is the backlog (list of outstanding stories, features) reprioritized based on an updated appraisal of the project at each iteration boundary? [Yes +1, No 0]
4. Are retrospectives held after every release and mini-retrospectives held after every iteration to reflect on what is working and opportunities for improvement? [Yes +1, No 0)
5. Does the team regularly challenge their own, and the companies’ processes looking to minimize waste and generate efficiencies? [Yes +1, No 0]

2 Value, Stakeholder Collaboration, and Planning Concepts

1. Is planning of work based on delivering business value above other factors? [Yes +1, No 0]
2. Choose the statement that best describes your long term planning: A) Features (stories, requirements) for future iterations are planned out in detail and rarely change [0]. B)  Features for future iterations are planned out with little detail and frequently change [+1]
3. Are change requests and defect remediation work traded off against planned features for future iterations in collaboration with the customers (transparency)? [Yes +1, No 0]
4. Are customers and business representatives present, or at least invited to, all team estimation sessions? [Yes +1, No -1]
5. Is refactoring encouraged via a little-and-often approach and larger refactorings prioritised with the customer? [Yes +1, No -1]

3 Empowered Teams and Rewards

1. Choose the statement that best describes your Work Assignment: A) The project manager assigns the bulk of the project tasks to team members [-1]. B) The team members volunteer for the bulk of the project tasks [+1]
2. Are individuals empowered to make local decisions about how work should be organized and undertaken? [Yes +1, No 0]
3. Choose the statement that best describes your Decision Making: A) The project manager makes the bulk of the project decisions [-1]. B) The team in conjunction with the customer and PM makes the bulk of the project decisions [+1]
4. Does the team regularly reflects back on the work done and offer sincere thanks to key contributors [Yes, +1, No -1]
5. Does the team decide how to split rewards and bonuses as it sees fit between its members? [Yes +1, No 0]

4 Controls and Practices

1. Are the best practices for continuous integration and automated tested encouraged, rewarded, and in place on the project? [Yes all +1, Some 0, None -1]
2. Is process and documentation fiercely kept to a “barely sufficient” level by, for instance using the: “Ask Why?” five times guideline for documentation (Yes +1, “What are you on about?” -1]
3. Is the primary reporting metric for tracking progress feature based, such as stories complete verses stories remaining, burn up graphs, or cumulative flow diagrams? [+1] Or, is it progress against a baselined plan such as percent complete or traditional earned value analysis? [-1]
4. Do the team members have an open work environment that supports collaboration and conversation? [Yes +1, No -1]
5. Are metrics and project information displayed prominently via big visible charts, or information radiators for all stakeholders to see? [Yes +1, No -1]

5 Context and Uncertainty

1. Choose the statement that best describes how you determined Iteration lengths: A) Based on project factors (size, complexity) and organizational factors (business practicalities) [+1]. B) We stick with 30 days, because Ken told us to [0]
2. How do you assess project suitability for agile practices? A) We apply a suitability filter or assessment process [+1]. B) We just always use Agile methods as they are inherently better [0]
3. How is project team size selected? A) based on the available people [-1] B) based on optimal team sizes and decomposition of project objectives into practical chunks [+1]
4. How are project tools selected? A) Based on the projects needs with a preference for simple tools where possible to engage the most stakeholders [+1], B) Based more on company standards with a preference for shiny new tools and developer coolness factor. [-1]
5. How are other factors like system criticality, requirements volatility, team experience, and testing effort factored into how processes are adopted? A) We use XP/Scrum/whatever so it’s all covered by the method, we just need to focus on the practices [-1]. B) They all play a part in selecting and tailoring the processes we apply. [+1]

Facetious Bonus Marks

1. Deduct 1 point for each PMP certified member on the project
2. Deduct 1 point if the PMBOK Guide is more actively referenced than agile books

Quick Results
Total your scores and look up your agile project management rating below:

Over 23: Uber-Agile - stop drinking the cool-aid and get real! Or, if you truly are this agile send me an email [email protected] and I will profile your team on my blog.
19 - 23: Good agile adoption and application – You are masters of your domain and slave to no blind process. You guys know your stuff and practise effective agile project management.
13 - 18: Limited agile adoptions – Welcome to no-mans land, some agile ideas are in place, but many of your practices are not agile (yet).
6 - 12: Not particularly agile – Watch out, your “process police” might be watching you visit an Agile site! Some agile practices may be in use, but perhaps more by accident than deliberate intention.
0 - 5: Not agile – your processes are handed down from Genghis Khan and woe forbid anyone daring to consider updating them. Standards replace the need to think and workers are robotic process followers.
Minus scores – Wow, is this for real? Send me an email and I’ll profile your team too! How a company can keep going with such a lack of team empowerment and recognition is worth investigating.

Detailed Analysis
Download the spreadsheet and enter your scores for each category to produce a radar chart of your agile project management adoption. Congratulate your team for high ranking categories and look for your weak areas to focus team effort upon.

Download apm_test.xls

In the example above, the project scores well on “1 Iterative Development & Adaptation” and “5 Context & Uncertainty”, but not so well on “3 Empowered Teams & Rewards”. Plug in your own numbers and see how you rate.

Important Disclaimer
This quiz is for fun and while based on sound categorization, the idea of attempting to quantify adherence to adaptive and context-specific agile practices is at best suspect, and at worst an oxymoron. The extent to which it can be used objectively is to identify broad areas of agile project management that are well adopted, and others that are not so well adopted.

The questions are leading and answers can be subjective. Remember that “Figures lie and liars figure” and as Albert Einstein observed: “Not everything that can be counted counts, and not everything that counts can be counted” so don’t place too much emphasis on it.

Background behind the Quiz
The categories and questions used for the quiz were checked for alignment and coverage with the following agile sources:

The Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Scott Ambler’s definition of agile projects: “Agile is an iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner with "just enough" ceremony that produces high quality software which meets the changing needs of its stakeholders.”

Ken Schwaber’s definition of agile projects: Iterative, Incremental, Self-Organizing, And Emergence

The APLN’s Declaration Of Interdependence (DOI):

• We increase return on investment by making continuous flow of value our focus.
• We deliver reliable results by engaging customers in frequent interactions and shared ownership.
• We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
• We improve effectiveness and reliability through situationally specific strategies, processes and practices.

And the APLN’s 6 focus areas:
Value, Customers, Teams, Individuals, Context, Uncertainty

Update

Following the publication of this quiz. Simon Baker from Think Box contacted me to describe their Uber Agile score. The text below is from Simon:

To summarise how we work, here's a link to one article on my blog:
www.think-box.co.uk/blog/2006/12/heres-content-of-presentation-i-almost.html

I've included your headings/questions, the scores for each, some brief justification/explanation and some further blog links that add more detail.

1 Iterative Development and Adaptation

1. Does your project deliver useful content for business review every
1-4 weeks? +1

We conduct an iteration review at the end of every week-long iteration.
And we put live every iteration’s accepted deliverables.

2. Generally do you feel the Change Management Process that is in place tends to:
A) Encourage worthwhile change submissions +1
B) Suppress most change submissions

Everything is captured on an index card and stored in Scrum’s Product Backlog. Defects are captured on pink index cards and prioritised along with everything else. Our backlog evolves using adaptive planning techniques taking cards from a vision to goal/s to epic/s to user stories to running tested stories.

3. Is the backlog (list of outstanding stories, features) reprioritized based on an updated appraisal of the project at each iteration boundary? +1

Yes, in fact the backlog stories not in the current iteration may be reprioritised more often than every iteration.

4. Are retrospectives held after every release and mini-retrospectives held after every iteration to reflect on what is working and opportunities for improvement? +1

Yes. We hold heartbeat retrospectives after every week-long iterations which last for 1 hour. And we hold larger retrospectives after every quarter, which involve more stakeholders.

www.think-box.co.uk/blog/2006/10/timeline-retrospective.html
www.think-box.co.uk/blog/2006/11/another-heartbeat-retrospective.html
www.think-box.co.uk/blog/2006/09/retrospectives-action-begets-action.html

5. Does the team regularly challenge their own, and the companies’
processes looking to minimize waste and generate efficiencies? +1

Absolutely and this comes out of the retrospective, captured as actions to take into the next iteration. We write these on index cards and add them to the product backlog.

2 Value, Stakeholder Collaboration, and Planning Concepts

1. Is planning of work based on delivering business value above other factors? +1

Definitely. Our product owner comes prioritises the product backlog by business value and the work we commit to during the iteration planning game is ordered and accomplished in order of business value.

2. Choose the statement that best describes your long term planning:
A) Features (stories, requirements) for future iterations are planned out in detail and rarely change
B) Features for future iterations are planned out with little detail and frequently change +1

We use adaptive planning to evolve the product backlog. As before, things start out as visions which evolve to goal/s then to epics then user stories then running tested stories (code + tests). Everything is captured on index cards and are published on walls in the bull-pen. The product owner is responsible (but collaborates with scrum team) to evolve the product backlog items into more detail as they approach release and iteration planning boundaries, i.e. as an items business value increases it is likely split into smaller more focused user stories. Typically, when a story is planned into a week-long iteration it is between 0.5 and 3 ideal pair days in duration.

www.think-box.co.uk/blog/2006/02/user-stories-part-1-what-is-user-story.html
www.think-box.co.uk/blog/2006/02/user-stories-part-2-adaptive-planning.html
www.think-box.co.uk/blog/2006/02/user-stories-part-3-using-spikes-to.html
www.think-box.co.uk/blog/2006/09/planning-board-and-user-story-cards.html

3. Are change requests and defect remediation work traded off against planned features for future iterations in collaboration with the customers (transparency)? +1

Yes. Defects occurring within an iteration, if time permits, are always fixed immediately. If they are deemed too low value to fix and more higher value stories are still outstanding then they may be descoped and added to the product backlog for prioritisation by the product owner.
Change requests are infrequent the scrum team collaborates intensely with the product owner as a story is developed using vertical slicing.
However, when we cannot accommodate a late change to a developed user story, the change is captured as another story and added to the product backlog for prioritisation by the product owner.

4. Are customers and business representatives present, or at least invited to, all team estimation sessions? +1

The product owner is always present at the planning games and iteration reviews. Indeed they present the user stories to the team in the planning game and then answer lots of questions about the details of the stories (which are then captured as acceptance tests on the back of the cards). The product owner accepts/rejects delivered stories in the review. We’ve never had a rejection because the product owner sees the story evolve through vertical slicing during development.

5. Is refactoring encouraged via a little-and-often approach and larger refactorings prioritised with the customer? +1

Yes. We use incremental design with refactoring to constantly improve the overall system’s design.

3 Empowered Teams and Rewards

1. Choose the statement that best describes your Work Assignment:
A) The project manager assigns the bulk of the project tasks to team
members
B) The team members volunteer for the bulk of the project tasks +1

Team members volunteer for story ownership at the daily scrum and then
pair off to program. In the scrum they state everything in terms of
commitments to the team and hold one another accountable to those
commitments.

www.think-box.co.uk/blog/2006/05/daily-stand-up-scrum-meeting.html

2. Are individuals empowered to make local decisions about how work
should be organized and undertaken? +1

3. Choose the statement that best describes your Decision Making:
A) The project manager makes the bulk of the project decisions
B) The team in conjunction with the customer and PM makes the bulk of
the project decisions +1

Pairs of team members make local decisions for the stories they own. If
they require wider input they call a team time-out. Other decisions
affecting the team are made by the team through consensus (using a
gradient of agreement), e.g. those decisions made in the retrospectives.

www.think-box.co.uk/blog/2006/04/consensus-decision-making.html
www.think-box.co.uk/blog/2006/07/calling-timeout.html

4. Does the team regularly reflects back on the work done and offer
sincere thanks to key contributors +1

Yes. We do this as routine in the heartbeat retrospectives.

www.think-box.co.uk/blog/2006/10/timeline-retrospective.html
www.think-box.co.uk/blog/2006/11/another-heartbeat-retrospective.html
www.think-box.co.uk/blog/2006/09/retrospectives-action-begets-action.html

5. Does the team decide how to split rewards and bonuses as it sees fit
between its members? +1

Yes. As contractors we don’t receive rewards from our clients. We reward
ourselves for our success with team events/nightsout. Everyone
contributes equally.

4 Controls and Practices

1. Are the best practices for continuous integration and automated
tested encouraged, rewarded, and in place on the project? +1

Continuous integration is performed with cruisecontrol. We run various
metrics over the code base with a plethora of alarms for different
situations, e.g. coverage <85%. People who break the build get to wear
silly hats. Breaking the build is a no-no. We use junit, jsunit,
selenium and FIT for automated unit and acceptance tests. We are fully
test-driven.

www.think-box.co.uk/blog/2006/02/ten-minute-build-continuous.html
http://www.think-box.co.uk/blog/2006/11/making-room-for-big-visible-screen.html
http://www.think-box.co.uk/blog/2006/10/silly-hats-for-failing-build.html

2. Is process and documentation fiercely kept to a “barely sufficient”
level by, for instance using the: “Ask Why?” five times guideline for
documentation +1

We strive to make the code communicate the programmers intent. We only
use code comments to communicate the ‘why’. Any other documentation is
captured ona wiki. Requirements are captured as user stories on index
cards. There is no other documentation necessary.

3. Is the primary reporting metric for tracking progress feature based,
such as stories complete verses stories remaining, burn up graphs, or
cumulative flow diagrams? +1
Or, is it progress against a baselined plan such as percent complete or
traditional earned value analysis?

We use burn-up charts to track running tested stories (done) and effort
remaining to get the stories (we committed to in the planning game for
the iteration) to done.

http://www.think-box.co.uk/blog/2006/07/im-burning-up.html
http://www.think-box.co.uk/blog/2006/11/drawing-burn-up-charts-on-overlays.html

4. Do the team members have an open work environment that supports
collaboration and conversation? +1

We have a custom designed bull-pen with lots of information radiators,
games and workstations that facilitate pair programming. The whole
environment is designed to promote communication and minimise
communication drafts from elsewhere. Everyone in the team is located
within the bull-pen.

http://www.think-box.co.uk/blog/2006/07/bullpen.html
http://www.think-box.co.uk/blog/2006/11/settling-into-new-bullpen.html

5. Are metrics and project information displayed prominently via big
visible charts, or information radiators for all stakeholders to see? +1

Yes. They are drawn on 4-feet whiteboards.

http://www.think-box.co.uk/blog/2006/07/im-burning-up.html
http://www.think-box.co.uk/blog/2006/11/drawing-burn-up-charts-on-overlays.html

5 Context and Uncertainty

1. Choose the statement that best describes how you determined Iteration
lengths:
A) Based on project factors (size, complexity) and organizational
factors (business practicalities) +1
B) We stick with 30 days, because Ken told us to

We use 1-week iterations because we want to deliver working software and
business value to production as often as possible and 1-week maintains a
tight rhythm and excellent focus. 30 days is too long to maintain focus
and often results in a tail-end crunch.

2. How do you assess project suitability for agile practices?
A) We apply a suitability filter or assessment process
B) We just always use Agile methods as they are inherently better 0

We are an agile team and we do it very well. We only take projects that
can be done using a combination of scrum and xp.

3. How is project team size selected?
A) based on the available people
B) based on optimal team sizes and decomposition of project objectives
into practical chunks +1

We have 3 teams of 8, although people are encouraged to swap between the
team every iteration to promote the spread of knowledge. We’ve tried
many different sizes and tuned them through the retrospective process.

4. How are project tools selected?
A) Based on the projects needs with a preference for simple tools where
possible to engage the most stakeholders +1
B) Based more on company standards with a preference for shiny new tools
and developer coolness factor.
We avoid pay-through-the-nose tools that are heavyweight. We opt for
simple tools which are often open-source. We modify them when we need to
and contribute the changes back to the community. The key is to be
lightweight, performing and not be tied to technology platforms when it
can be avoided.

5. How are other factors like system criticality, requirements
volatility, team experience, and testing effort factored into how
processes are adopted?
A) We use XP/Scrum/whatever so it’s all covered by the method, we just
need to focus on the practices
B) They all play a part in selecting and tailoring the processes we
apply. +1

Adaptation of how we apply practices is key to our success and is the
primary goal of all our retrospectives. What is also key is that our
adaptation does not compromise our agility by diluting the principles
and values by which we live.

http://www.think-box.co.uk/blog/2006/11/constructive-disruption-and.html

Many thanks to Simon for taking the time to document their process and share these clear explanations.