Common NonSense

I am very upset when common sense is mentioned during discussions about Scrum and generally about software development. It is usually used in sentences like: "yes, we use Scrum, but we are not erthodox about it, we just use common sense".

Why would I be so angry about it? Isn't it good that people actually use common sense to make decisions? After all, Scrum is also said to be "based on common sense".

This is the question to everyone who claims that the use of common sense is a virtue: what brought you to where you are now? Wasn't that common sense?

• Wasn't that common sense that told you to separate programmers from testers?
• Wasn't that common sense that told you to separate analysts or architects from development team?
• Wasn't that common sense that helped you invent "iteration zero" in which you are excused for not delivering anything useful?
• Wasn't that common sense that helped you invent "hardening sprint" in which you execute all the tests you did not care about over the course of the project?
• I also suspect you used common sense to determine that TDD makes projects too expensive and should be abandoned
• It was probably common sense that whispered to your ear when you named numerous roles in your team, for every member of the team to feel special
• And wasn't it nice when common sense provided you with so simple solution to the problem of an iteration falling into the holiday season? And you just made it one week longer...

Even if somebody else used common sense and made decisions quite opposite to those above, it was your common sense that told you to make these mistaken decisions. And therefore, don't trust your common sense. Talk to people who are wiser and more experienced. Search for options on the web. Learn what solutions people implemented in the industry. But don't trust your common sense.

This post wouldn't be here, if it were not for Michal Rosolowski, whose views on common sense blew my mind. There is a video available with Michal's lightening talk on this subject:

http://vimeo.com/album/1977617/video/44244699

Michael Feathers' visit

In May this year I had the pleasure of hosting Michael Feathers at Motorola Solutions in Krakow. We invited Michael to do a kind of extension, in the form of workshop and a lecture, to his great and well-known book "Working Effectively with Legacy Code".

Michael's skills are very rare as not only is he skilled in teaching the methods of dealing with legacy code, but he also feels comfortable with doing so in C++, in addition to Java and C#, which both are more pervasive among XP professionals.

It was a great experience and I think many of us will remember some of the ideas we learnt during this visit.

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.

Code Kata: toy fleet management

Background: there is an infinite grid with one point selected as a fleet management centre. There is a number (> 1) of cars that move through the grid, one step at a time, only in up, down, left and right directions. The cars periodically send their position on the grid to the management centre.

The task: we are to write a program that accepts coordinates sent by the cars and then can tell us the current total distance travelled by a car.

Points to consider: we assume that the coordinates are send periodically, regardless of the car's movement. Thus, a car may send various series of coordinates that our program must be able to interpret. Tip: the calculated total distance will be an approximation, not an exact value.

Additional functions (to be done as a next step, do not bring it outright into the design): if a car travels away from the management centre farther than N units, the program will signal that fact. Just use any method you wish to signal this, but remember that it should not be annoying, in case a driver took a long trip on the countryside.