My experiences on an Open Source Distributed Agile project

This project called RapidFTR was interesting because we all worked towards a good cause of supporting children who get separated from their families during disasters. So people at ThoughtWorks who were in between projects initially volunteered to help out building the applicationas part of the company's Corporate Social Responsibility.

It was also exciting in terms of me being the lone QA for the team. This was a truly open source distributed agile project and we had to adapt to a lot of process changes. Our aim was to get the source code into the cloud so that anybody and everybody could contribute to it.
This was a Ruby based project. We used all open source tools. GitHub for the source code repository / defect tracking, TeamCity for CI, CouchDB as the database.

There was a huge process tailoring required for the project. This is because, though initially the development was happening only in London, it gradually started getting distributed over to the East and West coast of the US. Thus we could not do pair programming anymore.

Stand ups instead of everyday used to happen biweekly late in the evening GMT, keeping the time zones in mind.

We did not get chances of doing story huddles either, again due to the differences in time and space.
The team came up with the idea that the code be peer reviewed once it is written to over come the lack of pair programming.

Similarly I suggested that we could also do some peer reviewing for the acceptance tests that are written in Mingle before the developers start playing a story. This would enable a knowledge sharing session amongst the team and also a way to have a second eye on the tests.

As a QA I used Cucumber and Webrat. It is a great tool to use. It works similar to Fitness and TWIST if people have prior experiences on these tools.  And one of the advantages is that it has some pre-implemented steps which can be used while writing the BDD tests. The tests run quiet fast too.

The stakeholder who came from a developer background, started getting too much involved in the development / implementation process of the project. This led to a great amount of discussions. I stepped in and suggested if he could just explain what he wants in plain simple english and le tthe developers worry about how it needs to be done, life would be easy for everybody. The stakeholder took this in a very positive way and the situation indeed change in a positive way.

Even after two months into the project I was testing the application on my local host which was quiet a pain. The developers kept forking out of the trunk to work on their feature stories and not merge often. As a QA, I found it very difficult to keep track of the current status of the story that the developers were working on as it was a pain to keep shifting between forks. I suggested them to merge as often as possible so that I can test the application on trunk which also might help me catch integration issues.

In a open source distributed agile project, one of the challenges of the QA is to review the code level tests (acceptance tests, rspec tests etc) along with the automation tests (scenario level) to make sure that the tests are actually testing what they are supposed to.

There were several people involved working solo in SFO, NY, London.

We kept communication to a maximum by opening up a google group and responding to emails through that medium. All most all of us were on skype and gtalk to catch up for a quick chat. We also used Google Wave for discussions. As explained earlier the core team used to meet up biweekly on a skype conference call to catch up with the updates.

We did a mistake of not including the stakeholder since the begining of the project on site. The initial 2-3 weeks of the project went in to skype calls with the stakeholder. But only when he came down to London and we all started talking over the table, did we realise that we were miles apart from understanding each other till then. After some heavy discussions and gaining a better idea, we had to go back and change some basic logic and architecture of the code. This costed us a bit of a time.

I was trying to improve and give emphasis on the performance of the application since the beginning, as that was one of the important lesson learnt from previous projects. But the developers were least concerned about it and like ever before wanted to keep the performance aspect for laters.

My first code jam

I attended my first code jam as an Agile Quality Analyst last week in our ThoughtWorks London office. It was a great experience and learnt quiet a bit to take forward to future code jams.

The code jam was conducted for a project called RapidFTR which is a child finder application to reunite children who get separated from their families during natural disasters.

The developers spent a lot of time setting up their machines on the day of the code jam thus losing precious few initial hours. Ensuring that people have set up their machines before hand to avoid loss of time on the day , or giving yourself extra time before the code jam for the setups and people to settle in, is a good idea. One of the suggestions would be coming up with a Virtual Machine with the required setup, so that people can conveniently download it and start playing.

Preparing ourselves for people with different backgrounds (BAs, QAs, devs etc) and skill sets  by collecting the information before hand, will ensure that everybody is engaged well.

Having a separate code jam environment / cloning the repository, would be nice thus protecting and isolating your master build. It would also help the QAs to rapidly do regression & smoke testing if the developers could keep checking in their code onto this environment. Needless to say having a Continuos Integration running on the code jam environment would help identify build integrity at an earlier stage.

Prioritizing enough stories so that there are no dependencies at any point of time is an useful exercise, so that there are no surprises during the code jam.

If the QAs could come up with the acceptance criteria and also try writing automation tests (I mean the BDD way) before hand for all the stories that are intended to be played in the code jam, then it would be very helpful for the developers to start off on stories and know what exactly needs to be done. Developers could finish implementing the automation tests as part of story completion.

Huddles before the developers picked up stories usually did not go very well as I was the sole QA always running around. Maybe having greater number of QAs having an understanding of the system.

We had a pomodoro up and running to rotate people and also to giving them an occasional break. A good practice is to keep a story owner (one who knows the technology etc) on the story and rotate others.

As a QA, I personally felt that, like usual, I could not go and poke the developers for doing analysis while the story was being played. I found this very difficult as the developers were in a constant time constraint for delivering some sensible functionality by the end of the day.
But I ensured that all the automation tests that were previously written have been properly implemented as part of the development sign off.

I observed that people do get disappointed for not finishing off stories at the end of the day. So we should make sure the stories are short and achievable but also challenging enough for a day.

Having loads of food, beer and freebies cheered up people !