Home > Agile, sbe > Completing a first iteration using agile and Specification By Example

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.

Advertisements
Categories: Agile, sbe
  1. 2011/09/10 at 8:46 pm

    Great writing, Anna! I am so thankful that I get your perspective on what’s going on as well. And thank you for accepting my feedback during these weeks so gracefully. I think we’re on to something good.

  2. 2011/09/12 at 7:45 am

    Very neat! Having an experienced person in the team is great, having the experienced person focusing on helping the team build their own experience is bulls eye!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: