Building Better Software Teams Part 3 - 4 Symptoms or One Problem
This story is third in the series Building Better Software Teams in which we understand and try to remediate some common issues faced by software teams.
In the previous part, we saw how 5 Whys can be a great way to get to the root of an issue. Once the team identified the first root cause, it was quickly able to remediate it and found a better way to plan their sprints.
Prashant Bhargava
Let’s continue our journey and understand what the team discovers and the importance of identifying the right problem to solve.
Concern 2. The team feels understaffed.
Why?
- Because we are not meeting the ideal project timeline.
Why?
- Because the number of journeys that have actually completed is far less than expected.
Out of 20 user journeys, only 4 are complete, 3 are near completion and 7 have just started development. By now, 12 journeys should have been completed.
Why?
- Effectively, because of parallelization, only a single developer is working on each journey.
This has led to gaps in feature knowledge, varying level of code quality due to different experience levels, which become problematic during code reviews. Additionally, trying to integrate multiple journeys simultaneously leads to unexpected bugs and requires extensive testing.
At this point, the team isn’t sure how to proceed.
After asking just 3 Whys, their analysis is linking back to the original issue of lacking a clear focus, as we discussed in Part 1.
The team decides not to delve further and moves on to discussing the next problem.
Concern 3. The designs are late.
Why?
The designers identify two main concerns:
- They’ve mentioned before that being late with designs was partly because they weren’t sure which user journey to prioritize, as the team had several in progress.
- The second concern is intriguing. They mention that creating user journeys is complex, as every minor change requires repetitive updates across all journeys.
Since the team has already encountered the first reason multiple times, they decide to pursue the second reason.
Why?
- Because we never created reusable components in the designs.
Why?
- We did not create a reusable library of components, since we were in a rush to begin the project and never got a chance to prioritize these components.
“That happens to us all the time!” one of the developers says and asks “So, how do you address this design debt?”
The designers are not sure. Although they have a good idea what needs to be done, they aren’t sure how to pay back this design debt.
The developers share some ideas on how this can be achieved:
By consciously making space for it. If there’s a component that has a lot of technical debt, the next time we touch it, we make it a little better. It doesn’t have to be rewritten or rethought, just something that would improve its quality is good. This way we are making continuous improvements and the more we touch a component, the better it becomes.
Concern 4. The team needs additional support to test the numerous features.
Why?
- There are too many features to test and not enough time for testing.
Why?
- Because everyone is so busy trying to complete their own work that they do not prioritize testing other journeys. Additionally, the QA resource is overwhelmed with all the different journeys being built at the same time.
This sounds eerily similar to others as well. Since multiple journeys are being built at the same time, everyone is individually trying to run to the finish line, instead of working as a team.
Lack of focus has come up in 4 out of the 4 concerns, and now the team is eager to fix this mistake.
We went through quite a few different things in this article and I will try to summarize some takeaways:
- The number 5 in 5 Whys is arbitrary. Depending on your problem, you may have to ask it 6,7,8 times, or, to exaggerate, even 20 times. Or, you might get your answer after asking just a couple of Whys.
- The 5 Whys can sometimes produce branches where you might have several reasons for a single problem. Don’t be afraid; there are different ways you can tackle them. For example, the team decided to prioritize only one of the two paths, because they didn’t see value in discussing the other.
- Cross pollination of ideas. Bringing everyone together in a meeting is a huge time commitment. But so is not bringing together everyone who is directly impacted by a problem. What would you rather have: 20 redundant ideas or 10 siloed problems? Now I am not advocating for having meetings after meetings with everyone you can possibly think of. However, the team that is impacted by a problem needs to sit together and collectively find solutions.
We saw how the designers were able to apply the concept of paying back technical debt to the way they approach their design sprints. If the designers hadn’t sat with the developers in the 5 Why process, they would have never discussed their problems out loud. Consequently, they probably would have never really found out how to tackle the problem they were facing. - Building empathy in your team is essential. Talking about your challenges openly, builds empathy. There are more people willing to help out and pitch in than you can imagine. But for that to happen, someone has to ask for help first. If your team is hesitant to ask questions, they are probably already feeling insecure or are not aware of all the help available to them. Encourage your team to ask questions, openly discuss challenges, and seek help from each other. This is common knowledge, I know, but it’s not easily implemented. Overcoming one’s insecurities requires building trust among team members.
Encouraging such open communication and problem-solving approaches can significantly impact your team’s effectiveness and overall morale.
In the next part, let’s talk about the team’s last and final concern: Scalability.
