Update: Over the hill
Reflections on our sprint from June 22 — July 3
First things first, as of this posting, this is my 10th week with the MOVE project. Where does the time go? (Well, really, it went here and here and here.)
If you’ve been following along with our last few updates, Shine and Evan both wrote about multi-location. This is the we-almost-finished-but-wait-not-quite feature. With collision data integrated into MOVE, we were approaching the finish line on “feature parity” — the point at which we reach functional parity with the two existing legacy softwares — but then we learned that the ability to interact with and pull data from multiple locations at once is critical to achieve “feature parity”. We can’t launch MOVE and deprecate the legacy systems CRASH and FLOW until we build this.
The reason this feature is so critical: many teams at the City look at entire corridors or neighbourhoods for their analyses.
There’s a team that looks at the flow of traffic through a corridor and adjusts signal timing to improve traffic flow. Neat, right? They use FLOW to retrieve data to do their analysis.
For example, they might look at a stretch of Eglinton Avenue West between Black Creek Drive and Caledonia Road. Although I’m making this specific example up, this could be part of an analysis of the Eglinton Crosstown LRT and how traffic would be impacted West of what will be the station at Caledonia!
That 1.8 kilometre long route has (by my rough and non-official count) 18 intersections including the starting and ending ones, and 16 stretches of road in between, which we refer to as mid-blocks.
For that team, pulling data location-by-location is cumbersome. The ability to pull data from all 18 intersections at once will save them time and help them focus more time on their analysis to make our streets safer.
🌹 Rose — What we’re celebrating
This past sprint, we rounded out the last feedback sessions on our low-fidelity ideation screens. Shine spent most of this sprint head’s down synthesizing our notes from the feedback sessions and incorporating the learnings into high-fidelity designs.
Based on these more concrete high-fidelity designs, Evan planned out development work for multi-location to make it real, and committed the first changes to code!
Another big thing we’re celebrating: CAB! (No, not a taxi cab.) CAB — in the context of the City of Toronto — is the Change Advisory Board. This is the formal review we will go through before our software is implemented at the City. It’s important we pass all the checks (security, privacy, accessibility, user support plans, etc.) to ensure the City’s software systems remain secure, accessible, reliable, safe, and have proper support for users.
One of our fantastic partners Aakash submitted our preliminary change ticket for review. Thanks, Aakash! This gets us another inch closer to launch.
We received news that one of our big technical / policy blockers has been cleared! This will give us the ability to bring accident reports to MOVE — a feature that countless users have asked for, and one last piece that will prevent us from reaching functional feature parity with CRASH and FLOW.
Some other things we’re celebrating this week:
- Evan took some much needed vacation
- We (finally!) had our official monitoring and evaluation kickoff. With guidance and support from Code for Canada, we’re developing a monitoring and evaluation plan to assess the project’s impact.
- Multi-day Automated Traffic Recorder (ATR) reports is through initial testing!
- We’ve been waiting on some tech-related support, most notably a QA environment so we can get users to try out MOVE before we launch to production. This will de-risk the launch significantly. We’ve been waiting for a while now because of COVID-19 priority projects. But, excitingly, conversations are now on track to get our QA environment, and other technology needs, in place!
- We spent some virtual time together as a team hanging out outside of a work context!
🌱 Bud — What we’re looking forward to
- Our next two weeks will be an inflection point for the development side of multi-location. As Evan put it, we’re “switching from pushing the ball uphill to the ball rolling downhill” (and gathering momentum while it’s rolling!) — a reference to the Basecamp Hill Chart.
- Continuation of conversations to get our technology needs in place
- CAB meeting — where we might get initial approval from the change advisory board!
📌 Thorn — Where there’s room for improvement
Recently, we’ve been starting our retrospectives with thorns so we can discuss areas of improvement and develop a list of concrete action items (and end on a high note with our roses!). Not all things have concrete action items though, and that’s okay. Sometimes it’s about putting less-than-great things out there.
Sometimes things don’t go according to plan. Both Evan and Maddy reflected that their sprint loads didn’t account for planned vacation and unexpected time off.
Multi-location is a pretty big feature, and timelines are still not 100% clear. This creates an environment where it feels like a never-ending beast, and it’s difficult to feel progress towards finishing this monumental task. Evan suggested that more frequent releases and design reviews could help feel like we’re making incremental progress.
When we started remote work in mid-March, no one knew how long this would last for. We’ve seen many tech companies go remote. For us, it’s possible that remote work could be the norm through the end of 2020, who knows! We’re making more of an effort to connect as a team outside structured work meetings: Slack channels for water cooler talk, a drop-in video room to chat with coworkers.
Closing thoughts
Evan’s reference to the ball and hill analogy really resonated with me during our retrospective — different pieces are coming together that have been paused or blocked for a long time. It feels exciting to have momentum and lots of wins lately!
We have lots to look forward to.
– Maddy, Product Manager, connect with me on Twitter @madsewins
