Building the new Environmental Registry of Ontario
Editor’s note: Spencer Daniels is the Product Manager on the ODS’ first agile service redesign project with a ministry partner. You may have read about it. A beta version of the new Ontario Environmental Registry was launched in February — you can visit the new registry, and check out the old one (for now, both exist in parallel to one another).
Starting out as bulletin board system (BBS) in 1994, Ontario’s Environmental Registry was one of the first online public consultation platforms in the world. Last refreshed in 2007, a once indispensable resource for anyone following environmental issues in Ontario was showing its age — complete with dense technical language, a confusing layout and baffling search functions. As the Environmental Commissioner of Ontario urged in 2015, the registry was “ripe for an overhaul”.
Following Ontario’s new Digital Service Standard, we assembled a cross-functional team from the Ontario Digital Service and the Ministry of the Environment and Climate Change (MOECC), partnering to build a new Environmental Registry of Ontario from the ground up. Starting with user research that unearthed wide frustrations shared by both internal and public users, the team quickly built out personas and key problem areas to focus on before pivoting into alpha. Over a couple of months last summer, we ran a series of Google Venture inspired design sprints, where we built and tested high-fidelity prototypes weekly with real users.
As the existing registry fades away and the new one rises to take its place, we’re formally consulting on the new registry design, collecting feedback from users and building out new features on our freshly launched beta site.
Learn how our team overcame bureaucratic barriers to user-centric design, agile development and plain language and how starting small and working out loud set us up for success.
Working as a “small-a” agile team
The Ontario Digital Service is an agile organization and our product work reflects this — but we’re still growing, maturing and establishing our tools and methods. We’re not practicing true Scrum, and maybe, we never will, but we’re invested in bringing a creative, adaptive and incremental approach to all of our work. IT projects in the Ontario government, still mostly follow a waterfall approach, so this new way of working represents a pretty big shift. When we kicked off our alpha work at Sprint Zero, we adopted the mantra, “if it works, do it…if it doesn’t, don’t!”. Careful not to be dogmatic with our methodology, we still practiced some Agile ceremonies:
- One of the easiest to adopt is the standup. Daily standups are quick meetings where everyone “stands up” together (in person, or remotely) to provide updates on what they worked on the day before, what they are working on that day, and any blockers they might be facing. The standup exists to help surface any problems and identify workarounds. But when we were in the thick of design sprints, working through tasks as group, we quickly realized stand ups were a waste of time, so we stopped doing them until we hit beta.
- Sprints kept us moving forward and feeling accomplished. We plan every iteration out in advance, at the very beginning of the sprint. All the team members on the project (not just the managers and decision makers) are involved in the planning process. This is very important — because to be able to work together, all the team members need to be able to provide value and input from the very beginning and share in the vision for the sprint. We were adaptive in our sprint lengths too — when building towards our beta launch, our sprint lengths varied from just a few days to a couple of weeks.
- Sprint reviews are called “show and tells” at the ODS. These multidisciplinary teams are not working in isolation — they work with stakeholders, users and, in government, politicians and political staff. In a sprint review, the team will show what they accomplished in that sprint. During our show and tells, anyone who has an interest in what we are working on is invited to ask questions and challenge the team.
- Show and tells are part of “working out loud” and this helped keep all our stakeholders engaged every step of the way. These stakeholders included: the Environmental Commissioner’s Office, people from all over MOECC and the other ministries required to use the registry, environmental group and folks from across government who were interested in digital and what we were doing. We even had the Behavioural Insights Unit and political staff attend. The show-and-tells had a very open invite list — if you were interested in hearing about the project progress, you were invited. We used the show-and-tell to stay accountable — to our stakeholders and ourselves.
- A very important ceremony we practice at the ODS is the retrospective. A retrospective should happen for every agile project — in fact, they should be happening with every iteration. In the retrospective, the feedback is not about the product but the process being used. One of the things agile embraces is that we know we don’t always get it right — and we won’t always get it right. Failure is embraced in agile — if needed, we tweak the processes we are using to make sure we don’t repeat that failure. In a retrospective, the whole team shares feedback in a productive manner, to hash out what went well, what didn’t, and what to fix next sprint.
Why the team was able to do things so quickly: the deployment model
The team for this project was one of the first at the ODS to follow our deployment model creating an agile team by bringing together developers, content managers, service designers and a product manager.
When the ODS team assembled, we knew very little about the Environmental Registry. We spent a lot of time with the team at MOECC to learn about what it was used for and its history. Embedding subject matter and communications experts from the ministry gave us a better understanding of the ministry’s culture and the way it functioned. And since we completely took over a MOECC boardroom for a couple of months, we had lots of drop-ins from staff across the ministry checking out all our sketches on the walls and asking what we were working on and how we were doing it.
When the build team began turning out code back down at ODS HQ, we remained connected with our colleagues at the St. Clair office over Slack and daily video standups. Since we had one team maintaining the existing registry and another building a new one, that open line of communication is vital.
Because the team was self-directed and self-managing, we were able to make decisions we knew to be important: for example, we deferred the build of the search function to build other features important to internal users since they would be the first to be onboarded.
The only reason we were successful in building and releasing a beta site in just a few months is because the team worked so closely together. We co-located and co-designed our way through problems and grew tighter each sprint as we rallied behind a common goal: creating a better experience for our users.
Changing cultures and behaviour
Besides the facelift, one of the biggest changes to happen with the Environmental Registry was the introduction of plain language. If our users can’t understand our proposals and what we’re seeking their feedback on, they can’t provide meaningful feedback! Writing for the web using plain language is second nature to those of us in the ODS, but our partners in the ministries had very technical expertise and were used to writing niche, technical policy items.
This was perhaps one of the more challenging pieces of this project. Managing change is very important, and we worked closely with our colleagues at MOECC to visit executive tables, committees, lunch and learns, town halls and communities of practice to spread the word about what changes were coming.
We also worked with staff to start practicing writing in plain language. This was important change management and outreach work we had to do, and it involved understanding deep ministry cultures. Our ODS team and ministry teams worked together to train over 100 users, over a number of sessions in the art of plain language! We also held over a dozen Environmental Registry 101 sessions, to show ministry colleagues how to use the new features of the site.
What worked for us
- It’s important to get the right people involved and invested early on. For this project, we were working closely with the business owner of the project and the ministry’s IT team. We even had an IT project manager dedicated to the project!
- In alpha, we had guidelines for the way we would work together. We said that there would be no such thing as a stupid question, and that team members would build on each other’s ideas (using a “yes, and” approach).
What we might do differently next time
- We used the Google Ventures sprint model, and there were a lot of sprints happening too fast — it was 8 weeks of back-to-back sprints, and was stressful for the team). This risked team burnout, and now we know we would do it differently next time.
- We were working fast toward a deadline, and didn’t have time to build out a team that was more diverse, and representative of the skills available in the ODS team and of the users of the Environmental Registry (at some points, it felt like there were just too many dudes!). Next time, we will definitely spend more time to thoughtfully pull together a diverse team.
ODS secrets: the tips, tricks and tools that helped us be great
- We quickly learned that the Environmental Registry’s users are as varied internally across ministries as they are in the public. For us, creating personas focused our prototype development in alpha, our permissions structure in beta and guided our user tests throughout!
- Tools like Sketch were very helpful to our work, but some of the prototypes we built were so good, that we simply couldn’t replicate the functionality technically!
- Using GitLab allowed us to start building quickly. The site was already taking shape on local development boxes (aka our MacBooks) before our staging environment even came online
- Making our product accessible early saved time (and is an important part of the Digital Service Standard) Long before we released our beta to the public, we tested early templates with users that use screen readers every day
- Our weekly show and tell was a great way to work out loud, get feedback from a variety of vested stakeholders and to bookend each sprint (not before the retro, of course)
- Being able to be co-located with our team was awesome, because we were able to build camaraderie and culture. With each release — we had 27 before the new site even launched — the team responded with the bell icon in Slack. At some point in beta, we started using a real bell to celebrate a release with the sprint MVP getting the honour to “ring that thing!”
As the product manager on this deployment, it’s been a thrill to see what a small, dedicated and empowered team can accomplish. Our diverse skill sets placed an emphasis on content and service design alongside technology and enabled us to tackle problems holistically sprint by sprint.
At this stage in our organizational development, being “small ‘a’ agile” worked for us — an overly prescriptive methodology would have been a barrier to working quickly. And it’s important to remember that a product manager is not the boss of the project — rather, we practice leadership without authority, prioritizing work and relying on each team member to deliver their pieces. It’s that trust — trust between team members, trust from (and in) our organization and trust from our partners that propelled us from discovery to alpha to beta in just eight months.
And we’re not done yet. Stay tuned as we build out more features and start integrating additional consultation streams from the old registry. We’ll be incorporating user feedback and working out loud every step of the way.
Spencer Daniels is a senior product manager with the Ontario Digital Service. He believes that software, like people, is always a work in progress.
