Update: It’s all Downhill From Here

Evan Savage
MOVE Project
Published in
6 min readJul 21, 2020

In which we keep the momentum going, and try to look out past the hill.

Another sprint down, another sprint closer to our medium-term goal: getting a version of MOVE into production.

To me, agile is about embracing the contradictions at the heart of modern creative work. You need a plan, and you need the flexibility to break it. You need a broad vision, and you need incremental in-the-weeds progress — and you need to constantly validate both the vision and your progress.

Our last couple of sprints have largely been about breaking previous plans — plans that told us we were ready to launch — and stepping back so that we could reform those plans around an understanding of how our users need to handle multiple locations at once. This last sprint, and the next few, will bring that understanding to reality through a lot of day-by-day, step-at-a-time work.

At the same time, we’ve crested a hill, and that means a new vantage point from which to think about what’s next. What does version 1 look like, and how can we validate that? What happens after version 1? Why are we doing this at all?

🌹 RoseWhat we’re celebrating

We started off strong by getting the first of many approvals needed to deploy to production at the City, and finished strong by deploying the first chunk of multi-location features to our AWS development environment! Here’s that last piece in action:

Corridor along Eglinton from Caledonia Rd to Black Creek Dr, in MOVE.

(You might recognize this corridor.)

Meanwhile, Maddy’s hard work around Monitoring and Evaluation (M&E) is starting to bear fruit! The M&E approach we’re using (with credit to Merlin at Code for Canada) is framed around a series of M&E stories, which start with a problem statement:

Story 1: MOVE replaces legacy software. The problem is that legacy systems CRASH / FLOW don’t meet staff needs; the goal is to improve upon those tools to reduce manual toil and increase capacity for proactive decision-making.

The “how might we” part is anchored in a simple flowchart, which shows how team outputs could lead to changes in capacity and behaviour, and how those changes could create both immediate and long-term benefits:

Story map for our first story, the one about MOVE replacing legacy software.

Could is the operative word here. At right in the story map, there’s a column that details the assumptions at each stage of this journey — without these assumptions being met, the changes that could happen probably won’t. By getting these assumptions out in the open, stakeholders can align around what needs to happen to make this vision a reality.

But wait! There’s more! Under Shine’s leadership, we’ve established a solid cadence of design critiques.

Definition: A design critique refers to analyzing a design, and giving feedback on whether it meets its objectives.

A design critique usually manifests as a group conversation with the ultimate goal of improving a design. It does not mean simply judging a design.

In a design critique, designers put unfinished designs in front of the group for early feedback. This takes a lot of intentional work on all sides. The designer has to be comfortable with presenting their work before it’s done. The group has to engage in open and honest conversation. Most importantly, this all must build on a shared understanding of user needs and goals, as gathered through user research and usability testing.

The end result is an excellent set of designs, arrived at with both internal and external feedback, created to meet user needs. Here’s one screen from that:

Screen showing the interface for selecting multiple locations, and routing a corridor between them, in MOVE.

This is just one screen out of a few dozen — and even this one screen shows the result of several decisions. When the user routes a corridor between selected waypoint locations, what does that look like? How do we textually describe a multi-location selection?

🌱 BudWhat we’re looking forward to

When the lockdown started, it came with a new set of priorities for the City. As the gradual reopening of Toronto and Ontario continues, those priorities have shifted, so that there’s now much more capacity than there was even a couple of weeks ago for non-COVID-19-related work. This means that we can now restart conversations with Technology Services Division (TSD, formerly IT) around some of the pieces needed to make MOVE a reality!

On the design front, Shine’s been exploring Framer as a tool for building mid-fi interactive prototypes. Multi-location development will take a few weeks — but in agile, that’s too long to wait for feedback! By building interactive prototypes, we can continue to get meaningful feedback from users to validate that we’re on the right track.

Screen showing mid-fi multi-location prototype, built using Framer.

As we chug through multi-location development, we’re also starting to think out to version 1 release, and to the longitudinal testing we’ll need to do beforehand. To get the most out of that, we need clear metrics and analytics from MOVE — and thinking about metrics and analytics is itself a clear sign that we’re actually getting close, for real this time! Even though the last-mile (last-kilometre?) work to get to production isn’t always glamorous, it comes with the reward of knowing your release is just around the corner.

📌 ThornWhere there’s room for improvement

Despite all the progress on multiple fronts, version 1 still feels far away. We’ve acknowledged that there’s really two issues here: we lack a shared understanding of what remains to do, and without a way to visualize our progress we’re missing a clear sense of progress.

To help deal with both issues, we’re setting aside time this next sprint to build a burndown chart — a sort of low-tech progress bar to show what remains and how fast we’re getting there. By having our progress out in the open, we can see that we are making progress, and we can align ourselves and others around realistic expectations for delivery.

Here’s one way to do a burndown chart:

A sample burndown chart, visualized as a bar chart of remaining effort (y-axis) vs. elapsed time / sprints (x-axis). It also includes an estimated completion date.

While this one includes story points and team velocity, the point is that you can see progress over time — however you choose to measure that.

As we plan towards version 1, we’re also mindful of the unique challenges this pandemic presents. With everyone working remotely, it’s harder than ever to engage with our stakeholders in a way that feels interactive and collaborative: it requires more energy than usual from everyone participating, and digital tools just aren’t comparable to physical tools in facilitating open dialogue.

That said, we still have to try! We’re working to build a larger pool of early testers, and we’re always trying out new tools and approaches for getting everyone in the same digital room. Digital whiteboards, note-taking apps, and screensharing sessions help, but non-technical approaches — like clear agendas and goals for sessions — are also important, just as they’ve always been.

Closing thoughts

If this blog post seemed long — well, that’s because it is, but that’s because we have a lot to celebrate, anticipate, and think about! I’m constantly amazed by how much our small team of three is able to accomplish.

As someone who’s worked with organizations large and small, it brings me back to an important realization I’d had a while back. Even if you could work every hour of every day, you can’t out-work the largest organizations — plainly put, they have more resources than you do. You have to out-think them and, in so doing, under-work them. As a small team, your superpower isn’t burnout and exhaustion; it’s listening better, focusing better, making tough decisions better, all so you can direct your limited time and effort towards the most important things.

So: here’s to our success in doing just that so far!

--

--

Evan Savage
MOVE Project

Co-founder of full-stack consultancy Savage Internet. 2018 Developer Fellow with Code for Canada. Currently improving Toronto’s transportation data systems.