The Role of Rules

In the context of the ongoing dialog in the lean/agile community about "defined processes" (in the sense of documented processes with clear guidelines or rules, not necessarily deterministic processes), the following sets of books have come to together to make an impression on me:

• Group 1: The End of Overeating, by David Kessler Strategy and the Fat Smoker, by David Maister Overcoming Organizational Defenses, by Chris Argyris (see also www.actionscience.org)
• Group 2: Software For Your Head, by Tom and Michele McCarthy (see www.mccarthyshow.com) Agile Project Management with Scrum, by Ken Schwaber (see scrum.org)

The books in Group 1 have a common thread which is that knowing how you want to behave is not the same as actually behaving that way. Changing behavior is very hard, particular when that behavior is linked to long standing psychological or physical inclinations. While each of these books offers approaches for implementing behavior change in the domain they are addressing, David Kessler in particular points out that, due to the different parts of the brain involved, creating discrete rules for oneself is much more effective in changing behavior that establishing more abstract objectives.

The books in Group 2 are interesting in that the each provides a set of strict rules and guidelines to be followed in their particular domain. Each has also been criticized as being too prescriptive and too constraining. But the Group 1 books explain that this is precisely why these protocols are effective. This topic also seems related to Bloom's taxonomy of learning and various concepts of mastery levels, where one progresses from learning rules, to applying rules, to teaching rules, to breaking rules, to making rules.

Nokia Test Questions

The following are questions that arose in my department after taking the version of the Nokia Test which has ratings from 0 to 10.

Iterations - Our iterations are roughly one month in length, scheduled a year in advance to end on a Monday in the middle of the month (to avoid holidays and other standing meetings). That works out to 8 iterations of 4 weeks and 4 iterations of 5 weeks during a given year. Is that "variable length"? For those that claim "fixed length", what do they do if the iteration boundary occurs in the middle of a holiday week?

Testing within the Sprint - What does "dedicated QA" mean? Is that a reference to a person or role? If so, is having an individual a Scrum team who is dedicated to testing considered superior to having the work fully distributed? If it's a reference to QA work, what does "dedicated" mean? Also, in scoring this question, can you only came credit for a higher number if you've satisfied all the "good things" implied by lower level questions?

Agile Specification - Is interpolation permitted or encouraged? For example, what about "poor requirements"? Is there a reference for what is meant by "specifications" in this context (and what distinguishes it from "requirements")?

Product Owner - Again, are lower level "good things" required for higher level scores? For example, if development team and ScrumMaster are doing the lion's share of the work in preparing the Product Backlog, the Product Owner is only peripherally involved, but the backlog is clear and estimated before the Sprint Planning meeting, is that still a 5?

Product Backlog - Not really a scoring question, but if "story point" is based on size(effort) and not value, then how is cost per story point a measure of ROI?

Team Disruption - There are lots of potential sources of disruption (e.g. other Scrum teams seeking assistance, support personnel seeking help to restore service for a "down" customer). Is this question not intended to measure those?

Team - Same question about whether/how higher levels depend on lower levels (see below for generalization). What does "necessary competency" mean? Our teams are in a constant state of challenge/growth in terms of their skills relative to a large legacy code base.

Generalized Scoring Question - Each of the scoring elements is expressed as either a "bad thing in at least some respect" or a "good thing" relative to Scrum. My understanding of the intended scoring algorithm is as follows:
* You can't score higher than any "bad thing" which applies to you, even if you satisfy something with a higher number
* You can't score higher than any "good thing" you don't satisfy, even if you satisfy a good thing with a higher number

Is that correct?