Merry Christmas!

Christmas is closing in and the Whole Team will be gone until 7 january. We're leaving mid-sprint, one week done and one week to be done 7 january and forward. It was either that or having slack time for a week working freely. Having a four day sprint didn't feel like an option. Any way I think it will work fine with a two-session sprint. And certainly better than unplanned time.

On another topic I received a Christmas gift today as I finally got the book I ordered three weeks ago. It should have been delivered in 3-6 days, but I guess it was busy times for the book shop... The book is The Art of Unit Testing by Roy Osherove. I've heard a lot of good things about the book so I hope it will be an interesting read. I'll try to post a review when we're back.

Merry Christmas to all of you, and a Happy New Year. See you in the next decade!

Selenium not a success story

Since the beginning of this project our Test Manager has been developing automated acceptance tests for our User Stories using Selenium. While it is great to have automated acceptance tests, it is not so great when you can't get them to run on your build server. The whole point of automated acceptance tests is to get feedback as soon as possible so you can correct either the tests or the code that broke them.

Our goal is to run the Selenium server as a Windows service. First I read this post http://clearspace.openqa.org/thread/17226 where I got the impression it was not possible to get Selenium to run as a service. Then I read this post http://clearspace.openqa.org/message/39530 telling that it was possible. Anyhow we have not got the Selenium to run successfully as a service, or rather, it does run but not reliable.

What are our options?
We decided to timebox the life of the Selenium server experiments to a maximum of a week. During that time we will set another developer to look at the problem to get a new perspective. There are three options to try here:
1. Get the Selenium server to run as a service. As we already know it might not be possible.
2. Always login to the server and start the Selenium server manually and not log out. The Selenium server works fine when you are interactively logged in.
3. Try to start the Selenium server using a scheduled task. I don't think we have tried this.

Another option than getting the acceptance tests to run on the build server is to run the tests on the developers machine, just like with unit tests.

I will give you our final decision in a future post and would of course appreciate your feedback on how you are working with automated acceptance tests and what tooling you use.

Easing up the XP

We have not reached the desired productivity level just yet even though development is faster for each day. Since we have a challenging dead line we have decided to ease up a little on the XP to get faster forward. This is what we did.

We first had a retrospective with the guys in the team to get their idea of what is slowing each of them down. Pair Programming and inexperience with TDD was the key problems. Some said that coding in pair takes longer than doing it alone since you need to explain everything you do. Some said that thinking about creating the test first probably took three times as long as just doing it.

The actions we decided on was

1. If you get stuck with the Test First, just do the code and write the test after.
2. If you feel that you don't add anything while Pairing, go to the task board and start investigating the next task.
3. Don't ask too much and don't tell too much while Pair Programming. Stick to the problem you're working on.

TDD is hard

Writing the tests isn't the hard part. At least not for me. It's when you have them. I often find myself do my refactorings first and then correct the tests to work again once refactoring is done.

How do you work with refactoring in a TDD project?

Another hard part is to stop writing the tests - to find the decent level where you have good tests and remain productive. I could spend an entire day writing tests to validate some data, but that wouldn't be very productive. Probably 15 minutes may produce the code needed with just a small number of tests - adding more tests would make sure that even more cases work, but they all probably do from the start.

When do you settle and think a test is good enough and move on to the next function?

Intensity

In the past three weeks...

I've learnt the basics of XP.

I've learnt the basics of Planning Poker.
I've learnt the basics of Pair Programming.
I've learnt the basics of Test Driven Development (TDD) with Rhino mocks.

I've learnt that a project that grows with new members rapidly is exhausting.

I've learnt that you must develop MOSS sites in a Virtual Machine.
I've learnt how to enable stack trace on MOSS.

I've learnt new keyboard shortcuts in Visual Studio.

and probably more...

Current number of Unit Tests

I just added a new Gadget in the sidebar, where we'll show the current number of Unit Tests in our project. We're starting now at 21 unit tests.

Presenting XP - our XP

I just held my fourth presentation of XP this month. The first was on the startup meeting, the second with the team, the third was for the customer and today it was for the entire tech department of Creuna Sweden.

The first occation was alot about selling the idea to the company. That presentation was based on the article What is XP by Ron Jefferies along with a couple of slides I added about why this was good for us, both in this project and in the long run. On the rest of the presentations I have just had one slide, One Page XP by Bill Wake, and talked freely about XP from upper left to lower right, adding things as I pass the different stages.

The second occation was to get the team started, trying to figure our the roles and responsibilities among us. What are the Interaction Designer, the Test Leader and the Project Manager supposed to do? We've decided on having the Interaction Designed being in charge of the user stories, and coordinating them with the customer. Along with the Test Leader she then writes proposed Acceptance Tests for each story. The Test Leader is then in charge of implementing the Automated Acceptance Test using Selenium and also doing the manual testing where Selenium can't be used. The Project Manager mainly do XP while playing The Planning Game and keeping the Overall Schedule. Other than that she keeps track of how we're doing with time and estimates and arrange everything around to let the rest of the team focus on producing - she's somewhat like a Scrum Master.

The third was more of a introduction where we wanted the customer to know what to expect and to get to know how much the customer wanted to be involved. We got the customer to agree on sitting one day every week at our office, and also got to know that more involvment in the story creation was wanted. We settled for a process where Angelina will produce the stories and then walk the customer through them in a separate meeting before we plan. It's a solution we all think will work really good.

This last one was more educational to let everyone else at the company know what XP is, what it can do for us and what pros and cons we've found so far. About half of the group knew briefly what XP is on before hand, but only a few had more than shallow knowledge. The most discussion was when I came to the Design Philosophy box in the lower left where we talked about Good Design versus Simple Design. I stated that all Design Principles still are valid and that Simple Design just states that you shouldn't make your design "future proof". An example that came up was that you might not want to use a Factory for creating objects if you only can see need for one implementation, which I agreed to but added that you'd anyway would make that class implement an Interface that others use to access it - making it easy to add a Factory later on if needed while it isn't adding code that isn't needed. I found it peculiar that no discussion at all was raised around Pair Programming - except our thought about how to deal with new developers added to the team.

Planning Poker

Today Tommy brought his Planning Poker deck to our Planning Game session (see previous post). I've only read about planning poker before but never used it in practice.

The Deck:

The Planning Poker deck is like an ordinary deck of cards but instead of clubs, diamonds, hearts and spades with different values there are only numbers representing days. On the back of each card there is a color to group them. Each color consists of thirteen cards numbered 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100. It also have two "wildcards", one coffeecup meaning take a break and one question mark meaning we have to discuss this.

Planning Poker Deck

Game play:

We were four players. Each player picked a pile of cards with the same color. As in most card games you are not supposed to show you cards face to your competitors. Then we read one of our User Stories and each player played the card representing the number of days they believed it would take to finish it. Estimates included automated acceptance tests as this is the definition of done in our case. The card you played was placed at the table with face down, and then turned by all players simultaneously so you wouldn't cheat:) If all players played the same estimate this estimate was written down on the User Story. If all players played different estimates we discussed back and fourth until we all felt comfortable with the estimate. Equally if some player played a much higher or lower value than the rest of us. The coffeecup or the question mark was not used, maybe next time.

Even though there's no real competition as there are no winner, except the whole team if the estimates are good, it was much more fun than just sit down and do estimates. I really recommend you to try it.

The Planning Game

Today we played our first Planning Game. We started this morning with playing Planning Poker to estimate all the stories we've come up with. It turned out really good, but we didn't manage to estimate all the stories on the hour we had before the customer arrived for the Release Planning and Iteration Planning. A small pile of assumed low priority stories remained, but we probably managed to estimate more stories this way than would have been the case if we had estimated the usual way.

Simon, Tommy and Angelina playing Planning Poker

When the customer arrived we first prioritized all the stories we had, including the ones that we didn't have time to estimate. Once the priorities were in place it was a no-brainer to choose what to include in the first iteration. We simply calculated how much time we would be able to spend during the iteration and then selected stories from the top until we reached the available time. The stories with high priority were all estimated by the morning session. We also created a release plan with some set dates for different parts of the project.

Moving on to Iteration Planning we had a bunch of proposed Acceptance Tests prepared to define each story. These were discussed by the Whole Team, including the customer. We slightly redefined a few of the stories by changing details in the proposed tests, and also came up with some extra tests needed to prove the function. Along with the definition of Acceptance Tests we also performed the Task Breakdown of each story. Here it seemed that the developers were the only ones really needed though, so in the future we might do that after the Iteration Planning.

Continuous Integration

For a few days we've been working to get the build server ready. We find it crucial to the entire project that the build and deploy works flawless, also continuous integration is mandatory in an XP project. Currently we test the continuous integration setup with a small template project for Microsoft Office SharePoint Server 2007 (MOSS).

So far we've managed to get Cruise Control.Net to trigger on commits to our Subversion repository. We already do this for our other projects so it was an easy task. What differs is that it also runs all unit tests and later it will also run all the automated acceptance tests.

It was quite nice to see the red/green bars of failed and successful NUnit tests in Cruise Control after a code commit to Subversion.

Before the build was actually working I was worried MOSS would make me install the whole Share point package on to the build server just to build and create a deploy package.

But, no worries, making it build was quite simple I just had to copy Microsoft.SharePoint.dll to our assemblies folder (this is our lib or libraries folder).

Tommy and I paired up to figure out how to use WSPBuilder without the need to install Windows SharePoint Services (WSS) to the build server. According to the WSPBuilder documentation it is required. First time we run WSPBuilder it complained that some assemblies where missing. By adding the -DLLReferencePath parameter referencing our library assemblies for WSPBuilder it was outputting the wsp file we wanted.

Next up is to get the wsp package to install nightly on the test web server. We don't believe we can do deploys every commit as MOSS is not super fast when deploying wsp packages.

Is this wise or not? Would you put the deployment into the continuous builds? Please give us your opinion.

More about writing user stories

In this project we've decided that I, as Interaction Designer, should write the user stories. I've worked in projects where we've used stories for planning our work before, but then we've mostly focused on the size and the independency of the stories. We've also prioritized functions before writing the stories, and writing them have been done by the whole team as a part of the planning activity.

This time we've been writing stories with the mindset to make them, Independent, Negotiable, Valuable, Estimatable, Small and Testable. We've learned these rules from Bill Wake.

An Interaction Designer should be aware of the user value in everything they do, and I find it useful to formulate the user stories so that they express how every part of our project is of value either to the end user or to the customer. In this way everyone in the team will be reminded of why a function should be developed and it will also be a good help to prioritize the stories later.

The writing of user stories in this project has been much about documenting a prototype that we've created in the pre-study. This work has been good because we've once again been forced to challenge everything we've decided to develop with the question "Why would the end user like to have/do this?"

To me the most difficult part of writing the user stories have been to make them independent. We have a step-by-step flow where the user first signs in, then fills in a form, and at last submits the information. Having a story including filling in a form while excluding the submitting part is not an independent story, but including the submitting part may make the story to big. Instead we’ve tried to split that story into several stories where some is about functions that make it possible to fill in the form (e.g. listing and manipulating information), and another one is about actually filling in the information and submitting it.

It has also been hard to make the stories both small and negotiable. Adding too much detail is easy, especially since we already know a lot about details from the pre-study.

Writing stories alone is hard. After a while you come to the point when you do not question your own writings, if you’ve once thought that a story seems to be, for example, negotiable it is difficult to reconsider it without a second persons view of it. Therefore I’ve had a great help from the developers and the Test Manager in my team. Discussing the stories has lead to new, deleted and rewritten stories.

The next step will be to take the user story draft to discuss with our customer!

To learn more about writing user stories I’ve been reading:

• The first three chapters in User stories applied by Mike Cohn. I think I learned the most from this reading, I appreciate that it has several describing examples.
• Advantages of the “As a user, I want” user story template from Mike Cohn’ s blog
• User stories at extremeprogramming.org
• User stories at Wikipedia
• A chapter about User stories in Extreme programming explained by Kent Beck. I found this reading quite brief (probably because I read it after all the other reading), but it may be good to get a first idea of what this is about.

Pair !Programming

The first few weeks of this project a lot of time have been spent in meetings, discussing how to do this, writing stories, prioritizing and setting up the environment. Today we decided to start doing the "pair" part anyway, so today we're doing Pair Build-Machine Configuration.

We've decided to use The Pomodoro Technique while starting with this Pair-thing. To begin we will do three Pomodori development and one Pomodori reflection before lunch, and then another similar set of four Pomodori after lunch. Our guess is that we after a while, when we have gained some experience with this, will add more development and remove at least one of the reflections.

Do you think it sounds like a good way to start?

Writing User Stories

As the first task doing XP we've started writing user stories for our project. We've decided to use the “As a , I want so that ” story template after reading this post by Mike Cohn. We consider the so-that clause required though, since we think it ads a alot of value to think about why we do things - we have allready removed one of the features we had planned after challenging it with that question.

Yes, we have planned features. Actually the entire project is planned up front, which is another challenge for this project. It was preceded by a pre-study and the picture about what should be done is pretty clear to us allready. Our interaction designer and our project manager have spent alot of time with the customer to get this picture, which we know is not very XP-like. The good thing is that these two internal persons have so good understanding about the product that they can act as the on-site customer that we can't have for real.

Cannonball into XP

A few weeks ago we were finally granted to use eXtreme Programming on a new project. It's a web application with a fair amount of business functionality. We have decided for the Cannonball-approach as Kent Beck refers to in his paper “Getting Started with XP”.

We both have some initial understanding about XP and have been anxious to try it out, but haven’t had support until now. We have experience from some of the practices, but not all, and have spent the first few weeks reading up on more details, like Extreme Programming Explained (Kent Beck) and Scrum and XP from the trenches (Henrik Kniberg).

Currently we use continuous integration on all projects already, and as senior developers we have plenty of experience with refactoring. We have used the Scrum process, and thereby Stories and Iterations amongst other things. Tommy have also been experimenting with TDD for a couple of years.

As for our concerns, none of us have done much pair programming or automated acceptance tests before. Another issue is our organization at Creuna which does not map directly to XP. Being consultants having an on site customer can be difficult for example.

Commenting this post we would love to get your input on how you started with XP. Also, during this project, don't hesitate to give us comments how you would solve similar problems.