Re-architecting the Sprint Demo for a Growing Engineering Team
This year, Conductor adopted a new method of showcasing engineering accomplishments that promotes interdepartmental communication. Twice a month, we engineers put on our orange t-shirts, and go to the Conductor Café to speak about what our team has worked on most recently. Engineers take this opportunity to learn what other teams are focused on, share anecdotes, and find opportunities for increased efficiency. Our sales and Customer Success teams use our demos to learn more about the development process, ask questions about upcoming features, and provide feedback on our efforts to create a scalable and reliable product. Throughout this process, engineers are challenged to express the value of their work without speaking in code.
Reimagining our sprint demo
That isn’t how we used to demo.
When I first started at Conductor, the engineering department came together to discuss our progress in a conference room. We had nine engineering teams and each of them had an allotment of time to use to present their work. The sprint demo meeting was a way to stay in touch with the other teams while sharing the challenges and accomplishments of our own. It was a long meeting because we had a lot to get through, and sometimes presenters got lost down technical rabbit holes. It was hard to keep the meeting short as the team continued to grow and as new features were developed rapidly. We knew that despite it being awesome to see each team producing and sharing great work, the means of communicating that work were not doing it justice. So I decided to do something about it.
First, I asked myself what value I wanted to get out of a sprint demo. For one thing, I knew I wanted to be able to have meaningful conversations with my peers. We often naturally get lost in our own code and projects, and we forget to communicate the bigger picture to each other. However, it is important for the whole team to stay in sync, not only to understand how our own efforts contribute to a better Searchlight, but also to appreciate the work of other teams toward that goal — whether that means increasing our end-to-end test coverage, scaling the capacity of our new architecture, or designing and implementing new client-facing features. Also, I believe that it’s actually necessary to allow people to go down those technical rabbit holes or open up a lively debate, but only when the audience is appropriate. For example, I should be able to get into an in-depth discussion with another engineer about their feature and find out how to reuse some of their code for something my own team will be working on. Finally, I knew it was important for us to engage with the rest of the company and no longer confine the team to giving presentations in a conference room.
C3: Let’s share our awesomeness
While I was working on re-imagining the team demo, all of Conductor was busy preparing for our annual customer conference, C3. This was my first C3, and I had little idea what to expect. However, I did know that I would get the chance to spend an hour each day presenting Searchlight’s latest features to our customers. Having the opportunity to speak with customers during C3 is quite a unique experience for Conductor engineers. It puts our communication skills to the test, since we have to express clearly the value of what we do. As an engineer, I admit that I did not always think about the value to customers of our work, because I was concentrating mostly on how the features I was building should be implemented. My experience presenting my work in person at C3 revealed another important and challenging facet to delivering software that meets the needs of users. Shortly after the conference, I realized we could do something similar in our office with our colleagues.
The engineering sprint demo v2 in development
I wrote a few proposals that detailed a new sprint demo format and shared them with my team, my manager, and the VP of Engineering. After two months of feedback and revisions, we got everyone aligned around the idea of bringing the C3 experience back to our office. The re-architected sprint demo has four components:
- Sprint highlights: Each engineering sprint team provides a short summary that explains what they’ve accomplished during the previous sprint. Those summaries are compiled into an e-mail and sent to the whole company.
- Each team sends at least one representative in their orange C3 t-shirt ready to showcase their work at the demo stations. Each demo station has a fish bowl, a printed placard with the team’s sprint highlights, and an engineer ready to demo.
- Fill the fish bowl! The sprint demo audience votes for the team with the best demo by placing a card with their name on it in the team’s fish bowl.
- The two teams with the most votes get a free lunch from the restaurant of their choice. While eating lunch, the winners are encouraged to reflect on how they can continue to provide their fellow Conductors with a meaningful sprint demo. They are also joined by one a sprint demo attendee from outside the engineering team, thus giving that person an additional opportunity to engage with engineers and discuss the work they’re doing.
Conductors in sync
The response to the new sprint demo format has been overwhelmingly positive. Since implementing it, several engineers have told me that they enjoy attending demos because the new style gives them a more active role. It forces them to think about how they can express the value of their work to people with different levels of technical fluency. Also, those engineers that are not presenting have the choice to watch the demos of the work they benefit from most or have an active interest in. Sharing the sprint demo with the rest of the company has dramatically increased the insight into the projects the engineering team is currently working on. It also allows people to understand the work that goes into releasing new features, improving the quality of our products, and providing Searchlight developers with high-quality reporting. And our sales and Customer Success teams feel more equipped to communicate updates to our clients and prospects. On the whole, we are helping each other be more excited about the work that we do, thus making our jobs more rewarding.
It’s an iterative process
Now that I’m hosting the team demos, I regularly ask for feedback on how we can continue to improve them. In order to prevent the process from becoming stale and irrelevant, I believe it is necessary to adapt our demos to suit our changing needs. In order to do this, I circulate small surveys and hold meetings to solicit different perspectives. I’ve already implemented some changes based on my colleagues’ responses, and I hope to continue to do that as long as it’s feasible. Just like programming, this is an iterative process!
