Menu

The road to Firefly 6, part 1

Recently, Robin, Viv and I had the honour of pushing the (literal) big red button that would enable our clients to upgrade to Firefly 6. Champaign corks were popped and pizza was enjoyed by the whole team before we, very quickly, very diligently, returned to work.

Robin, Viv and I gather around the beautifully designed button to activate Firefly 6 in our offices in Hammersmith, 12th December 2016
Robin, Viv and I gather around the beautifully designed button to activate Firefly 6 in our offices in Hammersmith, 12th December 2016

Now seems like a good point to pause, and look back on the past eighteen months and the changes we made to our team, technology and working practices that 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 journey in time from the deep dark past of April 2015 right up to the present day. We learned a lot about how to build great software in this time, so I’ll talk about that at the end.

In part two (spoiler alert) I’ll talk about the changes we made to our technology stack and our design and front-end development teams.

Spring/Summer 2015

Back in April 2015 we knew roughly what teachers, students and parents wanted from the next version of Firefly. However, there was still lots of work to do to refine our ideas into a definite, 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, refined, and tested again.

Me doing some user testing at the Firefly Learning Conference in Birmingham, November 2016
Me doing some user testing at the Firefly Learning Conference in Birmingham, November 2016
An early sketch from a sketching workshop we ran at  the Firefly offices
An early sketch from a sketching workshop we ran at the Firefly offices

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 used to Firefly already.

Autumn/Winter 2015

While research and design were progressing nicely, thoughts turned to a busy conference season. With the Firefly Learning Conference just around the corner and Bett 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 in Firefly 6, 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 anyting our stand visitors threw at it, and I think its fair to say that everyone was suitably wowed.

Spring/Summer 2016

At the Firefly Learning Conference in November we’d confidently told our clients that they could expect Firefly 6 in the summer term. By the spring it was apparent that we couldn’t meet this deadline and release a version of Firefly that was of sufficient quality. So we took the difficult decision to delay the release to the next logical point where schools would have a chance to install it in-between terms: Christmas.

In the summer we we’re able to release the new navigation, and because it was now in the hands of schools quickly iterate it based on feedback from a large group of users. As with all changes, it was met with a mixed reception, 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 diligent work 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.

Almost all of Team Firefly at the Firefly Learning Conference in Birmingham, 15th November 2016
Almost all of Team Firefly at the Firefly Learning Conference in Birmingham, 15th November 2016

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?

Well, the reality is that we were releasing, every two weeks in fact. 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.

So why was 6 such a big release? Well, this was such a step change that there were several Epics that wouldn’t make sense in isolation. For example, the new Set A Task flow allows teachers to create rich tasks with far more flexibility than tasks they could create 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 have learned a thing or two along the way, not least that we need more development resource, but having just landing the largest Series A investment in Education Technology in the UK, we’re certainly now in a position to do that.

It wouldn’t have been possible to build such complex software with a relatively small team 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 less bugs.

We established Epics, Squads and Guilds

We spilt sets of features up into logic 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 UX’ers, 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 far more 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.

Firefly’s new offices at the Aircraft Factory, Hammersmith.
Firefly’s new offices at the Aircraft Factory, Hammersmith.
Joe’s old Raleigh Firefly bike in pride of place at the Firefly offices in Hammersmith, October 2016
Joe’s old Raleigh Firefly bike in pride of place at the Firefly offices in Hammersmith, October 2016

We established the Nine Rules

I think what we’ve learned can be distilled into a set of principles that we’ve refined throughout this project. These are Firefly’s Nine Rules:

  1. Frequent tasks should be easy and occasional tasks achievable. Teachers are incredibly busy, don’t give them a vast array of options.
  2. Use smart defaults. We make good choices, so users don’t have to.
  3. Don’t make me think. Make the next action obvious and unambiguous. Reduce unnecessary choices.
  4. Beautiful by default. Teachers want to be proud of the things they create, so make this easy for them,
  5. Optimise. Firefly should be fast.
  6. Do less. Firefly should do a core set of things extremely well.
  7. Design for teaching, not content management. Firefly isn’t a content management system, its a learning tool.
  8. Right feature at the right moment. Too many options are confusing, be smart about when we expose a new feature.
  9. Firefly isn’t just used in school Users should be able to achieve their task, no matter their location.

Where next?

Its 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 brings.