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.