Master Mind Confused Mind Agile Mind

Master Mind

You must try to guess a hidden combination of colored pegs.

You fill a line of colored pegs.

Your opponent checks your line and answers. The answer indicates how many pegs there are in your line that are of the correct color and at correct location, and how many pegs are of a correct color but not correctly located. You continue until the combination is revealed.

  11111 ? (1,0)
  12222 ? (0,1)
  21333 ? (1,1)
  23122 ? (1,1)

(see e.g. http://www.lizardpoint.com/fun/mastermind/mindmain.html , http://thinks.com/java/mastermind/mastermind.htm , http://mathworld.wolfram.com/Mastermind.html )

Confused Mind

Same objective.

You fill several lines of colored pegs.

Your opponent checks your lines and answers. The answer indicates how many pegs there are in your whole block that are of the correct color and at correct location, and how many pegs in your whole block are of a a correct color but not correctly located. You continue until the combination is revealed.

  11111 
  12222 
  21333 
  23122 ? (3,3)

Are you talking about what http://mathworld.wolfram.com/Mastermind.html calls the "static problem", or are you talking about trying to guess a combination of 20 pegs (rather than the ususual combination of 5 pegs) ?

static master mind:

Exactly like normal Master Mind: Each time you fill in a row, your opponent writes down the 2 numbers next to each row. Except: your opponent covers those 2 numbers with his hand until you've done 5 rows, then reveals all 5 rows of numbers all-at-once.

Agile Mind

Same objective.

You place one peg.

Your opponent checks what you just put and answers. The answer says 1 if the peg is correct and well located, 0 if the peg is not in correct position, nothing is the peg doesn't belong to the combination. You continue until etc.

  1.... ? 0
  2.... ? 
  .1... ? 0
  ..1.. ? 1
  3.....? 1

At which game would you be sure to win faster if each answer from the opponent took :

4 hours ?
15 minutes ?
2 seconds ?

--ChristopheThibaut

I remember playing this game with the little plastic pegs in elementary school. Quite often the person who made up the initial "secret" combination (Is there a name for this player, the way "white" and "black" are the names of chess players ?) would forget which column was the "correct color and location" and which column merely indicated "other correct colors but not correct location", and swap the two responses. I wonder if thinking about "sometimes makes errors" is useful. Say your opponent immediately gave you a "possibly incorrect" answer in 2 seconds, but if you let him think a little longer he would give you a "correct" answer in 30 seconds ... what sort of strategy would you use ?

That's a lovely illustration, actually. Add these variations:

Predictive Mind

Same objective.

You place all the pegs. Incidentally,

The game is limited to combinations of pegs that can be expressed unambiguously by a formula.
You are given the formula.

Your opponent checks what you just put and answers.

What if you have a partial formula?

Collaborative Mind

Same objective.

Your "opponent" who provides feedback is actually a partner who benefits if you solve the puzzle.
You can choose whatever game rules you like, as long as success is you producing a pattern initially unknown to you, but known to your partner.

What is your strategy?

If feedback cycles are expensive.
If they aren't.
If you understand the forumula.
If you don't.
If you don't know whether you understand or trust the formula.
If you can communicate with your partner about the pattern outside the forumula and feedback.
If you can communicate with your partner about the rules or strategy.
If you don't know whether you understand or trust your partner.

The discussions around the efficiencies of prediction vs. iteration in software methodologies are often confounded because the conversations conflate three drivers: cost of experiments, what is known a-priori, and the effectiveness of derivation. The conversations also often ignore the other moves available to the players - the ones outside the mechanics of the game being played. Finally, methodology conversations often conflate arguments about "efficiency" with discussions of production processes and discussions of effectiveness. By analogy, we know that some SortingAlgorithms are somewhat less efficient than others, but more predictable. Sometimes that predictability is valuable enough that less efficient is more effective. (Programming a RealTime system often forces us to use algorithms that are technically less "efficient", rather than "efficient" algorithms that have worse "worst-case bounds".)

Discussions of "agile" software development also often conflate agility of the system being built with agility in the approaches and tools being used. AlistairCockburn has articulated this as "agile" and "adaptive." (Apologies if that is not his current framing. I plead limited bandwidth.) Many people do not make the distinction.

Software is so broad in the problems we apply it to that any discussion of software methodologies ought to account for variations at least this broad in the problems that methodologies address.

see MovingTowardsSellingAgility, BigBangTesting