Days 3-4

The first iteration started with some training on Git as a large percentage of the attendees had not used version control before. After the training we created a central Git repository and GitHub and everyone forked it.
The first story we decided to work on was sending an SMS message to the members of Fleet when the Cabinet door is opened.

Cabinet class diagram.

While breaking down the story it became clear that there were certain aspects of the story that none of the attendees had an idea how we were going to complete. The Web service team needed to decide what technologies/frameworks they were going to use for the API, creating the web pages and sending SMS messages. The Cabinet team needed to conduct some research to decide how to interact with the physical world using the Input/Output pins on the Raspberry Pi and how to send HTTP messages to the Web service. The Web service team settled on Slim for writing the API, Twig for page templates and using an online service for sending the SMS messages after some advice from the mentors. The Cabinet team decided to use WiringPi for the I/O Pin control and libcurl for sending HTTP messages.

The rest of day 3 and the start of day 4 was taken up developing the system before the first customer demo (at 2pm on day 4). Not entirely unsurprisingly there wasn’t a complete Story to demonstrate as we’d only been working on the actual code for less than a day.

The retrospective at the end of the first sprint threw up a few common problems:

• The Web service team didn’t know what the Cabinet team were doing and vice versa. This was fixed by introducing daily stand ups, something I’d purposely avoided adding in at the beginning to see if it caused problems.
• There was confusion about simulating time using Test doubles in the TDD process on the Cabinet team. I’d only just introduced the concept of test doubles and the relevance of what they achieve wasn’t apparent yet.