Developing software is a collaborative process that takes a tremendous amount of input from customers, designers, developers, and a company’s leadership team. We know the merits of shipping early and often, but doing so requires regularly making decisions with imperfect information. When it comes to effective decision-making, there is no one size fits all approach, but there are decision-making “smells” that can disrupt a product team’s effectiveness. Like “code smells,” a team should acknowledge and consider addressing these dysfunctions.
Inconsistent Decision-Making Process
Conversation on a ticket:
Developer: “I realized that the mockups don’t include a place for a user to log out. The two best places to add the button seem like A) the navigation or B) the account page.”
Team Member 1: “I definitely would go with B. The navigation is already a bit crowded.”
Team Member 2: “I think both could work”
Team Member 3: “Navigation makes the most sense to me. I vote A!”
… many hours of silence …
Developer: “Sounds like we don’t have a clear winner. Should we have a meeting to discuss?”
… many more hours of silence …
By highlighting the example above, I am not advocating rushing decisions or excluding team members from the decision-making process. The smell is that the developer does not have clear guidelines for how to resolve a stalemate. Maybe the team’s product owner considers all of the input and provides the final decision on the ticket? Maybe there could be time carved out after standup for the team to discuss the options, weigh the tradeoffs, and vote as a collective group? Either of these options works, but what is important is that the team has an agreed upon game plan. This brings consistency into the process and reduces developer uncertainty and stress.
Unavailable Product Owner
As a developer, when I work on tickets, I often run into a concern or edge case that needs to be run by the product owner(s) before I can proceed. Product owners are busy. They have meetings, other responsibilities, and they go on vacation. If a product owner cannot get back to me for a day or two, it isn’t the end of the world as I can pick up a new card and stay productive. Their absence becomes a smell when it is the norm. When a product owner is spread thin and isn’t able to get back to me on several tickets at a time, they become blocked and the backlog gets backed up. Having to constantly context switch between tickets can take a big hit on developer velocity.
Prescribed Solutions
Discussing a ticket on the backlog in a product planning meeting:
Product Owner: “The accounts team needs a new filter in the admin console where they can filter customers by sign up date.”
Developer: “That shouldn’t be too tough and will only take a few hours. Why do they need the filter?”
Product Owner: “They want to identify accounts created today.”
Developer: “That makes sense. What if instead, we just updated the existing customer table to be ordered by account creation with the newest customers first?”
Product Owner: “I like it. That would actually make it even easier for them.”
Developer: “Great. It makes it easier for me too as that’ll only take a few minutes”
This team almost missed a creative solution that led to a better outcome. It is a smell if a developer is working on a feature and doesn’t know why. A developer will have the best context on the difficulty and tradeoffs of different implementations. By looping them in on the business motivation behind each feature, you empower them to get creative and find wins that can ship better solutions to your customers faster. It’s even better if that context sharing takes place on the ticket and is not dependent on an in-person conversation. Job stories are a great way to achieve this.
Iterating on a Whim
Building a new MVP product can require a leap of faith because you don’t have the analytics of real users to guide most decisions. However, once a product exists, there is real world usage that a team can use to optimize the product. Optimization may mean more signups, higher retention, quicker checkout, more pageviews, etc. A busy team may not run regular analysis and miss the fact that the last deploy led to a major reduction in performance of several key metrics. A busy team may float the idea of running an A/B test, but scrap it since it will add to development time and may compromise a sprint. It is a smell if user validation and analytics are not treated as first class citizens when deciding how to iterate a product. Not all change is good, and it is important to identify which changes should be celebrated, and which should be reverted.
Addressing a Smell
Like code smells, a decision-making smell may not be catastrophic to your product or your team, but if you let the smells build up and fester, you are at risk of jeopardizing your product’s quality and your team’s morale. If you see a smell on your team, shine a light on it in your next team retrospective.
