We're launching MOVE: Version 1.0!

On Dec. 8, 2020 at 2:16pm, MOVE Version 1.0 went live! ✨

We accomplished a Big Thing in a year where it felt like Big Things were on hold. And still, next to the 50-year project of digital transformation in government, it’s such a small thing: one piece of software, still incomplete (as all things are), in one division, in one city.

It’s been a long trail in a weird time, but we’re excited to share how we got here, what we learned, and where we’re going.

These days, it’s tempting to make everything A 2020 Story. Yes, the pandemic upended our lives and work processes, as it did for so many others in so many places. Yes, it will continue to do so well into 2021.

It’s worth acknowledging, though, that this effort stretches back far before 2020, and that it will outlive the pandemic. Since the second Code for Canada fellowship started in Oct 2018, we’ve had three different core MOVE teams. Those teams have taken us from the earliest glimmers of ideation and user research through countless prototypes, tests, and iterations to reach this point.

And even that is only a partial view. Before we arrived, Code for Canada and our partners at the City had been having the difficult conversations necessary to bring us on board for over a year. To convince a large organization — private or public — to break with traditional methods and try something new is no mean feat. Without their hard work, we never would have even gotten in the door.

This is something that the neat division of agile projects into phases misses. The hardest problem is not the technology, nor design and product thinking, nor even agile practice itself — it’s convincing the right people that you should be there in the first place, and that they should support you.

Without that, you have nothing. With that, you have the barest foothold from which to start earning that trust. Your job is to keep moving upwards, finding larger, better footholds, constantly securing a rope to help those around you climb up and share in your success.

Actively listening to users and stakeholders is trust. Delivery is trust. Open communication is trust. Documentation and knowledge sharing is trust. You may not be able to do all of this at once — but if you don’t do any of it, neither you nor anyone else is making it up that cliff. This was just as true before 2020. It will be just as true in 2030.

Of course, that still leaves the question: how did we adapt to a massive, world-changing event?

I remember one of the last conversations we had as a physical team, on the 5th floor at 703 Don Mills, in a small room offering views of an apartment building, the Don River, and Toronto’s downtown cityscape against an early-spring sky heavy with rainclouds.

The question in front of us that day: how do we prepare for full remote work? It wasn’t a question we’d anticipated, wasn’t in any of our roadmaps or release plans. We decided to try conducting our next usability test remotely. We set up a workstation for remote access over VPN. We listed the physical things — documents, office supplies, random notes and sketches — we might need to refer to. Made copies, took photographs.

We thought the COVID pandemic might last a few weeks, so to be on the safe side we planned for a couple of months. We shuffled tasks around on the board, moving up tasks with minimal outside dependencies, buying ourselves time to figure things out.

Looking back, I truly believe we did the best we could in that moment. Forget, for a moment, the apparatus of sprints and rituals and kanban boards. What we did in that moment is agile in its rawest form: we responded to the unknown by leveraging the known, and we trusted in our ability to keep learning.

Since then, we’ve experimented with several techniques and tools:

• Notion for sprint planning and retros, so we could run these;
• Miro for ideation, so we could sketch and lay out ideas;
• Figma for design critiques, so we could follow along with our designer’s commentary;
• Google Slides for presentations, so we could collaborate around a single slide deck;
• Webex for user interviews and usability tests, to continue getting key feedback from our users;
• OBS Studio, Kapwing, and YouTube for creating tutorial videos, to help onboard users;
• Kumospace for socializing, so we could manage larger group events without the usual videoconference chaos;
• Mentimeter for live polls, so we could add some interactivity to webinars and presentations.

There were challenges, to be sure, but also unexpected opportunities. Moving to digital-first work made it easier to keep all our work in one place. Virtual meetings with dedicated “chat monitors” and live polls meant we could get more feedback and answer more questions than we ever could in person.

In that sense, 2020 was the year of Computer-Supported Cooperative Work. We’re used to the idea that digital whiteboards aren’t quite whiteboards, digital post-its aren’t quite post-its, digital meetings aren’t quite physical meetings. Digital tools and processes may have important shortcomings when compared with their physical counterparts, but — as we’ve seen — they can also have clear advantages.

The most effective organizations are those that combine the tools available, both physical and digital, to create a more collaborative, inclusive, and well-coordinated environment. Thoughtful, deliberate tool selection and use is a superpower. This was just as true before 2020. It will be just as true in 2030.

Which raises the question: where to, and what next? As I write this, we’re planning our next couple of releases — one for end of January, the next for mid-February. These will largely be small, iterative improvements based on user feedback since launch.

Before we can completely replace CRASH and FLOW, we’ll need to include MVCRs (Motor Vehicle Collision Records) in MOVE. These are the original collision records from Toronto Police Services, and they present new challenges around privacy and security of personal details.

Beyond those features, we’re entering a new phase focused around the management of data pipelines. Transportation engineering at the City relies on data from dozens of sources: manual counts, sensors, counting stations, collision records, datasets from other divisions, public surveys, and so on. Much of that data never made it into CRASH and FLOW in the first place. Much of that data is siloed off: sitting somewhere on a paper form, or in a spreadsheet, or in a contractor or vendor portal. Breaking those silos is a change of process.

Version 1.0 is a major product milestone, to be sure, but it’s also a major trust milestone. We delivered something tangible, something that’s in the hands of our users right now. They can see it, feel it, use it. Real, tangible things are much easier to invest trust in than promises or processes — but without changing the process, you can’t have real, lasting change.

This has always been part of the civic tech approach. Pick a problem Big enough to matter, small enough to be tractable. Identify a specific pain point in that problem, and create a real thing Big enough to be useful, small enough to be delivered quickly. Use that momentum to create the trust needed to change process, both from the Big lens of vision and strategy and from the small lens of individual tools, techniques, conversations, collaborations.

Maybe this won’t be the approach that gets us all the way to the 50-year project — I’d like to think that, over the next few decades, it will be refined into service and policy playbooks; into mature design systems; into accessibility approaches for highly interactive content; into publicly-funded open-source tools; into open sensing / measurement initiatives; into meaningful global collaborations; into all of these things and yet others that will be enabled by the technologies and practices of the near-future.

That said, it’s working for now, and that’s a very small-a agile way to approach a Big Problem: respond to the unknown by leveraging the known, and trusting in our ability to learn along the way.