Diving into the Digital Team backlog

A few weeks ago, the product and engineering members of the Digital team took part in a "Debt Bash."

Page Sections

Our goal was to take on technical debt and bugs that had been tiny thorns in the sides of us, other departments, and visitors to our sites. We (mostly) put our primary projects on hold and dedicated all four work weekdays (we acknowledge Martin Luther King, Jr. Day as a holiday at the City) to these jobs.

How did this come about?

Our team is responsible for maintaining a number of the City’s web apps and services, not the least of which is Boston.gov. Every City department is represented on Boston.gov. Aside from just providing information, residents have the ability to perform many City services, including:

paying tickets and property taxes
signing up for newsletters, and
getting notified of emergencies.

With a footprint that large, bugs are unavoidable. We’re always working to improve features for those who use the website, both inside and outside of City Hall.

Image for diving into the digital team backlog

While we maintain these existing systems, we’re building new features and products. We keep track of what’s currently in progress on our team wiki. We also have a public roadmap of what we’re planning next. When we’re running full steam on these new projects, it can be hard to prioritize small changes in other places. Even if a fix wouldn’t take long to write, the switching cost of going to another project can be very high.

One of the questions the engineering and product team asks itself when it meets each week is, “are there any experiments we want to try out?” We do this so that we can try out changes on how we work together without setting these changes completely in stone. If something seems to work in practice (the only way to tell) we may adopt it, otherwise we’ll stop doing it.

(Full credit for asking about experimentation goes to Kristen Johnson and Rich Paret of Crashlytics/Fabric/Firebase. We’ve based a lot of our process on their methods.)

Taking a week to focus on the lower-priority tasks that had been backing up was an idea that came directly out of asking ourselves that question.

How did we do it?

We scheduled the Debt Bash week a few weeks out to give ourselves time to prepare. We made sure our whole team knew about it, including our content manager and designers. Why? We wanted them to nominate issues and also be aware that there wouldn’t be any progress on other projects during the week.

We used an organization-wide GitHub Project to make a kanban board for the week. We could add GitHub issues from any of our repos to the project’s backlog. The product managers prioritized these issues the week before so that everyone could hit the ground running when the Debt Bash week started.

What did we get done?

Here’s a list of what we shipped during the week:

Moved our CodeRed API proxy app from Heroku to our new Amazon Web Services environment, paying down a bit of tech debt in our ongoing migration off of Heroku.
Added a Docker-based local environment for our Boston.gov Drupal installation so that developers — both inside and outside the City — can reliably get Boston.gov running on their machine in about 15 minutes. That used to take all day, if it even worked at all.
Fixed a bug that was incorrectly showing some properties on the Metrolist Lottery page.
Corrected the embed of the Tableau dashboard on our employee diversity page.
Fixed a bug in newsletter subscriptions that prevented new confirmation emails from going out if someone hadn’t responded to the previous one.
Improved help text on the city councilor map.
Enhancements for budget.boston.gov. This includes improving the existing infrastructure and making the process easier for us to create archived versions of past budgets.

We also made progress on:

Cleared out necessary disk space on our Drupal servers by migrating boston.gov's huge library of photos, videos, and documents. We moved this content to a more reliable and cost-effective storage space on an Amazon service called S3.
Moving search.boston.gov from a separate web app into Drupal.

How do we think it went?

At the next weekly sync meeting for the engineers and product managers, we talked about our Debt Bash experiment. Overall we were very happy to clear our schedules to address these issues.

We did hit one roadblock that affected how much we could get done. Two of our engineers couldn’t participate very much because they were standing up SuccessLink. This is a web app that helps young people in Boston get summer jobs. Since the SuccessLink program operates on a fixed schedule (we can’t push back when summer starts!) registration has to start in February. With that deadline fast approaching, we couldn’t put that project on hold like we did the others.

Overall, we enjoyed the Debt Bash experience and will keep doing it going forward. We’re planning on starting with an every-two-months schedule, but we’ll experiment and fine-tune things as we go.

The Digital Team is always exploring ways to make improvements in our workflow. Regular Debt Bashes are just another way for us to become more agile and efficient.