Agile in metaphores: angle of repose

This is my latest idea for a nice exercise that could be used during an Agile / Scrum or XP training for a development team. You are welcome to copy this idea and use it in your training, especially if you give me the credits :-)

Introduction:
Every loose material has a property known as the angle of repose. It is the angle that is naturally formed when a material is loosely spilled out, for example to be stored:

The task:
Give the development team an amount of loose substance such as salt of sugar and ask them to produce a measurement of the angle of repose of that substance. Then leave the room. Give them a protractor and leave the room.

Conclusions after the task is executed:
When you are back in the room, the engineers will have hopefully measured the angle in the experiment of spilling out the substance and measuring the angle more or less accurately. Explain to them that although a theoretical computation of the angle is possible, it would be extremely complex, compared to simply doing the experiment they have just done.

Then, this metaphore could be extended to cover topics like:

• empiricism as the method for solving (complex) problems (even if this particular is just complicated)
• TDD - experimenting with the production code to see when it passes a test, rather than trying to mentally execute it
• developing a story based on unclear or incomplete knowledge of scope, in order to get feedback, rather than struggling to understand and "lock" all of the story first

Beware of theoretical problems

Anybody who was a change agent or acted as one knows this too well. You meet a development team of 15+ engineers and do an introductory talk on Scrum. Even before you are one third through the talk, there is a question or an interruption from the audience - similar to one of the following examples:

• this is all very interesting, but how it [Scrum] would deal with a situation when half of the team quits their job on one day?
• this may work in an experienced team, but imagine that you have a team where there is just one experienced developer and all others are fresh graduates
• I don't understand why you are against my idea of recording the stand-up meetings; sometimes the amount of input from the team may be too large for the Scrum Master to remember

If you hear that (and it could be on any meeting you talk about change, not necessarily about Scrum), don't engage into discussion.They are all extremely theoretical questions that will NEVER happen in real life. What's more, whatever process / approach / tool is used today, it is most likely unable to resolve these theoretical problems either. As a change agent, you just have to hear it out, but don't begin discussing it.

Code Kata: Crazy letter delivery

Imagine you live in a crazy town inhabited entirely by mathematicians. Each day a postman delivers some letters to the citizens. There are no street names in town, just house numbers. Because the traditional delivery seemed boring to the mathematicians, they invented a kind of game and talked the postman into playing it: the postman changes the original numer of house on a letter to an alternate number (read below how) and delivers the letter to the alternate house. The mathematician that lives in that house knows both the alternate and original house number from the postman. He indulges in the task of converting the original number to the alternate and only when he knows the proper conversion does he deliver the letter to the proper receiver. Example:

Original house number: 139.
Alternate house number: 126

Conversion: 139 - (1 + 3 + 9) = 126; original number minus the sum of its digits.

Another example:

Original house number: 222
Alternate house number: 8

Conversion: 2 * 2 * 2 = 8; digits of original number multiplied.

The task is to write a piece of code that helps to find the conversion, based on the original number, the alternate number and a set of rules. You can choose the rules as you like and extend them gradually. You can start with + and - operations on the original number and its digits. You can take multiplication into account, as in the second example. You can choose to apply division. You can restrict the rules to always use all of the digits or extend them to use any combination of the digits, with or without repetitions. The program may give an exact answer, or simply answer "conversion unknown", in some cases.