PO needs to turn, but developers refuse!

Interesting discussion we have this morning in our Agile Improvement meeting: How to maintain a good balance between the need of the PO to change things to maximize value and the need of the developers of certain stability to perform their activities.

In one side is the PO, responsible for maximizing the ROI of the project. The PO takes all his decisions with the goal of maximizing the value the product will deliver, make it more sellable and make it more competitive. 

On the other side, the developers who work hard during an iteration to finish a feature. Timeboxed feature based iterations impose this hectic rhythm. In a short period of time, the development teams delivers a feature that has some business value. During this period, the development team needs to feel this feature has been groomed to a point where is nearly frozen or at least few changes will be necessary. 

So what happens when something has already been finished and the PO judges it's incorrect: it needs to be redone. In a project with a lot of uncertainty, this is entirely possible. Having to change something when already has been completed or have to drop something is demoralizing. The team could feel that the product team does not care for their work or that they don't have any idea of where we are going. Motivation goes down because there's no reward in finishing something.

How to balance these 2 apparent contradicting needs?

With trust: There's one team - product and development go in the same direction. If a decision that implies rework or throwing work, the team needs to know it's for the best. The team trusts the PO on these decisions. And the PO respects the work of the team. 

Atacking the uncertainties as soon as possible: when the team starts with a user story, everybody (product and development) tries to eliminate the uncertainties as soon as possible. Is the prototype Ok?  What will happen if?

Maintaining the communication through all the construction of the story: This conversation continues throughout the development of the story. The ideal is the PO seated with the team full time in an opened space. Of course, this is not always possible, but we should strive to make it as similar as that as possible.

But what happens in distributed teams, where the PO is in a different timezone. Written documentation becomes more important, because it sticks and can be consulted whenever the remote team needs it. Documentation becomes more important because communication decreases. Of course, written documentation is much less effective than oral communication but good teams overcome these situations.