Update: Being in Two (or more) Places at Once
In which we learn the difficult lesson that a big feature we’d punted on is more crucial to our users than we thought.
We started out this last sprint with a simple question:
How close are we to feature parity with legacy applications?
After all, we’d been barreling along, wrapping up features left and right. Collision data and reports? Check! Management tools for users requesting traffic counts? Check! We’d even started to iterate on existing features, based on feedback from usability sessions (a big thank you to all our users and stakeholders who made time for these!)
Except we’d conveniently ignored one thing: CRASH and FLOW, the two legacy applications MOVE aims to replace, allow the user to select multiple locations at once.
For a while, we’d assumed that this need could be addressed by making it much faster to get data from a single location, and by making navigation between locations easier. That’s fine for a couple of locations, but it falls apart quickly if users are looking at longer corridors — like the Eglinton Crosstown, for instance:
Moreover, we’re positioning MOVE as part of the future of mobility in Toronto. That future relies on proactive, holistic thinking about how people move through our city — and that’s really hard to do one location at a time.
🌹 Rose — What are we celebrating?
Shine and Maddy dug in for another round of user research, scheduling a whole bunch of sessions and sifting through a whole lot of feedback on short notice! This gave us some much-needed validation that adding multiple location support before production release was the right call.
In the meantime, Evan conducted load testing to estimate the performance impact of handling multiple locations: what can we do interactively right now, and what might require background processing and/or additional system resources?
Based on both user and technical feedback, we were able to chart a path forward, one that prioritizes small-to-medium-sized sets of locations within MOVE while leaning on Open Data for larger studies.
In the middle of all this, we had a few other notable wins:
- Open Data can now connect to the MOVE database, bringing us one big step closer to publishing collision and traffic count data!
- Big Data Innovation Team lead Aakash completed his CAB training! This means we can start the formal process of getting MOVE to production.
- Shine led an excellent remote design ideation session using Miro! It’s not quite the same as having a physical whiteboard — nothing is, really — but it’s much, much better than not ideating on designs at all.
- Evan shared how we handle large map-based datasets in MOVE in his talk Map all the Things with Mapbox GL at ForwardJS! (Video coming shortly.)
🌱 Bud — What are we anticipating?
We started out this sprint realizing we needed a completely new feature before release, and not knowing what that entails. After this sprint, through lots of user research and ideation and design mocks and feedback sessions, we have a much clearer idea of what multiple location handling might look like, and how we’ll get there. Shine has some high-fidelity designs out on selecting multiple locations, which gives us all a great starting point for anchoring the other parts of this feature!
Maddy worked with Merlin at Code for Canada to understand the Monitoring & Evaluation piece of MOVE: in other words, what we’re trying to achieve with MOVE, and how we know whether we’re on the right track. To feed into that, Evan and Maddy are learning more about web application analytics tools available at the City, and they’ve scheduled upcoming conversations to understand the integration process there.
📌 Thorn — What are we fixing?
We changed course very early on in the sprint, from “let’s get to feature complete!” to “oops, we need to do this completely new thing”. However, we didn’t update our sprint board to match this new direction! This led to a general sense that we weren’t getting anywhere — we were actually making lots of progress, but we hadn’t made space to acknowledge that.
We realized also that we’ve known about this feature for a while, but had always dismissed it as too Big and Hairy to make immediate progress on. It’s true that focusing on single-location flows early on helped us make headway on a complex problem. However, this focus then became baked into an assumption, one that we only just now invalidated. What if we had continued to production without realizing this assumption didn’t hold water? It’s good that we caught it now — but it also raises the question of whether we’re missing anything else.
💭 Final Reflections
It’s never satisfying to put the brakes on something you thought was nearly done and add more features to the pre-release list. That said, once we realized this was necessary, we moved quickly to question assumptions, re-prioritize work, and understand user needs in detail.
This is a great reminder that working in an agile, user-centered way is about continually being aware of your assumptions, and about seeking to validate or invalidate the riskiest assumptions as soon as possible. It’s also about being honest about what you’re actually doing, as opposed to what you planned to do. By being aware and honest, teams remain open and flexible in the near-term while still keeping medium-term plans and long-term visions in sight, and they notice early opportunities to improve those plans and visions.
So: here’s to a successful sprint, even if it’s not the sprint we thought we were in for!
