We all know it’s one thing to talk Scrum. It’s completely another to do Scrum. Real world application takes time, patience and if you’re lucky, a little insight from others who have walked the walk before you.
The good news? We can help. We encourage our students to reach out to us for that insight, to provide that experienced nugget of knowledge that can transform an issue from sticking point to smooth sailing. What follows is a snapshot of an email exchange between a 3Back student and ScrumMaster named Mark and our General Manager, Tommi Johnstone.
When Mark reached out for help from Tommi, he described the following situation:
During Planning, we were estimating effort on tasks and our Senior Dev would speak up and say, “This should take about 2 hours.” Then the Junior Dev would follow up with, “Well if it would take a Senior Dev two hours, it will probably take me about five.”
I know we get into this conversation of estimating the ‘average’ developer, but are there other ideas or efficiencies we can bake in somehow? Just wasn’t sure how you would handle this or if you knew someone who’s been through something similar.”
Mark’s concerns opened up a Scrum can of worms that many of us have experienced involving estimates, skillset gaps, Team Swarm and WIP (Work In Progress).
Mark, like many Teams, needed a sound solution. That requires some legwork. Sometimes it’s easiest to treat the symptom when trying to improve Team performance. However, while fixing the visible problem might provide a more immediate change, it is merely a quick fix. Without discovering the root cause, the problem will continue to rear its ugly head in different ways throughout the Team.
Looking for the “Why” (the root cause) behind the “What” (the visible problem) will prove to be a more successful and lasting solution. In Mark’s case, the “Why” was found by determining why the issues were cropping up now. Did the makeup of Mark’s Team recently change? Were the types of Stories being tackled a bit different than they’d been previous? Were the Junior members just now becoming courageous enough to speak up and challenge the Senior Devs’ estimates?
As it turns out, the “Why” centered around swarming, or rather, lack thereof. The Devs were not truly swarming (or at least not swarming across the Junior/Senior line). If the Devs were in a true swarming pattern, they would already be defaulting to estimates based on “us.” The solution? Mark needed to encourage team swarm.
How to do that? Limit WIP. Setting a limit on the number of Stories a Team can work on at a time is frequently used to harness Team focus, reduce noise and bolster productivity. However, for a Team like Mark’s with a significant skill-set gap, limiting WIP provides several other benefits as well. Essentially, limiting WIP forces the entire Team to swarm. Restrictions on WIP mean there are no options for a Dev, Junior or Senior, to dive into a new Story from the Backlog. The Team has to work together. It’s an outstanding learning opportunity for both levels of Devs. By swarming with the Senior Dev, the Junior Dev grows skill. The Senior Dev isn’t left out of the learning either, by gaining a better understanding of what the Junior Dev does and how they work. In the end, the result will be more accurate estimating that truly reflects what the Team can do.
Do you need helping limiting your Team’s WIP? We’ve got special training just for that. Check out one of our Kanban certification classes.
Is your Team dealing with an issue that you’d like some experienced input? Shoot us an email. We’re here to help.
As Always, Stay Agile.