I love how Scrum emphasizes the idea of continuous improvement. Every Sprint, we hold a Retrospective, looking back at what went well (so we can do more of that) and what was a challenge (so we can avoid it in the future). The notion that we are never “done” applying Scrum is incredibly human and freeing. Basically, it’s okay to be wrong, so long as you acknowledge that fact and try new ways to be less wrong next time.
That said, another core aspect of Scrum that is a bit more slippery is the fact that, even when we feel we have solved for X or learned from Y, the time will come when our previous solutions need to be looked at critically and rethought or, possibly, thrown out altogether.
The quick win
To take a step back, I’ll share a problem my team faced a few years ago. While we hammered through our Sprint commitments week after week, we found a bottleneck happening at the end of the Sprint. Work was making it out of the development queue, but it was not being tested adequately to pass along to our various stakeholders. At best, this just meant a cursory, successful review, but more often than not, it involved rework on items we thought were done but, in reality, needed more effort applied.
In discussing this during a Sprint Retro, the team determined that our QA process was lacking. We all agreed on the What, and I was quick to offer a solution. Despite not doing web development work any longer, I remain fairly tech-savvy and offered to handle QA for the team throughout our Sprints from then on out. After all, sometimes, the fastest way a Scrum Master can remove an impediment for their team is to just do the thing that isn’t being done.
Bing, bang, boom — another blocker squashed. Huzzah!
Jumping to solutions
Now I felt for years that this outcome was a positive one — case closed. By being more involved in our work, I better understood things and could more effectively collaborate with our clients. Plus, since I was testing our work, I readily identified a need for better “How to Test” guidance following dev work. I asked this of the team and supported them in writing better testing instructions for every work increment. On top of all this, my involvement freed the team to move on to other tasks more quickly, thereby increasing our velocity. Win-win…..win.
But recently, in talking with another Scrum Master about QA, they pointed out that, in my QA anecdote, I solved for the What without spending time digging into the Why. Sure, I helped my team on some level, but was I truly solving the core issue? This SM suggested I was not, and now, after years of thinking I had put this to bed, I have to agree with them.
In classic John fashion, way back when I discussed our QA process with the team, I vacated the problem space too quickly. I latched onto a simple What (the team hasn’t time for QA) and applied a simple solution (I’ll do it for them). In short, be it impatience or a willingness to act or whatever, I pushed us all into the solution space, and, as the brunt of the effort would be on me to handle, the team went along with it.
It’s not like the team tricked me into a bad idea because the solution did help and was easy to implement. But, I now doubt it was the most beneficial action I could have taken.
Scrum-bergs
When we, as Scrum Masters, stay at the surface level, not bothering to dig deeper into team challenges, we run the risk of identifying (and focusing on) “small b” blockers. These quick wins are fairly trivial to remove, but more often than not, under the chilly arctic waves lies a “Big B” Blocker iceberg, ready to sink our teams.
In retrospect, what I ought to have done with my team is keep us in the problem space. “Why aren’t we performing effective QA on our work?” Possible explanations are myriad: There’s no time in our sprint because we have too much work to do. We don’t have the proper tooling to do this effectively. If we did more internal Demos, issues would be made visible while the work is still in progress rather than causing rework in the next Sprint. I did everything in the ticket but didn’t know about an undocumented expectation of the stakeholder.
And on and on the list would go. Each of these bullets is a possible impediment for the team, each having a very different potential solution. Who knows how much of a positive impact we’d have enjoyed if I hadn’t shoved us along to the solution space so hastily, way back when.
Getting to the root cause of an issue can take time. It can even feel inefficient to discuss. But by leaning into techniques such as The Five Whys or Peeling the Onion, we have the opportunity to deliver a more effective and long-lasting positive impact for our teams. Yes, solving top-level problems feels good and does help the team. But by taking our time and exploring more, better, more crucial improvements can be made.
This post originally appeared on John’s personal site on August 12, 2021.