Agile Retreat – 2 Days of Code Enhancing Workshops

The Agile Code Retreat is a 2-day event where participants study and practice different tools and methodologies used in software development. The first ever retreat was run by Jon Jagger who specialises in practice, process, TDD, and complex-adaptive systems-thinking and is known for his collaborative development tool: Cyber-Dojo. Co-hosting with Jon was Kevlin Henney whose development interests are in patterns, programming, practice and process. A few lucky members of our team were able attend this year. Here are some of their thoughts and findings.

Filcho Dragunchev

Software Developer

The Agile Retreat was a breath of fresh air - I enjoyed revisiting basic principles that often get overlooked in the day to day development - it highlighted little anti patterns which in the long term, have the risk of being detrimental to a tasks’ progress.

I enjoyed being able to ask any questions even at the risk of appearing ignorant which were handled very well and explained without any judgement. Jon and Kevlin were very easy to talk to and treated everyone with upmost respect. The venue was also very conveniently located and the catering throughout the day was fantastic - overall a very enjoyable and educational two days and I would happily attend again in the future.

Emma Cheney

Software Developer

Spending two days at the Code Retreat was invaluable to my career. Not only did I learn from industry leading experts, but the most valuable learning was from other developers. Having a wide range of experiences there meant you could not only learn but were also able to suggest and pass on practices. The majority of the learning was hands-on and interactive which meant that as a visual learner, I was able to keep up and make the most of the time I had.

Joe Prisk

Software Developer

When we were told about the possibility of a few days of no pressure learning to code better, I jumped at the chance. Having heard both Kevlin and Jon at conferences in the past, I knew they would both be great together.

I’d heard Jon talk about Cyber Dojo and have looked at it in the past, we nearly used this for Mob programming workshop that myself and a colleague gave, but ended up using something less code focused as it was for non-coders.

So I knew fully what it was about but never actually found the time to have a good play, one of those things you know is good but just never have time. This was an excellent time to finally have a good session and understand the benefits that I knew were there.

A big part of the focus over the few days was on working together in pairs, it’s how we work on a day to day basis, and proven it works, although it did highlight to me how excluding any prior knowledge from pairing can be a great thing. Generally, in day-to-day practice, it is not uncommon for half of the pair to have a larger knowledge than the other, which can lead to more of an education than pair programming. The aim was to write some code following instructions and prove your code using tests.

My first pairing we had different coding knowledge so met in the middle and rolled with python, a language neither of us had knowledge of. A lot of googling ensued, but as with any language the idea is always the same, this really highlighted to me how there is little difference at a low simple level like this.

We never had enough time to ‘finish’ what we were working on by design of the plan. Again to focus on the writing of the code and refactoring, rather than just getting it out and done. This in itself is an incredibly powerful thing to remember and puts you in a different mindset of the end goal. Reflecting on your code and refactoring forces you into better practices, something small that may not be an actual issue now when you or someone else comes back in 6 months is suddenly a minefield trying to work things out, purely because the extra care and attention aren’t spent in the first place.

A large part of the learning came from collectively and anonymously reviewing each pairs code, and approach to solving the problems. It’s always amazing how many ways people come up with to solve a problem. I felt this was massively valuable, as most of the time you are working on a problem it’s not one that has been done before, or certainly not how you need it to be done, having this vast collection of ideas pushed you to think outside the box, or join a few ideas together to come up with what you feel is the best.

Each time a problem-solving session came to end we repaired and attempted the same issue again, this solution that came out differed every time, this has great value in just starting again, and facing a problem with new insight and ideas of how you could tackle it again, not one that you get the chance to do in every day working environment.