Building Better Software Teams Part 1 - The Challenges
What traits make a great software team? Join Beth's journey to uncover the keys to success for the product triad. 💻🚀 #SoftwareTeamSuccess
Imagine a Software Developer named Beth, working on a team responsible for building a critical feature for customers.
However, there’s a problem.
At the end of every sprint, during project reviews, new issues keep cropping up. If they continue on this path, the project will soon miss its deadline. Morale is low, pressure is high, and the team just wants to wrap up this project as soon as possible to take a breather.
Not only the team, but their manager, Linda, is under pressure too. She is not quite sure what’s wrong. This is not the first time her team has faced this situation; it’s happened before and she can clearly see the pattern. The project initially starts with good velocity, and initial demos go well. However, when the project is about midway, the pressure to deliver starts mounting up. During the weekly demos, the Product Manager identifies several issues with the product that the team clearly hasn’t thought about. Not only that, the VP of Software also asks tough but fair questions about the quality of the project, to which the team has no answer.
Beth comes up with an idea to have a project check-in, in which all stakeholders, including the VP, can be invited. Beth talks to her manager, Linda, and they both agree that it would be a great opportunity to bring the team together and gather perspectives from all the team members. They also discuss that the meeting should ideally be held before the next sprint starts so that any action items can be identified and implemented as soon as possible. Linda sends out an invite for the meeting and starts working with Beth to prepare for it. They both know that this meeting is critical for the project’s success.
The meeting day arrives. To prevent groupthink, they start by giving everyone 7 minutes to privately and anonymously capture their thoughts on answering a simple question:
Why do you think the Otis project is not going well?
Linda thanks the team for sharing their thoughts. After everyone has had a chance to speak about their sticky notes, the team tries to summarize and arrives at these main points:
- The team feels that team strength is low.
- They keep discovering more work and their earlier estimates were wrong. Additionally, they feel that features are being added mid sprint.
- Designs are regularly behind, partially due to the time constraints and partially due to certain missed scenarios related to enterprise users.
- The team needs help testing as there are a lot of features.
- Scalability is an ongoing concern.
- The architecture is complicated but not too many members seem to face this issue.
The team looks at VP for some direction. Although these bullet points summarize the problem nicely, he is still not quite sure what’s causing all these symptoms. The VP recommends the team to do a 5 Whys on each of these bullet points to get an understanding of the underlying root cause.
They are at the end of their allotted time, so the meeting has to wrap up. Everybody in the room is feeling energized after a long time. Beth is happy that she got a chance to voice her concerns and wishes that others felt the same. Linda is already thinking that this is a great start but wants to do the 5 Whys as soon as possible to not loose momentum.
We’ve all been in situations where we built features that:
- were never really used by customers,
- were so complex to build that the investment we put in didn’t justify the value they created (remember Pareto principle, 20% of your efforts will account for 80% of your results)
- or worse, the solution we built was completely opposite to the user’s expectations
Learn what Beth & Linda’s team discover during the 5 Whys. We will see what traits are necessary for a product team to function, go through the journey of investigating the symptoms of a problem to identify the root cause, and then try to remediate them.
Prashant Bhargava
