The team at Digital Theatre+ have just completed our first firebreak, and so it felt like a good time to scribble down a few reflections, discuss how successful it was for our team and whether it's something we'll be repeating in the future.
So, what's a firebreak?
A firebreak is an opportunity for a development team to take some time out of business as usual and flex their creative coding muscles. By the time we took our firebreak, the tech team at Digital Theatre+, had been working on the rebuild of our product for the past year and a bit, so for us a firebreak was a chance to take some wacky, outlandish product ideas that had been floating around in our heads and actually throw some time and resources into bringing them to life. Firebreak was an opportunity, to get creative, be innovative and have some fun without worrying about the pressures of delivering features and addressing bugs or tech debt.
You may or may not know that the title of this article is inspired by a song (We Didn't Start The Fire) in which singer Billy Joel provides his listeners with everything they need to know about history and popular culture from the twentieth century (I owe that A* in History GCSE to you, Bill). But, as the title also suggests, the idea of a firebreak didn't start with us. It's something teams have been practicing for many years, in many different forms. During my time at Founders & Coders our weekly project sprints were structured really similarly to how our team at Digital Theatre+ organised this firebreak.
If you want a more eloquent, descriptive summary of what a firebreak is, visit this link for an article ghost written by DT+ dev James Calmus.
What was the structure like?
It's well accepted that without a set of clear rules, fun just gets out of control. So, we started the week by outlining two key guidelines for our firebreak. First, whatever the team decides to work on must be linked to the general scope and vision of the Digital Theatre+ product. Secondly, all work must be completed within the allotted firebreak time - no crazy late evenings or weekend work allowed!
We decided to give ourselves a week for the firebreak, beginning on a Monday morning with idea generation at our usual stand up time. James, our dev facilitator, had prepared a Miro board where we could throw ideas onto a shared screen. Once we'd gathered enough project suggestions, we talked through them briefly and went on to vote on our top three. Votes collated, we had a really informal chat in between the four of us developers about what we'd each like to work on, and what style of work we'd like to do - mobbing, pairing or working solo.
We settled on working in two separate pairs. One pair worked on a synchronised video experience that allows users to play, pause and scrub videos in unison, which would be complimented by a chat room where users could discuss the videos they watch. The other (and my pair) decided to build a 'rich guide'. This was an opportunity to take the PDFs we have on our website and turn their content into rich text, which we could pop into HTML on a web page - similar to long reads that you find in most of the major news and journalism outlets.
Our other ideas are too good to share so we're keeping them under wraps - come back in six months or so and see if they made it into firebreak number two!
The rest of the week we kept meetings to a minimum. We started each day with a quick stand up to talk through the yesterday's achievements and today's plans, and then got back to work on our projects. We ended the week with a demo to the wider company and a firebreak retro, but more on that later.
What did we produce?
Our first pair built a video and chat room feature, with the idea of giving users control over videos in real time, while also being able to discuss content as you watch. Not only did they manage to allow users to play, pause and scrub video for themselves and everyone else watching, but they also were able to create what we called a 'teacher/student' relationship, where an admin user can control the video, but other users don't have permission to perform any actions on the video they're watching. This would be perfect for teachers assigning videos to students who are learning remotely, creating a allowing Oh, and they even had time to add a Giphy bot to the chat room, too.
The second pair took existing Digital Theatre+ content from PDFs and reframed them as rich text on a simple, HTML page. We had a hero image at the top of the article, with parallax scrolling of the overlaid title. Underneath that, we included a table of contents with sticky scroll, that also jumped smoothly to each heading within the piece of content. We included social media icons to allow teachers and students to share content easily. Within the body of the content, we added drop caps, indented our images with a negative margin so that they sat slightly outside of the text and also embedded video resources.
What was the feedback like?
We ended our firebreak week with two events. The first was a demo to the rest of our company - we hold a fortnightly demo during business as usual times anyway, so we used this recurring slot to show off our firebreak work. As most people on the call are non technical, we started with an explanation of what a firebreak is, its benefits, and also a huge disclaimer that none of the work they were about to see would be making its way into production anytime soon. We showed off the video and chat feature, and the rich guides, and both were a roaring success and received fantastic feedback from excited colleagues. The firebreak work got the wider company thinking about new ways to engage with and present our content, which is exactly what we'd hoped would happen. Our colleagues hit us with really insightful questions, ranging from child protection issues surrounding chat rooms to how teachers might use the rich guides for in-classroom discussions. It was great to see them so excited about our work, and we'll definitely be looking for ways to involve the rest of the company in future firebreaks.
Our second wrap up event was a closing ceremony retrospective just for the tech team, a chance to reflect on how the week had gone, and what we would do again or do differently next time we held a firebreak. We also used this time to discuss some of the more technical parts of each pair's projects, things we'd left out of the high level presentation we did to the wider company in our demo. It was really valuable to have this time to ask each other questions about the work, and take a closer look at the code, gawk at the lack of testing, etc.
Would we do it again?
Hell, yes! All four members of the DT+ dev team agreed that firebreak was a great chance to play around with our codebase and most importantly, a fun, relaxing way to spend a week after 14 months of focusing on the delivery of our rebuild MVP. Removing the pressures of business as usual and letting some creativity flow refreshed us as we prepared to enter a new stage in our team journey - post MVP feature development! A week was a good amount of time to spend on firebreak, and if (when) we repeat it in the future, I believe we'd want to stick with a week long event. As mentioned above, we'd love to get other members of the company involved in the future, especially as the ideas generation and design stage.
Big thanks to my colleague Kalle for loving my original title for this article (Relight my firebreak) and for also coming up with the even better one that I eventually used.
Top comments (0)