Jenny was a seasoned product manager who was growing into the Product Owner role.  She liked her additional responsibilities as Product Owner and the flexibility of the organization’s agile approach.  But after a difficult backlog grooming session she asked Tim, the Scrum Master, if they could speak privately. Imploringly, she threw her hands up in the air.

“Every time I suggested something in that meeting, the developers told me all of the problems with doing it. Why are they always so negative?  I also don’t think they really understand how complex some of business processes are. I’m worried that a key requirement is going to be missed.”

How should Tim respond to this? The key is in understanding the differences between how Product Owners and developers think and communicate.

Unprecedented access and communication

Remember the agile principle that states that “Business people and developers must work
together daily throughout the project?”  Before agile, buffers often existed between business people and developers.  A project manager, business analyst, or technical architect might have handled requirements gathering and posed questions to the users on behalf of the team. It seemed to make sense because they were better at switching between technical and non-technical discussions. Then agile came along, and all of a sudden users, product owners, and developers found themselves sitting around a table writing user stories, discussing detailed requirements and designing solutions. This created a new set of communication challenges…

A difference in perspectives

Writing code is a very intense, engrossing activity where the brain thinks in both logical and creative terms and attacks technical challenges from several angles until solutions are found. Defining requirements is geared towards brainstorming what the product can be. Because developers are accustomed to eliminating coding solutions that will not work, this thought process is instinctively applied to product design. What a developer perceives to be a logical approach to finding a design that will work can perceived as negativity by a product owner or user.

Solutions before requirements

While some developers are adept at hearing a business problem, formulating an approach to solving it, and breaking it down into constituent pieces that can be built into software, many do not have those analytical skills. Some developers are more comfortable in the realm of very specific solutions, and upon hearing a business problem, begin thinking in terms of how web pages should look and work.  Meanwhile, Product Owners and users are still thinking about shaping the underlying business processes, identifying user roles, defining and mapping the user stories, assessing the flow of the stories relative to the process, and determining how to logically approach the work.

Reflections

• As a Scrum Master, Tim needs to avoid letting people outsource their conflict to him.  That means bringing the Product Owner and developers together for a talk along with doing some individual coaching.
• The Scrum Master can help the Product Owner understand why developers sometimes think in critical terms.
• The Scrum Master can help developers understand what needs to be accomplished during the various types of meetings. Much of this is centered on having everyone understand that it is important to discuss things at the right level of detail at the right point in time.  This usually means that discussions should not get too detailed too soon. It also means reminding people when to focus on “what” should be built and not “how” it should be built.
• For complex business processes, it may be necessary to add a systems/business analyst to the team. Analysts know how to discover and capture the nuances of complex processes and how to facilitate re-shaping them to fit new business goals.