Successful Product Owners Challenge the Technical Solution
Product Owners who are afraid of challenging the Development Team will inevitably end up building a bazooka to kill a mosquito
Product Owners who are afraid of challenging the Development Team will inevitably end up building a bazooka to kill a mosquito
It was Friday, the last Sprint day, as I came to the office excited for the Sprint Review. Previously we failed to achieve our Sprint Goal. But I was confident we wouldn’t fail twice in a row. The Development Team was motivated to finish the authentication system.
I realized something was wrong once the developers told me they wouldn’t have lunch. The Sprint Review was scheduled at 02:00 p.m. I was hungry, so I went to have lunch with the Scrum Master. During lunch, I felt apprehensive because we failed the previous Sprint, and it would be embarrassing to fail again. I didn’t want to believe we would end up in the same situation.
At 02:00 p.m., the stakeholders were in the meeting room, waiting for the Scrum Team. The developers were still not there. Some people were annoyed by the delay. The Scrum Master tried to keep everyone calm, but the stakeholders felt something was wrong. After waiting for nine minutes, some stakeholders were about to abandon the event, but suddenly the developers arrived. They looked disappointed.
Sadly, I knew what was about to come. My fear came true once a developer said, “Unfortunately, we underestimated the complexity of building the authentication system. We failed again, and we don’t have anything to show to you. Sorry!” I was shocked. I wondered, “How could we fail twice in a row? What decision brought us here?” I knew we needed to do something different!
All of this could be avoided if I had asked a straightforward question, “Are we considering the simplest solution for the problem we have?” Which I didn’t ask. Let me share with you the learnings I had from this painful experience. Then, you can avoid it.
Be Careful! Don’t Build a Bazooka to Kill a Mosquito
Finding the right solution for the problem we want to solve is vital to achieving success. By building a more complex solution than necessary, we generate waste. Great teams strive to develop precise solutions. Complex solutions will not only slow down time-to-market, but also will inevitably add technical debt.
Simplicity — the art of maximizing the amount
of work not done — is essential.
Let’s go back to the authentication system I mentioned. We were a startup of around fifty people. To keep the business efficient, we built systems to make internal processes faster. But, only the Development Team could manage the users. Startups are dynamic; people come and go at a fast pace. So businesses needed to be able to handle the users without disturbing the developers.
During our Product Backlog refinement, I shared the need of giving autonomy to the business team on the users’ management. We discussed about providing something useful and straightforward. It would be only for internal usage. The Development Team understood, and we refined the Product Backlog items.
The Development Team decided to use a NoSQL database and build a micro-service for the authentication system. The team decided to do it because they wanted to learn more about these technologies. However, we did not need to build a scalable authentication system for internal usage.
We had a mosquito to kill. We could have used our flip-flops to smash the insect. But we decided to build a bazooka. We failed because we built a heavier solution than we needed.
“Everything should be made as simple as possible, but not simpler.” — Albert Einstein
Product Owners Should Challenge The Technical Solution
As a Product Owner, I love when developers challenge me on topics I bring during the Product Backlog refinement. It shows they are interested in solving real problems. But, many developers do not welcome Product Owners challenging the technical solution. Should it be like that? High-performing teams achieve astonishing results because they are not afraid of conflicts.
“It’s as simple as this. When people don’t unload their opinions and feel like they’ve been listened to, they won’t really get on board.”
― Patrick Lencioni, The Five Dysfunctions of a Team: A Leadership Fable
In Scrum, the Product Owners own the why. So as Product Owners, we should decide why we should work on something. While the Development Team owns the how, so they decide how to solve the problems. However, we should not forget that what is crafted together with the whole Scrum Team. The degree of collaboration between team members will determine our success.
Successful Product Owners challenge the Development Team on the technical solution. The intention of doing that is to ensure we are not generating waste. To guarantee we are not over-engineering. Product Owners challenge the team to bring more options to the table.
It is not about questioning the technical skills of the Development Team. On the contrary, it is about helping them to think which technical solution is a perfect match for the problem we want to solve. I have a set of questions that help me to identify precise solutions with the team:
Is this the simplest solution we can build?
Why is this the best solution for this problem?
What are we missing?
What are the other options we could consider?
What assumptions do we have with this solution?
From my experience, if developers don’t challenge the Product Owner, we tend to build solutions that are too simple. And if Product Owners don’t challenge the developers, we tend to develop solutions that are too complex for the problem we want to solve. The right balance is vital to thrive.
A healthy tension between the Product Owner and Development Team leads to technical solutions that deliver more value. Solutions that won’t be too simple and increase technical debt. Solutions that won’t be too complex and delay time-to-market before we prove it delivers value.
— Maarten Dalmijn, Why Product Owners should challenge technical solutions
Endnote
I have experienced many failures because of complex solutions. When I look back, I am sure we could build simpler solutions that would have solved the problems faster. I fell into this pitfall multiple times because I didn’t challenge the Development Team as often as I should.
High-performing Scrum Teams share one goal, building meaningful products. Each team member helps each other to thrive. Nobody is afraid of stepping on dangerous territories. Developers are fearless of asking the Product Owner why we should solve this problem. And Product Owners are courageous to ask developers why is this the simples solution we could build?
The tension between Product Owners and Developers is healthy as long as the intentions are to solve problems the best way possible. Without this tension, it becomes impossible to be a high-performing team.
Do you want to write for Serious Scrum or seriously discuss Scrum?