Surging – Remote Teams Working Together in Person for a Week to Make Magic.
Visual Studio App Center has a globally distributed team. We have teams from South Korea, India, USA, Denmark and more. With our distributed nature, we have used all the electronic tools and processes we can to try and enable all of our team members to have a great working experiences and be highly productive, regardless of time zone or location. We use Microsoft Teams, Azure Boards and many more. We also record Teams meetings so that people in other time zones can review them later.
With all that, we found that there were situations where we need to come together as a group and get specific projects done on a short time frame.
So, we adopted a new process that we call Surging.
A Surge is a weeklong event were a team of 15 – 20 people attend in-person and focus on completing a specific set of work. We most recently had a surge focused on making our user interface responsive, so that it could be used on mobile devices. This included refreshing the whole navigation design and updating the UI components for our entire product.
This perfectly fit our criteria for a surge and when we completed the surge in September, it was a huge success. The team had a great time, we shipped more work items than expected and a lot of people learned about a new part of our product. As we want to share this process with others, we have written down the guidelines for how to do a surge of your own.
Select A Project
We have found that these three attributes make for a good surge project.
- Swarm-able: It was something that 15-20 people could work on in parallel.
- Ship-able: With 15-20 people it could be shipped to customers in a week.
- Noticeable: It would have meaningful impact for our users.
Once the project is defined, you need to select who will be surging.
Select the People
Often times in larger developer organizations, there will be smaller teams that mostly work on specific parts of the product. In those scenarios, if a surge is focused on a specific part of the product, that team should be the “Host” of the surge. Then other people from other teams are invited to get to the 15-20 person count. When selecting who will join it is great to look at the work and see who can best help with the different items. It is also good to think about who would learn the most from joining the surge. Maybe you have front-end focused Surge and you want to invite a couple of backend developers to give them a chance to improve their front-end skills. Or maybe you have a new hire and it would be a great way for them to get to know others on the team. We also suggest having the owning PMs attend as well as 1-2 designers.
Another aspect of selecting who will attend the Surge is determining on who will work on what. For instance, our team does pair programing. We try to make pairs with one person who is on the “Hosting” dev team and one person who is new to this section of the code base. This part of planning will vary depending on your team and your project. Now that you have the people, the next step is to plan.
Plan, Plan, Plan
By the middle of the week before the Surge, all designs should be finalized and all work items spec’d out and approved. This will mean that the “Hosting” Product Manager and Engineering Lead will need to collaborate together and fully cost and plan out the work.Besides work items, planning also includes facilities, accommodations and fun events for the evenings.
We have found hosing a Surge in a hotel that also has a conference center has been most successful. That way people can both stay in the hotel and we can have our work room there. We cater breakfast and lunch at set times. This sets the cadence for each day. Breakfast at 8:30am. Standup at 9am. Lunch at noon and closing standup at 5pm.
Another attribute for choosing a location is to ensure the WiFi is good. We look for 50+ MPS and some hotels have an optional dedicated WiFi network.
While Surges are about completing work, they are also about team building. To make this a great team building experience, plan an opening dinner on the Sunday before the surge is to start. Then also plan dinners offsite for each day of the surge. It is important to let everyone know the dinners are optional as some people may need some alone time during the week.
Lastly in terms of planning, you need to make sure that all developers have their local developer environments setup. If they are moving to work on a different part of the code base, it may require some setup time. With the goal of them starting to be productive at the very beginning of the surge, it is important to require them to get their local environments setup the week prior. Now your planning is done, it is time to get to it!
Focus and Resolve Issues Quickly
It is Monday morning and your team is ready to go. The main thing now is to focus. This means no email, no customer support, no meetings. We have all of our attendees block out their calendars and we set the expectation with team members not attending the surge that the team will be effectively offline all week. This allows the team to really focus and produce high quality work.
Another learning we have from Surges, is that it is very important to raise concerns quickly.
If a team is blocked, tell people right away. The Product Manager’s role is to be constantly surveying the room and seeing how people are progressing. Then if there is an issue, work on resolving it right away. Some of our team have taken to getting red party hats for developers to wear when they are blocked. That way it is very clear that there is a problem.
Now you are in day 3 of the surge. People are getting into the grove with the project. You are already seeing parts of it come together. Some people are starting to get a bit worn out from the intensities of the days.
Now this is the hard part. It is time to update the scope of the project to insure it ships. Shipping means that it is actually in production by the end of day Friday. Not that it runs on this one person’s machine or it runs on our staging server, but a couple of our tests are not passing. I mean it actually ships to customers.
It is common to want to keep adding more features or refactor a section. This is when the PM and the Engineering Lead should see what they think the team can accomplish by Friday at noon. That way they can communicate that goal out to the team and have some wiggle room in case something goes wrong.
Then comes Friday afternoon, when everything is ready to be send to production, get everyone in a circle and click the button (check out Azure Dev Ops for your CI/CD) and celebrate with the team. We also like to go around the circle at this point and have everyone share what they worked on for the week and then celebrate all the great work that was done.
Closing the Loop
After your surge is done, it is now time to learn how to improve it for next time. We use the 6 hats retrospective format. This is a great way to learn and also check in to see how each team member experienced the surge.
So that is surging and our learnings from doing it for the past year. We think this is a great tool to add to the toolbox for remote teams. As it is our mission “to empower every person and every organization on the planet to achieve more”, we hope this will help you and your team in the future. Please let us know if your team currently “Surges” or adopts the practice in the future. Happy coding.