A few months ago we blogged about how mob programming has helped our team collaborate and spread knowledge. We started trialling it after Woody Zuill, a Mob Programming advocate, came to GDS and chatted with us about his experiences.
One of the things Woody talked about that had a great benefit to his team was group learning: each day his team would take an hour in the morning to work together and learn.
We recently decided to do some group learning as a team. So every fortnight we take half a day to do something together with the aim of improving or expanding our own understanding. This blog post aims to share our experiences.
The first two group learning sessions
For the first exercise we did the ‘Minisculus Challenge’. This is a set of small coding puzzles based around codebreaking. We ran the exercises in a mob programming style, swapping driver and navigator every few minutes and rotating round the whole group of approximately 10 people.
The problems can be solved in any programming language but we decided to do them in Ruby because the team wanted to practice in that language. This was successful and we finished the coding exercise followed by a mini-retrospective (a feedback session) to run over how it went.
The second task was another programming exercise carried out in a similar manner. This time we wanted to explore implementations of a finite-state machine (this is how one of our services is implemented). To help increase understanding of our systems, the aim of this exercise was to explore the possibilities of implementing a simple state machine and the problems you might come up against when you try and extend it. We followed a similar format to before, but we found that with a more open-ended exercise, we had a lot more discussions on deciding an approach rather than reaching tangible outputs.
A technical team unconference
For the third session we held a tech team ‘unconference’. In an unconference (also commonly called open spaces) participants suggest and choose the topics on the agenda themselves. We booked out a room for an afternoon and got as many of the developers and webops as we could together. We pitched ideas for discussions, assigned time slots and we ran a total of 5 sessions.
Unconference summary and findings
Over the last few months we’ve had lots of new people join the team so a few of the sessions were based on providing some context behind why we have the infrastructure and application architecture that we have. This was great as it helped us to re-evaluate some of the things and processes which had been in place for a long time, and helped to fill in some gaps we all had in our knowledge.
First off, we discussed our approach to developing services. We talked about what's meant by ‘Microservices’ and what we could do to make it easier to re-write or split out parts of our applications.
We then had a session where we discussed how messages are passed between components in our system, talking through which parts of the message are intended for which recipient, how we use encryption and signing on our messages and how our PKI is used to ensure communication is secure and can be trusted by the parties involved.
Richard, a developer on the team, gave an intro to the tools he’s been using to improve his typing and editor skills, such as gTypist, typing.io, vim tutor and vim adventures. We’re now using some of this content into an introductory Unix workshop for junior developers.
We also had a discussion around our choice of tooling for managing infrastructure. At present we use Fabric, Puppet and Ansible. We discussed why each tool had been chosen for each purpose and how it might be possible to develop a more consistent approach.
Finally, we had a discussion about how the theory of constraints applies to our release process and where it might be best to focus our efforts if we were to try and decrease the time it takes to push changes to production.
Feedback from the team
With such a large team it can be hard to get the chance to work with everyone, and these learning sessions have given us all the opportunity to learn from each other.
Learning sessions also allow us to experiment and try new tools and approaches without the same concerns we have when building code for a production environment. One of the key learnings we took away from our sessions was from the second programming exercise on a finite-state machine. As this exercise was less well-defined, the feedback for it was really valuable.
We discussed how to improve future learning sessions and agreed that well-defined exercises work better. For next time, we’d introduce a series of small objectives that build on each other, and also tackle any ambiguities in the task that could block progress. Additionally, we found that for us, teams in these sessions should be no more than the same size as what we find works for mobbing (5 people).
Overall the feedback for the unconference was great, and it meant that both developers and web operations engineer had the opportunity to work together with colleagues they wouldn’t routinely work with, whilst learning things from the group as a whole. We will be hosting future learning sessions and iterating the format based on what we’ve already achieved.
Subscribe to the blog to keep up to date with our latest developments on GOV.UK Verify.