What’s wrong in software product line engineering? Political power play between product units

In previous blog posts we identified

• lack of resources in platform organization and
• insufficient collaboration between product and platform unit

as causes for problems in software product line engineering. Of several more, I want to pick a third and final one, before we turn to the root cause of it all in the next blog post. This third cause is the political power play between product units as they try to prioritize requirements for the platform organization.

Specifically, in traditional application and domain engineering processes, the platform is jointly paid for by some corporate funds or the product units directly. These costs occur, no matter what, and are not tied to the prioritization and triage of requirements for the next release of the platform. As a consequence, there is no cost associated with fighting to get your requirements to the top of the list.

Read what engineering managers and software developers had to say about power play in product line engineering:

• “A consequence of the power play between product units is that the platform drives the [domain engineering] process and involves product units only very late.” Developer (platform), case 1.
• “We [platform organization] don’t know how to prioritize reusable asset requirements, and the product units are no help because each feature is most important.” Manager (platform), case 2.
• “We didn’t understand the reusable asset requirements as communicated by the product units. […] Not much worked when we first delivered the component.” Developer (platform), case 1.

Power play and political infighting between product units leads to poorly prioritized requirements which in turn, from an overall perspective, lead to systemic overall delayed product delivery.

Why? A sane prioritization would have the benefit of the overall product line in mind, not the interests of the most powerful product unit or the technical interests of the platform only. One can argue that this is a failure of the domain engineering process and a sane process would lead to correctly prioritized requirements. However, the lack of sanity ensues because there is no cost associated with prioritizing and a better or worse run domain engineering process won’t change anything about it.

Finally, read about the root cause of it all: The separation of product units as profit centers from the platform as a cost center.