& Continuous Learning

On any given team, lots of time, effort, and thought goes into determining the team culture. This includes Agile practices and ceremonies, the discovery process, collaboration strategies, and communication with stakeholders.

A high-priority project with a tight deadline can disrupt these routines. Some practices will need to be shelved until things calm down, and you will need to change the way you approach your work and communicate with your team. Which practices are important? What should you focus on to overcome the chaos?

Our team recently went through a very chaotic time while working on a high-priority project related to COVID-19 vaccinations. Our team consists of eight developers, a dedicated QA, a designer, and two product owners, but we doubled in size at various points of the project as we pulled in outside help. We worked on the project for about two months before it went live, and continued to add features for the next six months while its usage increased dramatically. Our application grew to serve millions of page views per month with thousands of concurrent users and assisted in getting over one million people vaccinated. Here are some of the lessons we learned along the way.

Be empowered to change your team’s Agile practices

Our team's typical cadence was thrown off, it felt like we were starting a new sprint every three days. We weren't able to wait for our sprint cycles to end to do releases, planning and demos. It was also hard to get everyone together to do a retrospective. If you face the same situation, don’t worry about conforming to all of your typical Agile practices if they aren’t bringing value. Shifting to a Kanban-style backlog will allow your team to be more flexible. Create informal mini-retros and tweak your team’s processes on the fly instead of waiting for a scheduled meeting to happen. Iteration is extremely valuable in these situations. For example, our team’s standups were getting very long due to the amount of developers we brought in to help out on the project, so we decided to have one person give an update for each feature that was being worked on.

Don’t be afraid to reorganize your team to match the funnels of work that are coming in

In normal circumstances a lot of time is spent making sure everyone on the team is caught up on the work being done. For example, making sure everyone understands the database schemas, API surface, business logic and the interaction among features. This was not possible for us during our project since there were too many features that needed to be worked on in parallel. Instead of spending the time to keep everyone in the loop, we decided to split the team to match the streams of work that needed to be done. We called these feature squads, and they helped us stay focused on our work and reduced the amount of communication that needed to happen to move a feature forward. We had to be OK with not knowing everything that was going on and trust each other to make the right decisions. This made us more efficient and focused in the short term, but had a cost as silos formed. As we got time, it became important to catch up on what was going on elsewhere in the project in order to keep on top of the big picture.

Communication feedback loops

It may feel natural to jump straight into the work on a time-sensitive project, but take some time to plan the internal and external team communication. Slow communication feedback loops will compound the stress of the situation. Address these early on.

Minimize the number of people each teammate needs to talk to so that they can stay focused. However, if you’re repeating the same conversations with different people then communication isn’t flowing efficiently. Not only does this slow the team down, but a different audience may bring up new considerations which forces the discussion to cycle through the team again. Or worse yet, these communication hops open up the possibility of the message changing.

Include as many knowledge representatives as possible in every important conversation. For example, discussions about a new feature should include a PO, a developer, a business stakeholder, a designer, etc. to make sure each domain is covered. Also, provide frequent touch points with key stakeholders so they can effectively communicate progress to the business and ensure that the correct thing is built.

Expect to put on your PO and Delivery Lead hat while working on features

There will be little time for discovery before work begins for a feature. The normal expected level of acceptance criteria and detail in the story description will not be there. This means the developer who picks up the story will need to show grit and do the discovery work. This could include identifying an appropriate stakeholder to ask clarifying questions, talking to a UX resource to get an idea of how a screen should look, and white boarding with another developer to bounce ideas for the technical design. Many of these people may not have time to spare, in which case the developer must make and document some educated assumptions and start on the work. Once the work is started, the developer must listen for clues that would change what they are currently working on.

Make the priority list highly visible

Our priorities changed as the environment changed around us, and having a highly visible priority list enabled the team to act autonomously. There were times when state and federal vaccine policies announced the prior night or midday needed to be addressed as soon as possible. One of our POs would accordingly post the priority list to our team chat twice a day: once in the morning before standup, and once in the afternoon. The PO emphasized changes in the list and flagged items that required urgent attention.

Make the priority list focused and actionable

Initially, all future work was combined into a single virtual white board and priorities were pulled from this board. However, there were dozens of possible features and enhancements, many of which were ill-defined. Trying to keep a rigid priority of these numerous items was time-consuming, and it hindered team momentum when an ill-defined item was grabbed. Normally, we allow time in our sprints to work on “spikes” (work that requires more discovery) but we found the team worked more efficiently when only the immediately actionable items were shared. Ill-defined future work stayed on the virtual white board until it was further groomed.

Understand the difference between priority and value

There were occasions when the highest requested features weren’t on the priority list. These were high-value features but they weren’t the highest priority. Typically, these items required a large amount of work or the solution wasn’t immediately obvious. Making these the highest priority tasks would have blocked the team from completing numerous other tasks with high aggregate value. For example, early in the project a highly requested feature was to hold/reserve vaccine time slots for customers while they completed the consent form. We did eventually deliver this functionality but not until several months after the initial release. Providing this functionality took several weeks of effort that we couldn't afford initially.

Provide a single entrypoint for work

When we were getting started with our project there were many essential business stakeholders that provided valuable input to the team. At first, this input came through various channels such as emails, DMs or group chat messages, and virtual meetings. Under our normal pace of work it’s easy to relay this information to the rest of the team, but when everyone is heads-down and moving quickly, assembling a team discussion was a scheduling challenge. Important information was lost, and ambiguous priorities added to the stress of the team. We eventually agreed that the priority list was the source of truth and to weave desired actions through the priority list.

Don’t forget about tech debt

While working at a high speed on a critical project, a team is more likely to create tech debt than fix it. However, it can be crucial to put some thought into which tech debt issues could come back to bite the team in the near future and prioritize them. Our team realized that some of our older infrastructure may not stand up to the high traffic we would see once our project was released to the public. We were able to migrate to newer infrastructure in time because we identified the potential issue early on. As the project goes on and more tech debt is accrued, keep a list of things you’d like to go back and fix up once things slow down. We asked our stakeholders for some dedicated time to work on tech debt after the project slowed down and it allowed us to clean up a lot of issues.

Lead with empathy with your teammates

Everyone is stressed. Check in on your teammates and ask how they are doing. It is important to have a blameless culture in these times. Things will slip through the cracks. When they do, don’t point fingers. Make sure everyone on the team feels comfortable asking for help. Problems are less likely to be swept under the rug when everyone feels like they can share issues without being reprimanded. Teammates regularly had one-on-one conversations after late nights or early mornings. It helped to know each other's headspace, and it provided an opportunity to encourage one another.

Check in with yourself

Avoid burnout. Attempt to disconnect and avoid 16 hour days even amidst chaos. Do your best to unplug at the end of each day and on weekends.

Reset once things slow down

It is important to recognize that some of the practices and strategies we’ve described are not sustainable in the long term. After the chaos started to subside for our team, it was helpful to have a reset meeting to talk about how to get back to a normal working environment. The transition took us some time, but it was useful to call out the things we were doing because of the situation we were in, and to talk about how we want to work in an ideal environment. This is especially relevant if teammates have joined during the chaos and have never experienced how the team works normally.

Take the lessons learned in this post as guidance, not as law. Working on a chaotic project can be a dizzying experience. The chaos will bring stress and alter the dynamics of the team, but try to embrace these changes. If your current practices are causing friction then take a new approach. This isn’t a sign that your current practices are bad, but they may be misaligned with the challenges of the new, temporary situation. Adjusting your mindset and knowing what to focus on can make the difference in achieving a rewarding outcome.