Days 8-10

After the successful customer demo from the last sprint we needed some new user stories so started with a Three Amigos meeting to agree the stories with the customer. We created stories to monitor when the defibrillator was taken out of the cabinet and keep the temperature of the cabinet above 5 degrees centigrade so the defibrillator does not get damaged by the cold.

As we’d demonstrated some stories in the previous sprint we discussed what it actually meant for to complete a story and came up with a Definition of Done. The final iteration went fairly smoothly and myself and the other mentors were able to take more of a back seat role with the attendees needing less help.

On the Thursday night a group of us attended the local Cornwall Geeks meetup. It was a good chance for the Huddle attendees to meet other local software developers and discuss possible local job opportunities. The meetup also had a couple of talks, one by Wo King on a new product he’s launching and one by me about the Summer Huddle and other Software Cornwall events.

The final day was very calm considering we were having our final demo to the customer and potential employers. The release went smoothly as did the demo, well done to Emma who presented the demo.
By the end we managed to get the system:

• Unlocking the door when the correct pin code is entered
• Sending SMS messages when the door is opened
• Sending SMS messages when the defibrillator is removed
• Keeping the temperature of the inside of the Cabinet above 5 degree centigrade

The customer was happy with the progress and we learnt a lot about what is going to be required for the rest of the project. We’re now considering how we carry on the project after the huddle.

Thanks to everyone who came

Days 5-7

With the initial setup over we were able to concentrate on producing usable features during the second iteration. As is often the case when I’m introducing agile development to people who have never done it before, keeping the team focused on the Minimum Viable Product (MVP) was the hardest part of this iteration.
We ran into some confusion over terms we were using the describe thing during the iteration, the most common being the term “Pin” with some people thinking it was referring to an “IO Pin” on the Raspberry Pi and some thinking it referred to the “Pin Code” used to unlock the door. The confusion were easily overcome by everyone agreeing on terms to use but before we realised it did lead to some interesting and confusing conversations.
We had completed two of the user stories for the customer demo at the end of the iteration. We’d implemented sending SMS messages to the members of Fleet when the door is opened and allowing the door to be unlocked by entering the correct pin code. This meant that we only had one tiny story left in our backlog so we held another 3 amigos meeting to create some more user stories with the customer after the demo.
Issues raised in the retrospective were that everyone needed to commit and merge more often as there were quite a few integration problems and merge conflicts during the iteration.
There was also a request for more Fans as England was going through a mini heatwave and it was very hot in the office.

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.

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.

The Agile Summer Huddle is a two week event I run with the help of various Software Cornwall members (this year Headforwards, fffunction and Nixon Design).

This is the first of a series of posts about what happened during this years event.

The purpose of the event is to introduce a group of graduates to how software is developed within an Agile software development company. During the event we develop a software product usually for a local charity or organisation. This year we were developing a system for Fleet to monitor the emergency defibrillators they have located throughout Cornwall. The purpose of the system is to allow easy access to the defibrillators and notify Fleet when they have been used so they can be tracked down, have a battery change and be back accessible to the community as quickly as possible.

Day 1

I started with an introduction of what was going to happen during the event, using Scrum Tennis to introduce the concept of iterations. Scrum Tennis allowed every to relax and got them talking to each other. Next we setup the working area, I had purposely not laid out the working area so they could decide how they wanted to work, the only restriction I put on them was that they were going to be pair coding so they had to accommodate that. We then setup the Raspberry Pis we were going to be using as development systems and went to lunch.
The afternoon was mostly taken up introducing everyone to Test Driven Development (TDD) using Cyber-dojo. I was originally planning to run an introduction to Git as well but in the end I decided that it was probably a bad idea as the TDD introduction had been quite intense. I finished the day with a brief overview of the project.

Day 2

After finishing the morning cyber-dojo TDD practice, Dan Goodwin of fffunction gave a talk on UX, User personas and testing with Users in preparation for the first customer visit.

We then had our first customer meeting with Norman Trebilcock and Kieran Bignell of Fleet giving an overview of the project. During the overview the attendees noted down all of the users they were told about and the head line features that we could use as Epics. Once the project introduction was complete, we discussed the Epics and users that were collected with the customer to ensure that what everyone had noted down was what the customer wanted. The customer then picked and ordered by business value their top 5 Epics.

We took the top Epic and created a simple User Journey Map for one of the paths through the Epic and created User Personas for the users involved in the journey. The user journey was then broken down into User stories and Conditions of satisfaction agreed with the customer.

To help with the discussion about how to break down the system, we created some C4 Architecture diagrams, this allowed everyone to have a common understanding of how the system was going to be built and what the responsibilities of the various parts of the system were.

After we’d broken the system down to the Container level it was decided to split into two teams collaborating on the overall objects, one team working on the Web-service and another team working on the Cabinet (embedded) monitoring system.