Code for Canada: Toronto Squad 2018 @c4ctoronto2018 - Tumblr Blog

We’re Moving!

We’re moving our blog to Medium! This blog will remain up for historical purposes, but all its posts have been migrated over, and you can keep up-to-date with MOVE’s progress at our new blog location:

https://medium.com/move-project

Read on for more details.

Update: Foresight is 2020

One year ago, we were busy filling wastebaskets and tearing down post-its to tackle mountains of research on legacy systems used by dozens of stakeholder groups.

A year later, we have several prototypes, countless user tests, an alpha version, and multiple follow-up releases with key features under our belts. We have solid plans for the near future, backed by a vision for MOVE as an enabler of data-driven decision making. Most importantly, we have the runway to make MOVE happen, courtesy of an 18-month extension on the contract.

So: we’ve got a lot to celebrate, a lot to look forward to, and even better and bigger challenges on the horizon! Here’s to a successful 2019, and to an even better 2020.

Update: Vision and Validation

Above: preview of collisions heatmap in MOVE, which fades seamlessly into individual points as the user zooms in.

While we’re currently working towards feature parity with legacy systems CRASH and FLOW, MOVE is ultimately about more than just recreating those systems. How might we connect the big picture to on-the-ground issues and improvements? How might we enable new kinds of analysis and understanding around Toronto’s transportation network?

This is the first small glimpse into MOVE’s driving (and cycling, walking, etc.) vision: a near future in which City staff combine their expertise with state-of-the-art analytics, data visualization, and predictive modelling to make our roads safer for everyone.

In that vein, time for our (belated) Rose, Bud, and Thorn!

Update: Crash & ADFS

In this update:

We have a full team and are still forming and norming!

🌹 Rose (what are we celebrating?):

hey we have a fully realized team! How cool is that? As a first order of business Shine has completed a UX audit. It’s unclear when the right time to pull the trigger on these findings actually are at the moment but it serves as a helpful overview of the MOVE app. There was also a celebration of a fast ramp up. This is where we diverge slightly in that Ruth feels that she did not ramp up as quickly as she felt she should have. There was also celebration over a new path forward that is a more proactive approach. Jesse and Aakash feel that there are a few more items that require clarity but we have important buy in on a general direction.

🌱 Bud (what are we anticipating?):

We’re anticipating more reports as we dive deeper into Crash. There are also some timezone issues to tackle which may not be a very straightforward activity. Shine is about to embark on a UX study to get feedback and we’re anticipating our first release.

📌 Thorn (what are we fixing?):

ADFS still remains outstanding and we’re hoping for resolution on that soon. There’s still some murkiness on who’s who in the Transpiration services organization as the reorg continues. There is also a lot of confusion and information overload being new and ramping up for both Ruth and Shine since they’re so new. Ruth also feels that having unrealistic expectations of being fully ramped up right away may not be super helpful.

Thoughts/Reflections:

It feels like in many ways things are coming together and rubber is hitting the road so it’ll be exciting to see what happens as we go live and get this app into user’s hands.

Update: Flow Reports, & New Designer - oh my!

In this update:

Hey we got a new intrepid UXer!

Welcome Shine Chaudhuri!

🌹 Rose (what are we celebrating?):

Our celebrations are focused mainly around on-boarding once again. There were a few small things that I (Ruth here) found during my on-boarding process. This primarily includes the right articles to start out reading and what they branch off into to help make better sense of the domain overall. We also found that on the first day it’s incredibly beneficial to get Aakash and Jesse’s time nailed down to discuss their vision as C4C and BDITTO move forward together.

🌱 Bud (what are we anticipating?):

We’re still anticipating ADFS and what it will take to get authentication going. This will allow us to cap off the Data Supervisor requesting flow. If we can’t get ADFS, we may be able to make forward progress on CRASH. We are also anticipating our computers. ;)

📌 Thorn (what are we fixing?):

We’re trying to work on getting better visibility and understanding of the Corporate IT processes. We also got some feedback on the new story map and feel that it needs to move in a more proactive vs reactive direction. This means that priorities may need to shift and more discovery may need to be done to get a sense of what new requirements will emerge.

Thoughts/Reflections:

It’s really great to have a fully rounded out team. I feel as though we need to work on better alignment moving forward on the 18 month plan. It feels as though these are the right moves we needed to make during the fellowship but as a long standing piece of software it must encompass the new evolving needs of vision zero which the currently scoped solution doesn’t service.

Update: Two Heads Are Better Than One

In this update:

Hey, wait, this isn’t Evan!

That’s because he just ramped up our new Product Manager Ruth Birman.

Evan got me up to speed while completing several tasks, as well. Go, Evan!

🌹 Rose (what are we celebrating?):

Our celebrations are focused mainly around onboarding. Everyone has been incredibly patient while I get up to speed on the overall domain. As a newbie PM, I dug into Flow to see what generating the reports is really like.

I spent some time on day one with Evan, Jesse and Aakash. I went back and re-read the PM Onboarding with renewed understanding and context. This allowed me to actually to a few tasks somewhat competently week one.

Evan introduced me to IT. This enabled me to take on follow-up tasks. I followed up with IT on authentication and role-based access, which will become critical for our next epic.

We identified an opportunity to split the collision reporting work into two phases. The first phase includes the collision data to create warrant reports. The second phase focuses on implementing the remaining collision reports.

Thanks to Evan for being such a great onboarding buddy!

Additionally, he managed to get the warrant reporting started, conducted in-person usability tests and implemented the feedback.

🌱 Bud (what are we anticipating?):

We’re expecting that a designer will be joining us at the end of the week. This will allow us to have a tightly formed unit. Hooray!

We have some movement on authentication, so Evan is kicking off this sprint digging into that to see what else we may need to get from IT. From there, we’re going to continue on with the reporting and usability testing.

This is well-timed, allowing the new designer and me to ramp up on the process simultaneously.

📌 Thorn (what are we fixing?):

A minor point that we still need to resolve is my computer. It’s not a considerable blocker, but not having it means that I have to find a PC to log into. In the interim, I’ve brought my own, which allows me to access several resources and continue to make meaningful progress.

Evan was also hoping that the reporting would be further along. Due to the short week and the additional time needed to ramp me up, it didn’t get as far he hoped. We’re focused on reporting as one of our big rocks to move this sprint, and hopefully, me taking on some of the non-dev tasks will lighten the load.

Thoughts/Reflections:

It’s pretty incredible to be a part of a project like this. We have the potential to make a huge difference here, and I can’t wait to see how much we can transform these systems over the next quarter. Thanks for having me, C4C.

Update: Reporting for Duty Sprint

In this update: reports and data processes mature slowly but surely, and we learn (once more) to expect the unexpected while reflecting on what that means for sprint planning.

Update: On the Download Sprint

In this update: picking the right tools, and using them the right way, is hard but rewarding. (Maybe hard and rewarding?)

Update: UX Cadence Sprint

In this update: learning to balance different roles in the interim.

Update: Bridge Kickoff Week

In this update: Flashcrow becomes MOVE, the project keeps going, and our first Rose, Bud, Thorn.

#retro #civic tech #agile #jobs

How do we figure out what to build?

Now that we’ve been building our product – called Flashcrow – for a while, it’s worth talking about something tricky: how do we plan what to build? We’ve got 12 user groups, and a billion possible priorities. We use three processes that feed into one another in order to get clearer on how to build what matters, for the users that matter, in the time we have.

The roadmap

It’s the thing that says what outcomes matter, and in what order you’re gonna build them. It’s pretty vague on timelines, but it usually says what’s gonna happen within the 3 months with some clarity, and it has a bunch of ideas and some good priorities for 3-to-9 months away.

The roadmap gets made from our vision: whereas a vision just gives us something to aim at, the roadmap adds some clarity around priority and timing to that vision. It makes the dream real, but still a little unformed.

The hypothesis dashboard

Sure, you might know what features a user needs – but what if you’re really putting an app together from nothing? You probably don’t know what they’ll look like, how they’ll fit together, or even which are the most important.

To solve those problems, you need something that helps guide your experimenting, that gives you increasing confidence and clarity over user needs, and that puts the focus on what you must do first. And that’s what our hypothesis dashboard did in the early stages of our product development. Sure, we don’t use it as much now that we’ve validated and falsified many hypotheses – instead, we’re leaning more on user stories and epics – but it was super important in getting us here.

The hypothesis dashboard was the way we turned hypothesis-driven validation into a process, backed by a kanban board. This is what it looks like:

Neat, hey? We can filter by what’s being validated (feasibility/viability/desirability), what slice of the product it could affect, and whether it’s ready to test (and should be added to our sprint plan) or already tested, in which case we’ll have to integrate its conclusions into our sprint plan too, or go back to the drawing board.

Which brings us to:

The sprint plan

The roadmap tells you what’s important, the hypothesis dashboard tells you what we believe about how to solve what’s important, and the sprint plan tells us how we’ll try to go and build it, based on our view of what we need to do now, and with the expectation that we’ll probably learn we’re wrong in exciting ways.

Because the sprint is where the rubber meets the road and all our previous beliefs will actually get tested, it’s also where we discover the ways we’re wrong. So the sprint plan can’t be that we’ll do everything on here, or that we should even try. Instead, we’re setting priorities based on a simple question: what do we need to do first in these next two weeks to accomplish what we must? And the goal of our sprint plan becomes: do the important stuff first, and find out if the plan is still right along the way.

When framed as “what do we need to do first,” it allows us to take the pressure off ourselves needing to execute on all the things we could execute on. We’ll start with some riskier stuff that’s important, in case we learn that our roadmap or hypothesis beliefs were wrong in important ways. And that’ll probably affect our sprint plan, maybe even getting us to reprioritize stuff or adapt to adjust in the middle of our sprint if it’s important enough.

The sprint is the place where we learn what to adapt to, and then we adapt. The sprint plan needs to ensure we’re not wasting effort in adapting to the wrong things, and gets us quickest to the learning part. In concrete terms: the sprint plan needs to make sure that we’re getting closer to a hypothesis dashboard that has helpful and validated hypotheses, and that our roadmap is accurate and well-prioritized so that we get closer to realizing our product vision.

What’s the work, then, that ends up on the sprint plan? Anything that we believe could do those things well: getting closer to the truth, and to the goal. Could be user testing, or a UI design exploration activity. It could be some preliminary backend coding around the map tile pipeline, or frontend dev. It could be some communication work to express our vision or roadmap to get stakeholder feedback. In a sprint, there are only ever a few pure “research questions” that we ask in order to directly falsify or validate our beliefs; most of the time, we learn that our plan is right or wrong by doing the thing we thought was right.

The other reason that anything can make it onto our sprint board is because our roles are interdependent, and as a team, there are many ways we can unstick one another and create progress for our whole product.

Without the structure of the roadmap and hypothesis dashboard, it’d be hard to know what “progress” means, making a sprint plan hard to articulate. But sometimes, you have to do that anyway: you might just have to start with a sprint plan but no roadmap, and the need to get you closer to getting a roadmap. Maybe that’s a topic for another post, though: how do you bootstrap an agile, lean team that doesn’t have an established vision or roadmap to work from? We’ve got a little experience in that now, too :)

Visual thinking isn’t just for designers.

Now that we’ve built a couple of prototypes and tested with users, we’re starting to think about how to move from prototype to working application. Part of that is working with actual data in the backend - but to do that, we first need to prepare the data for use in our application.

The middle diagram - the one with all the arrows and circles - was part of a meeting with the Big Data Innovation Team to discuss data preparation. That’s right: we tackled an abstract technical problem with dry erase markers and a whiteboard. (And we got some praise in return: “we should use the whiteboard more often!”)

By making a problem visible and tangible, we lower the burden on our working memory and get it out in the open where we can build shared understanding. By using a medium that’s easy to edit, we can quickly discuss and compare potential solutions. By working at the fidelity of sketches, we make it clear that these are just potential solutions, which helps remove the all-or-nothing planning pressure of traditional Word / Excel / PowerPoint workflows.

For the non-designers out there: how can visual thinking help you in your work?

Good products require good user testing. Good user testing means running experiments designed to test good hypotheses and assumptions. Good hypotheses and assumptions are falsifiable: you can design experiments to show whether they’re true or false.

This means being prepared to draw big red Xs beside your cherished ideas.

Team developer Evan meets Rick, his friendly neighbourhood crossing guard.

Rick is a retired CN Rail employee who works part-time as a crossing guard. This gives him a sense of connection to the community, and he enjoys helping children in his area stay safe as they walk to school.

It takes a village to maintain safety on Toronto’s roads! The School Crossing Guard Program works closely with both Police and Transportation Services to identify and staff intersections with heavy school-age pedestrian traffic.

The School Crossing Guard Program is just one small part of Vision Zero, which brings together many more divisions like Pedestrian Projects, Cycling, and City Planning.

Initiatives like Vision Zero operate within the context of broader policies, such as the City’s Official Plan. These initiatives and policies often unfold over years or even decades, outlasting the involvement of any one person.

It’s like the classic Powers of Ten video: as you zoom out, you realize exactly how much work it takes to improve a city of over 6 million people...

...and then you zoom back in, and you realize it’s all people working together to make things better, all the way down, a bit at a time.

On Process

This is the non-technical intro to a more technical writeup on our tech process and tooling, which you can read on the Savage Internet blog.

OK, quick exercise! Picture a software developer.

Now that you've got your own personal image of a bleary-eyed twenty-something hackathon wizard propped up by Monster-spiked cold-brew coffee as code scrolls by Matrix-style at a blistering 200 wpm, we'll tell you a dirty secret of the profession.

A quick photo of team developer Evan and his partner Valkyrie riding past Bloor / Yonge during the 2019 Coldest Day of the Year Ride! At their backs: about 200 other warmly-dressed cyclists, all enjoying the comparatively warm weather (it was a balmy -4°C!)

A common argument against expanding bike lane coverage in Toronto is that they’re wasted space in the winter. In fact, the Bloor lane averages 1700 cyclists per day in the middle of January, and 27% of people who cycle to Ryerson continue to do so in the winter (including 31% of students!) Cyclists make up a rapidly growing proportion of road users, so there’s every reason to expect winter cyclist numbers will continue to rise.

The need is here now - let’s build the Ten Year Cycling Network Plan and invest in a better, healthier, and more cyclist-friendly Toronto.

What does the aftermath of a week of research synthesis look like? Now you know! Lots of potassium and post-its involved, and at one point we may have installed a whiteboard? Who’s to say!

Now, we’ve got great starts on personas and user journey maps for many of our users. Next up, we’ll be validating our work by going back to the user groups and showing them what we came up with. Hopefully, they’ll identify with the characters we created the personas around, and be able to point out the gaps in our understanding of their work with CRASH and FLOW.

Trending Blogs

Recently Viewed Blogs

Code for Canada: Toronto Squad 2018