Qualities of a Healthy Relationship Between Engineering and Product

Early in my career in software development as I reflected on what makes a great product, I began to formulate the opinion that success was 90% engineering and 10% everyone else. What I mean by this is that if the engineering team was top class: filled with talented people, had great coding standards, embraced testing, had seamless continuous integration, etc that you would most likely have an amazing product.

Now keep in mind, as a former developer, I was biased. Heavily biased.

As my career progressed, I began to appreciate more and more the impact product managers and their teams can have in the overall quality and success of the product. I learned that you can have a rock-solid piece of software that has 100% test coverage and is functionally sound yet fails miserably in the market.

I learned that if you really want to have a successful product, you need a healthy relationship between Product and Engineering.

What does that look like?

Product Owners are team members

Are Product Owners really considered members of the team? The Scrum Guide,” clearly states that the "Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master," so it should be a settled matter yet much digital ink has been spilled on this point alone. And I don't think it's a trivial one.

Many think that it's the ScrumMaster's job to handle the details throughout the sprint while the Product Owner (PO) goes back to their market research and wire-framing. This is not the case. Product Owners are the "CEO" of the product. While the success or failure of the product falls on everyone's shoulders, there is an extra amount of ownership and responsibility that rests on Product. Therefore, when some decisions need to be made during a sprint, such as negotiations on specs, the PO needs to be ridiculously available for these discussions.

The PO should be an ever-present figure who is there for their product. This means the PO shows up at most of the stand-ups, sits in on retrospectives, and is physically located (when possible) near where the work is being done.

Product simply doesn't hand off specifications and user stories to the development team then disappear for two weeks until demo time. This is a sure-sign of an unhealthy relationship that will ruin your product.

Product Owners and ScrumMasters are best friends

Professional best friends, anyways. What does this look like? It means that the ScrumMaster (SM) and the PO spend a lot of their time throughout the day together.

Why do ScrumMasters and Product Owners need to spend time together? Two primary reasons:

1. The SM should know almost as much about the product as the PO (yup, I said it).
2. The PO should know exactly how groomed the backlog should be for the development team to successfully build what they want.

These two facets can often times feel unnatural since the SM isn't normally as strategic and the PO not as tactical in the way they approach their jobs but they are areas both need to learn in order for their careers to thrive. 

The better the SM can understand the product, the more effective he will be in identifying if the team is making the right kind of progress. The SM can also make better decisions with the team in the absence of the PO. 

The better the PO can understand the level of story detail required to direct development the more efficiently engineering can go about their days. UAC should be defined for all known requirements. Not only will this show the team if they sufficiently completed a task, but QA will be using UAC to help build their tests. This drives the whole team forward to their shared goal of a successful release.

As I mentioned before, these skills may not come naturally for the SM or PO, so it's the job of the Agile Coach to make sure the PO is educating the SM on the Product and the SM is educating the PO on the level of granularity acceptable for each story.

I could go on at length on this topic, but if this relationship doesn't work, then the product will fail.

Product Owners and the team share the spoils of victory.... and blame in defeat

We're all in this together. And this all seems pretty obvious, but often times there are devastating rifts that can grow between Product and Engineering if we're not careful.

This is where good coaching comes in very handy. An effective Agile Coach can catch symptoms before it blows into a full-blown disease. Ask yourselves these questions:

• Who is writing the user stories? If it's the SM by his lonesome, you have a problem.
• At what point in the process is the PO getting her hands on some version of the product? If it's at the end or around demo time, you have a problem.
• Who owns and grooms the backlog? If it's your ScrumMaster alone, you have a problem.
• What do retrospectives reveal about the health of the Product/Engineering relationship? If the team provides feedback around not being provided timely or detailed enough information from Product, you have a problem.
• Can the SM effectively describe the product, its features, and where it's headed in 30, 90, 120 days? If not, you have a problem.
• How often are the SM and PO seen collaborating? If these two appear more like ships passing in the night, you have a problem.

While there are many nuances to this relationship, it's now very clear to me after over 10 years of software experience that the ScrumMaster/Product Owner relationship can make or break your product. 

How do your ScrumMasters and Product Owners get along?