This article is long and will take you on our Firefly 6 journey, from Spring 2015 through to early 2017. I recommend saving it for when you have some time, and reading it in a comfy chair with a cup of tea and cookies.
On 12th December 2016, Robin, Viv and I had the honour of pushing the (literal) big red button that would enable our clients to upgrade to Firefly 6. Champagne corks were popped and pizza was enjoyed by the whole team before we very quickly, very diligently, returned to work.
Now seems like a good point to pause, and look back on the past eighteen months. This includes the changes we made to our team, technology and working practices, all of which enabled us to release the biggest step-change in Firefly to date.
I’ve broken this article into two parts: This first part starts with the journey from the deep dark past of April 2015 right up to the present day. We learnt a lot about how to build great software in this time; I’ll talk about that at the end.
In part two (spoiler alert) I’ll look at the changes we made to our technology stack and our design and front-end development teams.
Spring/Summer 2015
Back in April 2015 we had an early idea of what teachers, students and parents wanted from the next version of Firefly. But, there was a lot of work to do in refining the details to create a definitive, focused list of features that would work for everyone.
As Head of Product, Viv ran a number of discovery workshops with teachers, students and parents from a large number of our schools. Armed with this research, our UX team was able to start sketching solutions from which we could create interactive product mock-ups. These were then tested with more users, then refined, and tested again.
We didn’t just limit this discovery phase to the start of the project, we continued to conduct user research at every stage. We’re lucky that our clients don’t mind acting as guinea pigs and let us test all our crazy new ideas on them. We also engaged an agency to connect with non-client teachers, students and parents, to ensure that the new features would work for everyone, not just those who understood and used Firefly already.
Autumn/Winter 2015
While research and design were progressing well, thoughts turned to a busy conference season. The Firefly Learning Conference was just around the corner and Bett was looming, we knew we needed something more tangible than interactive mock-ups to show people.
Bett, in particular, would be the first time clients and prospects alike could get hands-on with the new Firefly. We had to build a demo version of Firefly that would work well enough to give prospective clients a taste of what was to come and that would also be robust enough to work with the WiFi in the ExCel centre.
In a sterling effort by all involved, we cut a demo-ready version of Firefly less than 24 hours before the start of the show. Despite there being a few bits of hidden sticky-tape and string holding everything together, we had an amazingly successful Bett. The demo stood up to anything our stand visitors threw at it, and I think it’s fair to say that everyone was suitably wowed.
Spring/Summer 2016
Our initial roadmap had Firefly 6 scheduled for release in the summer term. But, in the spring term we realised we would not be able to release a product with the quality, functionality and robustness that we demand of ourselves and our schools have come to expect. So we took the difficult decision to delay the release to the next logical point when schools would have a chance to install it in-between terms: Christmas.
Nonetheless, in the summer we released parts we were happy with and had rigorously tested, such as the new navigation. Once out in the world, we could make changes based on the feedback from a large group of users. As with all changes, a few tweaks were requested, but the vast majority of users loved the changes we’d made.
Autumn/Winter 2016
We were now nearing the end of our development phase. A significant portion of both the web app and native iOS and Android apps had now been completed. We were on target for our completion date of 28th November, which would give us 2 weeks to do final testing before launch on 12th December.
Building software is hard. Building great software is very hard. So it was understandable that the final few weeks before our production deadline was filled with late nights and many take-outs in the office.
It is a testament to the talents of everyone involved that we brought this incredible new version in on time. Not just the team who built the software, but also the support, client experience, sales and marketing teams. They’re all responsible in equal part for Firefly 6.
Please release me, let me go
Even the most old school software companies release their software more often than every 18 months, so why did we take a year-and-a-half to release Firefly 6?
In fact, we were actually releasing every two weeks. We shipped 35 versions from 5.2.1 in April 2015 to 6.0.1 on 12th December 2016. These releases included a large number of bug fixes, and lots of new features and tweaks to existing features, which users were requesting.
So why was 6 such a big release?
Firefly 6 is made up of several feature sets that wouldn’t make sense in isolation. For example, the new homework task flow allows teachers to create rich tasks with far more flexibility than could be done in Firefly 5. Releasing this without any ability for students to respond to these tasks, or teachers then to mark the response was simply unfeasible.
Things we learned and changes we made
We’ve certainly learned a thing or two along the way, not least that to continue making our ideas a reality will require more development resource. Now having landed the largest Series A investment in education technology in the UK, we’re certainly in a position to do that.
It wouldn’t have been possible for our relatively small team to build such complex software without some smart ways of working. Over the last year-and-a-half we’ve made some big changes to the way we work, these help us work faster and release with less bugs.
We established Epics, Squads and Guilds
We spilt sets of features up into logical chunks. These we call Epics. An Epic is a set of features that makes sense end-to-end. For example, the new task setting flow was a single Epic. This included all the backend logic, and user interface elements for teachers, parents and students.
Each Epic is owned by team called a Squad. A Squad is a self-contained unit of user experience experts, designers, developers and a manager. Everyone who’s needed to research, design, build, refine and manage workflow for that one Epic.
There are parts of the product that are relevant to more than one Squad. For example, the Pattern Library is used by all squads working on the Firefly web interface. To manage changes and updates to these areas we have Guilds. Typically, a Guild will contain a representative from each Squad, and meet on an ad-hoc basis when changes are needed.
We moved
It would be remiss of me not to mention our new office. In October we moved from Lyric Square to the Aircraft Factory, in Hammersmith. We now have an amazing space that feels attuned to building brilliant software. We even have Joe’s old Raleigh Firefly bike (the inspiration for the name) in pride of place above his desk.
We established the Nine Rules
I think what we’ve learnt can be distilled into a set of principles that we’ve refined throughout this project. These are Firefly’s Nine Rules:
- Frequent tasks should be easy and occasional tasks achievable. Teachers are incredibly busy, don’t give them a vast array of options.
- Use smart defaults. We make good choices, so users don’t have to.
- Don’t make me think. Make the next action obvious and unambiguous. Reduce unnecessary choices.
- Beautiful by default. Teachers want to be proud of the things they create, so make this easy for them,
- Optimise. Firefly should be fast.
- Do less. Firefly should do a core set of things extremely well.
- Design for teaching, not content management. Firefly isn’t a content management system, it’s a learning tool.
- Right feature at the right moment. Too many options are confusing, be smart about when we expose a new feature.
- Firefly isn’t just used in schools. Users should be able to achieve their task, no matter their location.
Where next?
It’s an exciting time for Firefly.
We’re expanding our team, and we’re brimming with ideas for the future. We’re working closely with a wide array of our clients to shape the next iteration of Firefly. There won’t be a large release for a while, but that’s exciting in itself, it means we’re going to work on smaller features that we can get into your hands quicker.
I, for one, can’t wait to see what the next eighteen months bring.
