Ignoring the redness of a stick

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.

Completing a first iteration using agile and Specification By Example

Time flies and on Tuesday, we complete the first iteration, using agile practices and more importantly: Specification By Example.

We started off with a number of short planning sessions, setting the stage and discussing the scope. We were here coached by Joakim Holm from Adaptiv and Herbjörn Wilhelmsson and together we actually set a little bit different scope than we had set before and now the scope feels manageable. Herbjörn and Joakim forces us to really look at the scope, which up until then had been in practice a big delivery: all or nothing and we hadn’t been able to force ourselves to see it differently.

Findings:
* Even if you’ve been working with agile practices before, an outside coach can help you renew your practices and consider new ideas.
* With an external party, the scope can be discussed more freely and sometimes, as in this case, the scope can actually be divided into manageable deliverables.

Parallel with the actual planning and completing of the project, we’re also coached in Specification By Example. We’ve done some short training sessions and as we’ve gone along, we’ve just started writing feature files with scenarios. We’ve also initated (but not yet started) a book club based on Specification By Example. This book club is targeted internally and to everyone interested in the methods. More on this in a later post…

Findings:
* It is one thing to read a book on a method, and another to really test and get feedback from someone who’s been doing this before. We would have gone in a completely wrong direction hadn’t we had the feedback from Joakim and we would either had ended up just trying to get the example tests working or simply giving up.
* The combination with small training sessions and directly testing something really works for me and things got really concrete right away. This probably works better for me than a couple of intense training and then being left on my own.
* The whole team participate in the training som SBE becomes a common thing for the whole team. Everyone can edit the files and anyone can discuss them. This means that I can test my scenarios with anyone in the team – perfect for a coffee break.
* As I’ve worked so much with user stories before, I initially had a hard time understanding the differences and had I just started working on this on my own, I would probably had missed the point.

During the iteration planning, we discussed the highest prioritised user stories and I was actually challenged in my priorities: why is this important? Does this really give business value? So, I changed my mind. I also stressed the importance of success in the first iteration. New teams are often underestimating the challenges in the first iteration…

Findings:
* Challenge your onsite customer if you don’t understand the priorities: very often there might just be assumptions behind the original prioritisation.
* Don’t take on too much during the first iteration: it is better to build a habit of succeeding.
* Don’t spend too much time on estimation in the first iteration – you know next to nothing so it’s better to afterwards evaluate how long things actually took.

After the iteration planning, we got going in an ordinary agile manor. I will not in this post go into details concerning the agile practices but what was interesting was that even if we’ve not been talking TDD, the testing and the pair programming came naturally to the crew and I just had to hand out some extra keyboards and mouses. This also lead to developers working on areas which they’d not worked with previously. Developers who normally only works with user interface now have a basic understanding on what’s underneath. Nice…

I for myself, started to write on the scenarios. Joakim started with an example based on our user stories. He told me to start editing and I had to fetch my old and hidden knowledge on how to edit test cases in Visual Studio from the long term memory. I started writing some and then asked Joakim what he thought. His quick reply was that I needed more training on Gherkin 😦 well, actually this is the good point: he was (and is) absolutely right but now I got the feedback directly and could slowly improve my skills.

Findings:
* It would have been very hard to start working without the first examples from our User Stories. Now I could see based on my problem domain how this would work with the scenarios, etc. It became much easy to just get going. Had I started from skratch, I would have had a hard time knowing where to start.
* It was good to get direct feedback on my scenarios. By pointing at errors or areas of improvements in my real cases, I learnt so much more than I would have from made up examples.
* I always discuss quickly with someone before checking in changes. Would I be working on my own, this would make no sense. Now I get to test the scenarios on someone else and at the same time build their business knowledge. I also get so many good hints about good scenarios from these discussions.

So how is it going? Well, the progress board looks really good and we feel confident now when the iteration is nearing an end. If I would change anything, it would be my own priorities. I chose to do some other things which kept me away for sometime days. I tried to slip by when the meetings were inhouse but I can definitely say that I should not have prioritised all these outside tasks. Not that I don’t do other stuff otherwise, but I try to do so many of these tasks while in the team room because otherwise I miss out.

Findings:
* The time in the team room has a value in gold.

Draftning a first example

Yesterday, we worked on values, objectives and user stories in one of our projects. We were also given a short introduction to SBE by our coach Joakim Holm. SBE, for you who like me are new to to the concept stands for Specification By Example. I will not with my so not even basic whisp of knowledge about what this really means at this point even try to explain it, but we will formulate solid, important requirements and test cases in the form of specifications which can be executable. I will probably go into more details in later posts but if you want to readup on the subject, just google Specification By Example and you’ll find someone who can explain this much better than me.

So, back to my first encounter with these specifications. When I saw the way they were written, I first didn’t really understand how they relate to user stories – why do both? What is the difference between the notes on the flip side of a story card and a specification?

A bit skeptical, I during the first session started writing user stories. This is familiar grounds for me and we found a bunch of good stories. So I left the user story writing workshop with the intention to write a number of related specifications, exemplifying the user stories. No probs, hey. I know how to write this stuff, don’t I? I’ve written tons of user stories and as many test cases.

But this was no cup of tea. Writing these examples was so much harder than expected and I went home with a draft for one specification and more questions for our next session. Some of the questions are of course questions about formulating examples but most of them are domain questions and a large portion are directed to the developers and the architects. Which I guess is the purpose of this work. Keep you posted.