As good partners, our responsibility is to assist our clients to the greatest degree possible. Once we understand their short-term and long-term goals, we proactively look for opportunities to be better, make suggestions, and add value. It’s helpful for our clients to embrace dynamic thinking as well. The best way to make the most of the partnership is to stay open to the idea that every project begins with unknowns and that there are many paths toward your eventual success.
I’m not talking about scope creep—gasp! But I am talking about having an awareness and strategic approach that gives everyone involved—from your team and from Sparkbox—space to make suggestions, seize unexpected opportunities, and make sure that we’re maximizing the results.
As a project manager, one of my absolute favorite tools to encourage this mindset is project sprint retrospectives. Conducted at the end of each sprint, these retrospectives force us to pause, analyze, and reflect on how things went for the collective team (Sparkbox and our client). In addition to reflecting on how effectively we met our goals, we also take time to analyze how the work got done—because the healthiest partnerships produce the best results. Not everyone loves retros as much as I do, especially not at first. Asking team members to be honest, even vulnerable, can be very uncomfortable. But if done right, it’s the honest feedback and questions that get to the really good stuff—the stuff that can be sometimes difficult to hear but that results in action items that make the work better and the relationships stronger.
Noticing When to Pause
On a recent project, a pain point surfaced during one of our sprint retros. On this project, we handled our releases by spending a sprint completing the identified work and then pushing it to staging. In staging, the client would QA the work and then compile all feedback into a single card that we called “QA Feedback.” We would then address this card fully in the following sprint.
We noticed that QA Feedback cards were consistently larger and more complex than we would typically expect. It would have been easy for us to say this was due to the complexity of the work—we were building Drupal components flexible enough to support more than 100 different sites and clients with unique needs. However, our experience told us that this QA process seemed inefficient, and after seeing the trend, we asked if we could investigate.
Investigation Leads to Efficiency
In order to determine how to improve, we had to understand why we had so much QA feedback in the first place. We took a couple of days to explore QA cards from previous sprints, creating a simple spreadsheet to log our findings. Through our timeboxed investigation, we identified three categories of work that were showing up in these cards: regressions, bugs, and additional feature work.
We were able to take that learning, improve the project, and increase efficiencies in three ways. First, we were able to work with our client to gain a shared understanding of what a regression, bug, or additional feature is. This got all of us speaking the same language, which inherently leads to time savings. Second, we applied that knowledge to break up efforts into appropriate buckets of work. More specifically, individual cards allowed the client to more clearly prioritize and deprioritize work. And finally, bulking cards into natural efficiencies helped save developers from context switching, instead allowing them to get into a flow and saving tremendous time.
The biggest takeaway here is that all of our investigative work ultimately led to a more seamless and empowering QA process for our client.
Retros are intended to tackle tough issues. On this project, there was a pain point to both Sparkbox and the client that needed to be addressed. Analyzing the issue yielded a wonderful and productive conversation with the client, and it fostered increased trust, stronger communication, and better work. This is exactly what we mean when we talk about partnership.
On your next project, consider incorporating retros, pausing when you hear a pain point, and letting it guide you to look for new answers and potential process improvements. Pain points may take time to dig into, but this process will save even more time and improve your outcomes in the end.