Today, while starting up our fourth iteration, we again work with our examples. Our coach, Jocke Holm, is now stepping back more an more, enabling us to take more and more control. The situation is similar to being the kid learning how to walk. It is so nice to be carried around all the time but you at the same time crave the freedom of making it on your own. I salute Jocke for making it a smooth ride for us: it is not easy seeing your kids fall and hurt themselves but the hurt they feel if you haven’t allowed them to doing so under controlled situations is so much harder.
This time I had prepared myself and actually written something of a skeleton for an example. Jocke told me not to show it straight away and this was a good thing: I new some of the tweaks I wanted to catch but I still wanted to see if the guys came to the same conclusions as I did.
I then presented the guys to two of our new personas which we have developed at TUI Nordic. We have more personas but these two have very different objectives and behaviors when consuming the services we are developing for them. Together we just made some quick notations of their different needs and then we headed for the examples.
One of the guys started writing about the happy scenario and when we felt comfortable about this, I started adding some of the complexities which are necessary to exemplify the features. The guys ended up with a semi-similar example compared to my first draft. The differences were important and good.
It’s a good thing for me to do some initial drafting before discussing with the team since I then have thought of some of the most important details but it was also good to start from scratch while working together. I actually found that the scenario was not focusing on the thing I had expected and this is not the first time I find myself in this situation while working with examples. The methodology really turns my head sometimes, making me see what the real issue is instead of assuming that the problem is how the wanted feature is as it’s explained by the customer.
The best teacher I’ve ever met had of course many talents which all together made him a brilliant tutor and one of them was teaching us to be aware of the distraction of details while solving a problem. While writing examples today, I again was struck by the importance of this.
This teacher, who gave math classes in High School made his own math tests and the last task was always something special. In order to solve that you need not only have grasped the lessons but you also had to be really clever. I must say that I, as a mediocre math student, seldom cracked his last question, but I always looked at that first when taking a test and it was always a pleasure seeing him after the test explaining how to solve it.
One of his first tests included this question: given that you have a red, one meter stick. What would be the smallest dimension for a box to hold that stick?
This still requires some thinking for me to solve but the most interesting part is that he wrote that the stick was red and many students focused some of their problem solving on this fact. Why does he write that the stick is red? How does this affect the dimensions? But the answer was that he intentionally included facts which were distractions. He said that one key area of problem solving is understanding which facts are relevant and which facts to ignore. I guess some of the students hated that… But it is an important lesson in real life, as all software developers (should) know.
While writing examples, I struggle with this all the time. I try to think out all details and often get stuck writing examples which covers all these facts. And then it hits me: that fact is just the redness of the stick. It makes the problem solving hard but it is just a distractions. When I can ignore that fact, the examples becomes so much simpler to both write and understand.
My old teacher died many years ago, but his teaching stays with me in my daily work. What a sign of great leadership.