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.

Last weekend (21-22nd May 2016) I helped out running Cornwall’s first Tecademy along with other members of Software Cornwall. One of Software Cornwall objectives is to support education in the community and this event was designed to show teachers what resources were available to them and teach them how they could use the available resources when teaching their students. Although the event was targeted at teachers from Cornwall we did have one teacher travel down from Bridport in Dorset.

Day 1

Introduction

The day started with me giving the obligatory (boring) building safety instructions but quickly transitioned into a brief introduction to Software Cornwall by Mike Trebilcock of Cornwall College followed by a quick overview by me of some of the other events Software Cornwall runs that the teachers could potentially send their students on or attend themselves.

Scrum Tennis

Something that seems to be building into a tradition at the events we run, the first exercise we made the teachers attempt was Scrum Tennis. The aim is to give them an idea of how iterations and retrospectives work in software development work, it also has an added bonus of making the participants interact with each other and gets them talking which improves the rest of the event (not that it seemed like communication was going to be a problem at this event).
As we’d run a Mission to Mars event a month before we had the scores that the students had achieved still on the flip chart. When the teachers scores started to plateau as they made smaller process changes between iterations to make things more predictable (which is not necessarily a bad thing) we showed them the scores from the students which were 4-5 times higher than they were achieving. It appears the threat of being beaten by students will give teachers the necessary kick to think outside the box and come up with process changes that dramatically improve their performance. On the final iteration one of the teams did beat the best that any of the students teams did.
What’s always interesting about Scrum Tennis is the solutions different groups come up with to score points. The cascade approach below was a new one to me.

Physical computing

Our first exercise on Raspberry Pis showing the teachers some basic LED control to simulate traffic lights using GPIOZero. The teachers had to build the circuit themselves which caused less problems than I though it was going to and everyone was happy to get stuck in.

Minecraft

A surprise to me was that most of the teachers had never seen/played Minecraft. We started by showing them how to navigate the Minecraft world using the keyboard and mouse and explained how the world co-ordinates work. After they were comfortable moving through the world we taught them how to use the Python interface to Minecraft so they could programmatically modify the world.

Sonic Pi

After a short run through of the possibilities there was an eerie silence for the first 5 minutes of the teachers using Sonic Pi. I’m sure there were perfecting the musical masterpieces and eventually the room started to fill with music.

Controlling Motors

Back to using GPIOZero for the penultimate activity of the day. We gave the teachers a motor, showed them how to connect it up to a h-bridge, use it with GPIOZero and then gave them free rein to create what every they wanted. The videos below show some of the things that were created, sadly I didn’t manage to record everyone’s.

Camera

The day ended with learning how to use the Raspberry Pi camera.

Day 2

Robocode

Day 2 started with a few rounds of Robocode, a programming game where each player writes code to control a robot battle tank which is placed in a battle arena with all the other players tanks. The objective is to be the last tank standing by destroy the other players tanks. Well done to Kirsty for winning overall. As is obligatory the tank in last place was developed by a couple of the mentors.

Microcontrollers (Arduino, micro:bit, etc…)

Up next was an introduction to other Microcontrollers that are available. We didn’t go into too much detail about how to use them as we really wanted to let the teachers discover what a BBC micro:bit is capable of and how to use them. Anthony Lawrence gave an introduction to programming the micro:bit using MicroPython and then it was over to the teachers to try what ever they wanted.

Creative project time

The majority of Day 2 was spent allowing the teachers to develop whatever they wanted using what they had learnt during the event. We had lots of different ideas as shown in the demo videos.

Demos

Next Tecademy

Plans are now afoot for the next Tecademy which will be later this year. Keep an eye on the events section of the Software Cornwall website where details will be posted.

This October I’ll be helping run the second “Star Coders – Mission to Mars” coding school over October half term. If you’re aged 15-18 and are interested in a career in software development then apply using the link below. Don’t worry if you don’t have any coding experience, there will be a team of mentors that will help you to learn coding whilst being part of a self-organising successful team.

Apply now (deadline 9th October)
http://codeclub.cornwall.ac.uk/octoberschool/

Thanks to everyone that came to my talk.

Patterns and Practices for Embedded TDD in C & C++ – Slides