XP Creuna

Where's my team?

2010-05-28T10:08:00.007+02:00

When the application was put into production the original team split up and the developers was put on different projects. Most of the new projects was build on the same foundation and a lot of the experience could be reused. Those projects was much smaller and we did figure that we could build them in parallel instead of keeping the team and building them one after the other. Looking back I'm not sure this was the right decision and will never know. Anyway, we had to support the old application to fix bugs and add features on request.

New features!

Our customer wanted a few new features after the application went into production. With all the automated tests we could be quite confident that adding features would not break the application. We added new filtering and sorting functions, added feed forward for the filters and new fields for a few lists on web pages.

Bugs?

Yes, we did have one or two minor bugs, and one that really did make us reflect on our testing methods.

The bug removed a lot of data our customer had entered, as you can imagine this is not what they expected. Also, the first time it happened we could not believe it, as it was impossible for us to replicate. Until it happened a few times again. We did have unit test and automated acceptance test for the scenario and were confident the bug would have been trapped, that obviously was not true.

So, what was the case? We have three buttons, one "yes" and one "no" and one "regret". When clicking "yes" or "no" the "yes" and "no" buttons are hidden and the "regret" button is shown. Clicking the "regret" button restores the state so you can click "yes" or "no" again. A quite simple scenario, right?

Well, opening another browser, clicking the "yes" button and switch back to your first browser you still can click the "yes" or "no" button as that page has not been reloaded. Our backend logic is built to always allow you to click the "no" button, and that is correct in this case. Clicking the "no" button (from the first browser session) while actually being in the regret state made a call to a function that should never been called. This function was an update statement that updated more records than it should. We later found that due to a refactoring a parameter was removed from a SQL statement and never put back. Our unit tests tested the function with correct parameters but only using one record. This was a mistake, the test should have made the same test with more than one record.

But, while one of the bugs where severe there have been so few bugs that the effort put down into testing have payed off, a lot!

What's next?

From all the stuff I've learnt from this project I see Pair Programming and Unit Testing as two of the most important lessons as a developer. There are a lot of other practices that is good, but may fall in the category of project management.

So, next up is to convince others that Pair Programming and Unit Testing is really great stuff.

Project delivered - on time!

2010-03-01T13:53:00.004+01:00

March 1 is here, and we are LIVE! We also have a demonstration video of the public web on YouTube, narrated by Danny Saucedo of EMD. Check it out!

E-tjänsten för val till förskoleklass har öppnat (stockholm.se)

How we do this - development

2010-02-11T17:56:00.004+01:00

Following up the last post, about our process, here’s how we do our development. During development we do try to use as much XP Practices as we can.

We have Continuous Integration using CruiseControl that also runs all our unit tests with NUnit. We also set it up to show code coverage using NCoverExplorer (currently 87 %). We have two targets per project. One target builds and runs tests whenever something is committed to our Subversion repository and the other target does the same thing every night and also deploys it to our test server.

We have Automated Acceptance Tests using Selenium. Unfortunately we haven’t succeeded in making our nightly build target run them after the deployment as we intended to, but instead we run them manually when we come in the morning and once during lunch. Some why they time out nine times out of ten when we have the build server start the test…

We try to use TDD as much as possible. Other than NUnit we use the mock library Rhino Mocks to make all unit tests self contained. We also have the plug in ReSharper installed on everyone’s Visual Studio 2008 to get support for running NUnit tests, extended refactoring menu and enforced coding standard. ReSharper also gives us pointers on better ways to code, like pointing out that a method could be made static. It also gives some, imho, bad ideas though out of the box that needs to be changed in the configuration, for example removing curly brackets around one line clauses. Read more on my opinion about that particular issue on my personal blog, The Tommy Code.

We do quite a lot of Pair Programming. Initially we did virtually everything in pairs, but the further we get with the project the less we’ve done in pairs. “Just fixing it” is, the way I see it, not as important to do with a navigator. When in pairs we try to follow the Pomodoro rule of taking a break after every 25 minutes to make it less intense and to be able to stay focused. We don’t make estimates or task lists for the day though, just having a timer (Pomodairo) that tells us to take a break every 25 minutes.

We also switch pairs frequently, achiving collective code ownership for the entire project. Unfortunatly that doesn't include Front-end (html, css, javascript) or Test (Acceptance testing and manual tests), which are each done by a specific person. We have done some pair programming with one of them and one from the rest of the team, but far less than I would have wanted. We also had everyone in the team write one Acceptance Test each do know how it's done, which was a great idea.

We keep design as simple as possible, but no simpler, and always try to remind each other when we notice someone taking height for more than we need to do at this moment in their implementation. We of course try our best to follow the DRY principle, coding everything once and only once. I’ve noticed that it gets harder with unit tests with a lot of mocking, which may differ slightly between the different test cases, so I have to admit that there are some principle violations in the test assembly. Also, of course, we try to avoid if-statements.

To be able to have the unit tests covering as much code as possible, getting high Code Coverage, we do our web pages in a design pattern inspired by The Humble Dialog Box, an article by Michael Feathers. That leaves our aspx files, including the code behind, as stupid as possible and puts all the logic in a composer object in a separate project with no knowledge of the HTTP context. We first had an idea about using ASP.NET MVC but decided that we had enough new elements in our project with all the XP stuff.

That concludes the walk through of how we do this. We’d love to hear your thoughts about it and will be happy to answer any questions. Use the comment field!

How we do this - process

2010-02-09T17:27:00.007+01:00

I get a lot of questions about how we do this project. I’m going to start with describing the process in this post and am already preparing a follow up about the actual development. Comments and questions about our process are most welcome, but if it’s something about the development you might be better off wait for that post. That being said, here’s how we do it, the process part.

Our cycle (re)starts on Thursdays. Each Thursday before lunch we meet our customer to make sure we're on the right track. Since we have decided on two week iterations, every second Thursday we first have a sprint demo and then (re)prioritize all remaining stories in the backlog. The other Thursday we just discuss issues from the first half of the iteration and status of other ongoing tasks - i.e. stuff that people outside the team are doing. That may be setting up the production servers in the customers’ environment for example.

On the sprint ends we have a retrospective where the whole team, except the customer, get together and discuss the sprint. At first we had it before the customer meeting with the demo, but we always had to rush it in the end to get done before the customer came. Once we invited the customer to join or retrospective, but since the involvement during sprints is so low the customer didn't have much to say. Hence we decided we'd keep doing without and moved the retrospective to after lunch. The time before the customer arrives we now use to prepare for the demo.

The next step in the process is the task breakdown of the top prioritized stories. We get the whole team together and the Interaction Designer, who has somewhat the role of the on-site customer, will walk us through the stories and show the prototype. We take the the stories one-by-one and after the walkthrough we break down the story to tasks. When the breakdown is complete we play Planning Poker to estimate each task in measure of days, with half a day being the lowest estimate. Tasks a lot smaller than that we try to merge together.

When we had the retrospective before lunch we had task breakdown after lunch. I felt we needed some more slack to really end the first sprint before starting a new one though, so that was another reason for changing the meeting calendar. As we moved the retrospective to the after lunch slot, we now break down the stories on Friday after our daily standup meeting. I feel that it gives us a lot better rhythm. That also leaves some air on Thursdays to execute some ideas from the retrospective and deal with some technical debt.

Speaking of the daily standup we have it each morning at 9.15 except for Mondays, when we have a general meeting for the entire company at that time, and have our standup after that. We have all done Scrum before and have learned to value the daily standup meeting a lot. That’s about all we took from Scrum that doesn’t exist in XP though, except maybe the role Board Master that we invented to have some responsibility for our Kanban board.

We have the standup meeting in front of the Kanban board. Our board now has the columns Selected, Development, Test and Done, where the Development column is split into three sub columns - In progress, Trash and Ready for Test. The trash column is the only addition from our original board. It is used for collecting all tasks before they are all done. When all tasks are done we will move the story card to Ready for Test and the trashcan can be emptied.

The Art of Unit Testing

2010-01-27T11:16:00.004+01:00

To deal with the issue I mentioned in the post TDD is Hard earlier I bought the book The Art of Unit Testing by Roy Osherove. It helped a lot! Osherove writes plenty about how to make the tests cope with changes in the code and about writing maintainable tests.

He also mentioned Test Coverage tools as a good way to build reliable tests. Making sure every line is covered by a test doesn't test all possible results tho, but it's a good start. For example if you want to test a method that validates email addresses you might just have a RegExp. That row will be covered by the first test you write. Still I wouldn't find it reliable by just making a test with one email address. Here I didn't find any solution in the book, so I'd be interested to hear how you make sure your test is reliable.

How ever, I downloaded the last free version of NCover Explorer (1.4.0.7). It showed to be a very competent tool that let me find a bunch of untested code paths, and also a few completely untested classes. We also added a simple version to our Cruise Control project that gives us a figure with the current coverage (88 % right now). We have not excluded code that are excluded from the unit tests with the Ignore attribute though, so the real coverage is higher. We use the Ignore attribute for some integration tests that require a VPN connection to work.

Among the tips from the book I found the most important one was to have at most one mock object in a test, while other fake objects should be stubs. He also claimed that a test should have only one Assert verifying the outcome, but I'm not sure I agree with that. He is the expert tho, but I guess I need to burn my own fingers before I agree with that.

As a conclusion I would recommend this book to anyone. The one who wants to start doing unit testing will probably get the most from the book, but I think that also the one who is just curious about it and definatly the one who's been doing it for some time (that's me!) will have a good read too. I bet that even the expert might get some new insights while reading it. And it's a quick read - I think I spent less than 10 hours to read it all, except the appendixes.

Merry Christmas!

2009-12-23T15:39:00.003+01:00

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

2009-12-09T15:59:00.000+01:00

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

2009-11-27T17:05:00.003+01:00

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

If you get stuck with the Test First, just do the code and write the test after.
If you feel that you don't add anything while Pairing, go to the task board and start investigating the next task.
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

2009-11-12T11:40:00.003+01:00

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

2009-11-04T08:46:00.000+01:00

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

2009-10-30T11:18:00.003+01:00

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

2009-10-23T16:26:00.010+02:00

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

2009-10-22T21:23:00.014+02:00

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

2009-10-22T17:33:00.003+02:00

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

2009-10-22T13:22:00.001+02:00

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.

Pair !Programming

2009-10-16T12:10:00.004+02:00

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

2009-10-09T15:22:00.000+02:00

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

2009-10-09T14:28:00.001+02:00

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.