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 !