Agile Testing Days Website
On Monday evening of the Agile Testing Days all speakers were invited to go to lunch from the organizators. I had the dear honor to sit next to Tom Gilb with Mary & Tom Poppendieck directly facing. Though I was not able to follow the complete conversation in-depth, I was able to get most of their points. Unfortunately I didn’t take notes on everything discussed there, but I denoted two things on the next day from that conversation.
Lunch-serving
At lunch-time on Monday the hotel had prepared lunch for all the participants. There was a long, long queue at one end of the buffet, while there was a second serving-point near to be unused. All participants just queued up on one side of the buffet. Mary Poppendieck elaborated this queueing in the evening at dinner. She raised the point, that the queueing was rather inefficient. There was also a reason why there was a queue. The way the buffet was built up, was optimized for food-serving. The queue got longer and longer, since the buffet was apparently not optimized for getting people something to eat. When she had said this, I noticed that she had just applied Lean-thinking to food-serving. The local optimization of the buffet arrangement lead to the drawback of the queue for getting people something to eat. Since serving food and getting people something to eat are contradicting goals, there was a queue rising for the unoptimized of the two: getting people something to eat. Though, this does not mean that a lunch- or dinner-buffet is something bad, this simply means, that serving food in a buffet manner is cheaper for the owner of the restaurant. Having your food served by waitresses on the other is more confortable for you getting something to eat. So, you should ask yourself before going to lunch or dinner, whether or not it’s more important that you get something to eat rather than spending more money, or if saving money is more important to you than getting something to eat. On another viewpoint you must decide whether you want to develop software in your business or whether you want to sell software to your customers. Viewing things at this system level makes your optimization strategy clear. When thinking of software development as flow of decisions in a system, you will realize that piling up decisions in your software in order to simply develop a lot of software, is a really bad thing. By filling in the decisions from the business-perspective via real customer requirements might be a better strategy, if you don’t do product development for the mass-market. In the latter case you need to have a good product management in place in order to bring these business-decisions into the software development team.
Problem-solving
Tom Poppendieck referred often to problem-solving. Since I was reminded of the problem-solving approach from Jerry Weinberg, I felt urged to ask what his understanding of problem-solving is. He pointed me out, that problem-solving starts with where you would like to be. If you have identified where this is, you can explore where you are currently in reference to that place where you want to be. The gap between the two is the problem, you actually need to solve in order to reach where you want to be. Let me try to elaborate an example for this. Suppose you want to reach the moon. Then you have identified where you actually want to be. By identifiying where you are now (California, Berlin, Jupiter, Mars, Moon, …), you get to know what the difference between your target and your current position is. If you’re already on the moon, you likely won’t have a problem. If you are on any other location as the moon itself, you have the distance (and maybe the missing atmosphere and some gravitational forces) between your current position and your target – the moon – as your problem. This is what you need to solve. As I recently learned, President Kennedy pointed this one out in the early 60’s when setting the target to get the first human on the moon by the end of that decade.
