Get certified - Transform your world of work today

Bad Team or Bad PO?

How the PO setup impacts the PO -- and the development team

05/07/2015 by Wei Zhou

One day, a new ScrumMaster -- I'll call him Jack -- came to see me.

"Hey, Joe," he said. "You know, sometimes I think Waterfall is better for a cross-functional team."


"Recently our team developed several features. All of these features are quite small; we could finish each of them in just one sprint. So I thought maybe we could finish coding them and test them all at once. We did it, and the designers were happy since it looked very efficient."

"How long was your sprint?" I asked.

"Not long. Four weeks," answered Jack.

"So, your team just delivered once at the end of the fourth week?"

"Yeah. We saved a lot of extra work, like regression testing and documenting," said Jack.

"Did your operational PO (OPO) know about it? What did he say?" I asked, since I felt something was wrong.

"He didn't care."


Obviously, this was not a good Agile team. But I was also curious about why the operational PO didn't care about delivering only once. After I talked to him, I realized the reason.

In this organization, due to too many development teams, the PO team was split into three layers. There was the TPO (total PO), APO (area PO), and OPO (operational PO). And among these POs, only the TPO had the chance to see the customer and get the direct information. Then this information was transferred to the different APOs. Each APO would lead several OPOs. One OPO would take care of several development teams. But the OPOs had little connection with the TPO, and they didn't have the authority to impact the release plan. So OPOs would receive pushed sub-features from the APO, who split big features into several small ones. The OPO would not be involved in splitting or release planning.

Now we can see the whole story. The OPO got a sub-feature and delivery due date from the APO. Due to insufficient information and authority, the OPO became an execution role, much more like a small project manager role. For them, the only motivation was to deliver the sub-feature on time. That's why they didn't care about how many times the team delivered.

Let's go back to the team. When a cross-functional team got this kind of information, they had no motivation to split a sub-feature into several small user stories in order to deliver a smaller piece earlier. And the team found it was more efficient to use small Waterfall than Agile!

In this case, if we wanted to simplify the setup of POs -- like removing APOs and connecting the TPO directly with OPOs -- the OPOs would be activated again. The better way is to encourage OPOs to communicate with customers directly. They still could report to the TPO, but they would have more authority and be more active. For the team, having a PO with real authority is important. Sometime it's the key!