Redgate’s first Open Space Event
How’d you share new experiences and ideas within your organisation? How do you bring people together with interests in the same topic? These are really hard questions to answer, and at Redgate we’re always striving to improve the way we approach Learning and Development.
Today, we tried something new for us called an open space (also known as an unconference). The idea is that you bring people together, sprinkle some guidance and good stuff happens. Sounds magical right? (also sounds pretty scary!). Luckily for us, Ian Johnson had attended a few conferences run in this style and was on hand to set the scene.
The agenda for an unconference is driven by the participants and is in no-way predetermined. This is a pretty scary thing — would enough people turn up? Would anyone actually suggest topics? Thankfully, there was a great turn out!
It took about ten minutes to suggest the topics. I was amazed at the breadth of topics, from the technical (how can we use F# libraries to do property-based testing) through to softer skills (how does how we talk about quality affect our approach to it?), and to the slightly out-there (modelling message queues using humans!).
Andrea Angella has shared a bit more about his experiences of the open space event in the video below:
What did I learn?
We should explore Property Based Testing: Hedgehog looks like a great library for exploring property-based testing! Most of our code is written in C#, but there’s a lot of interest within Redgate on functional languages, such as Haskell and F#.
In 30 minutes, we’d hacked together a few property-based tests for a Minesweeper game. Definitely one to try out!
Auto-merging branches: We waste a lot of time with merging for “boring” commits (for example, renaming is safe right? If the tests pass then we should just merge!). If we had a mono-repo then this wouldn’t be an issue, but Redgate uses a repository per library. This means a change to a library can take way too long to reach our products.
We discussed whether we could find some automated ways of simplifying this, and it turns out loads of this already exists (Teamcity). Let’s try this out and see how it works for us.
Language of quality: There’s certain aspects of product development that are really easy to talk about, such as “when is it going to be done?” or “how long do you think that’ll take?”. If you’re an engineer on a team, it’s easy to fall into the trap of thinking that’s all anyone cares about. But obviously, that’s not true! Everyone wants a high-quality, easy to maintain product but they lack the language to ask the questions. What can we do about that?
- Talk about the value: If at a stand-up we say “we refactored” that doesn’t talk about the value at all! What if we said “we simplified X so that adding/changing new areas in the next sprint will be much easier”?
- Celebrate success: When we ship something amazing at Redgate, we celebrate! But what if we remove a dependency on a gnarly bit of code that makes us go faster? We should celebrate that too! (love the idea of the Golden Shovel!)
- Policies: You wouldn’t ship a car without wheels. You wouldn’t build a house without firm foundations. You wouldn’t build a product without XXX? The answer is different for each team (dependent on where it is on the product life-cycle), but if we were clear on the expectations they could be talked about as a first-class citizen, just like deadlines.
What next?
We gathered feedback and held a mini-retrospective (or at least, a somewhat structured chat with beer). The vast majority of feedback was positive (phew!) but obviously it wasn’t all perfect and there’s some great opportunities to do it better next time.
So that’s what we’ll do!
