Settling down with specification by example

We’ve now moved into iteration three or something like that. Some of the practices have changed, some stay, but it’s still both so rewarding and hard. Writing good examples are really so much harder than one could have expected.

What works for me is that we start with a group. The group can be between two and five people. We discuss first with eyes on each other and on the whiteboard. No writing should be allowed just to keep us concentrated on the dialogue.

We then take a coffee break, go back and try to structure the conclusions in a semi example way. The guys most often talk about how to make it a good example given the Gherkin language but otherwise the focus is on the business rules.

We then part ways. It never takes more than 2 hours, most because you need to change focus and not become too stuck. We are never done after two hours but continuing is only semi constructive.

I finish up my notes and send them to the developer responsible for typing in the example. He takes notes too and can therefore compare the two versions in order to see how clear we are.

After a first rough version we sit down together and discuss how well the example(s) match our discussions. This takes no longer than 30 minutes and after this the developer updates the example. This is often an iterative process where we can have many very short discussions but after a few rounds, we feel that we are done.

There after I sit down with another developer, letting him read and explain the example to me. This is to ensure that the example is interpreted as expected but also that it can be understood by someone else. This always result in some minor changes.

Done!

Personas to the rescue

We’ve now gone into our third iteration using Specification By Example and after a really good iteration we had a more struggled iteration the last two weeks. But this is a good thing: we’re learning so much from the previous iteration and I’m happy about the learning’s we’ve done. Better now than later; we will have ample time to handle new challenges later.

But as we’re moving along, we can also see a need for solid personas. I’ve worked some with personas previously but have never really fallen for it. Guided by our coach, Jocke Holm, we hoped to find the real practical usage. Yes, I’ve seen that it’s probably useful but when it’s come to the real thing, I’ve not used it to any greater extent. But now we need to form good examples with clear business value for our different users.

We looked at the personas we have on TUI Nordic. They are based on our segmentation model and I’ve previously found them somewhat useful but Jocke thought something was missing.

What we did was started writing and thinking about our personas and the result was a longer story and this made the personas come to life for me. Suddenly, with all these details and small moments I actually saw the grace of personas. I could see how these very detailed personas helped me in prioritization and forming examples.

But I also realized that I couldn’t present a number of novels to the team. Hence, I searched for a good model to present personas and totally fell for Per Axbom’s template for personas. With our novel form personas, I could present the key differences in one easy format. The templates are in Swedish but I think you can probably get the picture anyway.

From Per Axbom

And I must say that some of the other templates will probably find their way into my other processes too.

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.

the story of a tunnel

When we talk about professions, we like to know if someone is good at the profession or if he’s bad. A good professional should probably be successful more than the bad one, or? So what about project managers? What is the definition of a good project manager. He should be successful at managing project, then. But what is successfully managing projects? Does this mean that the management should be successful or that the project should be success? But what does it mean to successfully manage a project and what is a successful project? This post focuses on the latter statement: the successful project. In many definitions, you take requirements, budget and time (and sometimes quality) and look before and after. If you can check as many of these groups as “as planned” then the project is a success. But then there is the sense of success. This should not be understated.

We in Sweden can be proud to be on the top three list of building projects. The problem is that it’s not the best but the worst building projects in the world. Just after the opera house in Sidney, we find the soon to be completed building of the tunnel of Hallandsåsen. So, why has this tunnel made it into a list just two places below the Panama canal?

For you who are not up to date with Swedish politics, it all started with the railroad and the heavy industry in Western Sweden. In order to ship all the heavy goods, they wanted the railroad to go through the hill created in the last ice age, instead of over it. This would not only cut time but also enable heavier train loads. It was a sure thing but also a political necessity. It was important to show that we spend money on trains and not just cars.

The problem is that the hill was not helping out here. When they started to drill, it also started to rain in ground water into the tunnel. Not little, but a lot. And the wells in the surroundings were drenched and the tunnel needed to become more water proofed. Then the cattle on the hills started to become sick and die. The water became contaminated by the material they used to seal the tunnels. Also, it was not as easy to drill as they had expected. It was slower and harder. I don’t think anyone disagrees with me when I say that during this time, everyone saw the project as a failure. So there were haltings of the project, companies were sued and there was also legal proceedings regarding the spoiled water.

The projected was halted and then restarted. In 2015, the tunnel is predicted to be opened, 23 years after they started on the tunnel. I mean, Apple started selling the IPod one year after he launched is idea to his team and here it takes 23 years to dig a tunnel which is 8,6 km long. The tunnel was originally thought to cost 1 BSEK but will probably cost at least 12 BSEK in the end. Cattle died, people had to get new water supplies and of course we had all the scared people when we had the poisoning scandal.

A couple of weeks ago, I saw a TV documentary about this project and it was interesting to listen to how people involved saw the project. The engineer who saw this as the most interesting thing he’d ever done. He loved the technical challenges and probably saw the project as a success since they’d been able to overcome all these technical problems. We had the farmer who’d found his dead cattle one morning, who definitely saw the project as a failure: all that wasted money and of course the sadness over his lost animals. Then there was the project manager, focusing on the target: getting the tunnel DONE. He was a bit disturbed about the failed time plans, missed budgets etc but his work (even if there were probably many project managers along the way) was to be completed. They had not given in. The politician then. He was the most interesting person to listen to, from my perspective anyway. He also saw they project as successful, since it would be completed. But here comes the interesting part; he felt that it had been mandatory to complete the tunnel, even if it meant spending all that money since otherwise the spent money would have been waste. Come again? If you’ve wasted 2 BSEK, this money will still be waste even if you spend 10 BSEK more. But if they would have cut the project, then they would have spent the money but would not have a tunnel. Now we spend 12 BSEK and we get a tunnel. That is of course true, but think of all things you can do for 10 BSEK…

Finally, the reported turned to the potential customers. The heavy industry guy. As we all know, they don’t sit down for 23 years and just wait. They’ve found other ways and he didn’t see any big use of the tunnel.

The funny thing is that different stakeholders in a project can have such different opinions on the successfulness of a project. But who’s opinion matter?

Time estimation at school

Today was the first day of school for my son, beginning first grade. And is it not symptomatic that on his first day of school, his teacher gave them an estimation task. Don’t get me wrong. She seems to be a wonderful teacher and the exercise felt thought through but it’s in any case interesting that developers learn to participate in estimation before they learn how to write code.

The teacher told the class that she had one piece of straw for every day until Christmas break and she asked the students if they knew or wanted to guess how many days there were before the end of term.

Some students said 10, others 100 and someone said 30 000. It did feel like estimation of stories in other words…

My son waved his hand eagerly and was then given the word upon he said “as many days as you have straws.”

I wonder if he’s a natural at planning poker or just a little joker. Or perhaps he’s been reading Hitchiker’s guide to the galaxy.

Hey! May I have your attention?

Many of us who have children suddenly experience a change in what grab their attention. Suddenly they see things they would never even noticed before. If you don’t have kids you might have experienced this when you grew a new interest in something. When I got hooked on cycling, I saw cyclists and bikes very differently and I also became another type of driver: since I know how quickly I can ride my bike, I pay more attention to potential bikes on a road than your average non cycling driver. Sometimes this can be derived from more troublesome events. A couple of years ago, I was attacked by a probably mentally instable man while running to work and since he attacked me from behind I’ve since then become much more aware of scruffy looking old guys with big black dogs while running. Not that I’m afraid, but I do take notice of them.

What we pay attention to is personal but there are, as John Medina points to in his Brain Rules, also some cultural differences. Urban Asians view visual scenes pay a lot attention to the context of the scene and the contrasts between foreground objects and background objects while North Americans pay attention to foreground objects before paying attention to background objects and context. This means that different groups presented to one visual presentation will probably see very different things.

When we present something or try to make a visualization of something, we take for granted that others notice the things we want them to notice. But then again, we all know that you yourself don’t direct your attention to what the presenter had in mind. How many things have you thought about the presenter’s weird accent and missed the context of the presentation? How many times did one of the items in the presentation grab all your attention, making you miss the rest of the content?

We cannot force people pay attention to what we had in mind but we can do what we can in order to help onviewers pay attention to the important things. And step one is probably to recognize that we all pay attention to different things.

The word resource

Yesterday I blogged about resource planning and not long after publication, Dave Rooney (http://practicalagility.blogspot.com/2011/08/im-not-resource.html) posted a comment about the word resource.

I have some memory of this discussion, but I’ve not paid it any attention until now. I viewed the film and I can see some point to making a distinction between the words “person” and “resources”. But what words should we be using? When I use the word “resource planning” I cannot simply switch this to “people planning”. I don’t plan people and let plan their own work. I will gladly switch to other terms if the suggested terms are better and makes sense not only to the software development community but also to the customers and the developers themselves. When we create terms like scrum master and product backlog, we force our customers to use terms which they don’t understand and which does not make sense to them and for what good? It can also lead to so many misunderstandings. I’ve heard so many times how the word “sprint” has been interprated as what it means in sports. You exhaust yourself, which is not what I hope we want for our teams.

But I must take it upon myself to be less slack when I use the word resource and I can admit that that I’ve sometimes used that word when I should have said person or people. Not that I don’t like those words but rather due to corporate vocabulary. But here I’ll try to do better.

What do you think? Are you offended about the word Resource and if so: why? What should we use instead of the word resourc planning?

Thanks Dave for putting the spotlight on this.

Calculating the need for resources

Most of us need to calculate the need for resources but the question is what you calculate.

One thing you can calculate is how much resources you need to complete a task. The first question is of course what do you mean by completing a task. If you’re working with software development, is it the coding, or does it include all the things you need before and after the coding (branching, getting to know the code, writing tests, merging, validating test environment) and does it include stuff that other people do. Another question is if you say something takes 10 days, do you mean 10 days of actual work or do you mean days between you start with a task and when you end the task, the latter concept is what we call Duration in Microsoft project.

In other words you need to know
* The definition of done
* Decide if you calculate Duration or Work

The next thing is that you need to start thinking about the difference between cost of delivery and cost of creating. Lets say you have a task which takes 40 hours of hard labor to complete. Lets say your resource actually completed the task in 40 hours. But chances are great that he will bill you more than 40 hours. People take breaks, the help other resources with their tasks, they do other stuff. Do they report these side things on your project? You bet! Imagine the opposite! Two resources are working on different tasks but on the same project. First one of the resources want a second opinion from his team mate. So he strolls over and they talk things over for 15 minutes. Would you want all resources keeping track on stuff like that. This is one of the reasons we want team rooms but it also gives us a situation when tasks cost more than the cost of their delivery.

As we are budgeting our projects, I must surely keep this in mind. In my budget, I must take into consideration that this happens so even if I use the scenario that 60% of time is spent on tasks, I need to calculate that they work 100% anyway. So I need to take into consideration:
* The number of hours tasks take
* The number of hours tasks bill the project

In other cases, thing become more complicated. Take the product owner role. That person should sit 100% of his time with the team but he doesn’t have to work 100% on project tasks. He can do other stuff in the team room (as long as he can be pulled from these tasks whenever someone needs help and that the other stuff doesn’t bother the other team members). If you do have a product owner who works 100% in the project that is perhaps more of a warning sign: you might have a product owner proxy or someone who’s not involved in everyday business work.

Our magical memory

When we say that we recall, I guess that we take for granted that memories are like goods in our warehouse, and when we recall a memory, it’s like our brains go and grab those memories in the warehouse. But as we can see from research (again, see the book Brainrules for some references) every time we access a memory, we change it. Sometimes slightly and sometimes very much. And when you think more about it, it do make sense.

My husband and I met 20 years ago and some of the memories one of us tell someone, they get to hear over and over again when we meet new people. What has is some instances happened is that the memory has been shared so many times that the main caracter change. Just this summer I heard my husband share an old memory not once but twice with some new friends. The problem was that it was not his memory but mine. Over the years, the story has become as much part of his history as mine. It is almost like our memory works like a whispering game where the story changes for each person who’s ears the story goes through.

It is also so strange what sticks to our memories. I’ve a good memory for odd details (pestering my friends with weird facts all the time) and numbers. I can still recall my grand mothers phone number even if she’s been dead for many years. My husband and my son share the habit of not remembering names of people but it’s so strange. My son can have known someone for years and still don’t recall their names but he knows all the names of all the Bayblades and he can even recognize a recognize and know the name of a Bayblade in the store. Some things are probably more interesting to remember than other.