Agile-Scrum clearly defines the Product Owner (PO) as a key member of a Scrum team. The PO represents the Voice of the Customer. The PO is responsible for fusing the various needs, wants, and perspectives of project stakeholders into one complete, coherent, and cohesive vision. The development team depends on the direction and guidance provided by the PO to understand what business capabilities to develop and how those capabilities must work to provide value to the customer. Thus, PO plays the most important role in the creation of User Stories and their prioritization within the Product Backlog.
However, more often than not, when I ask Agile-Scrum development teams, “Who is your PO?”, they do not know for certain. This is especially true in systems integration projects. Ask different developers within the project who the PO is and you will likely get different answers. Some will say the Enterprise Architect is the PO. Others will name the lead Systems Engineer, or the Chief Engineer, or the Project/Program Manager, or the owner of the company, etc. Often the answer is, “We don’t have one.”
Agile-Scrum was originally conceived within a commercial product development paradigm. The terminology of Agile-Scrum is indicative of this product development bias with terms like Product Owner and Product Backlog.
In a product development project, the company has significantly more control over the Product Vision and how that vision is actualized than in a systems integration effort. The company decides what capabilities and features to develop, how they will be integrated into the product, when the product will be released, and how much will be spent developing the product. In well-run product companies, all of these decisions are informed by market and user data. However, these decisions are ultimately made by the company.
System integration efforts, by contrast, tend to be customer-driven. Customers decide which capabilities they will pay for, how much they will spend, and when the implementation of those capabilities is due. Thus, system integration efforts are, by nature, service engagements, not product development efforts. Also, software solutions integrated into enterprise environments are typically much more technically and organizationally constrained than than green-field product development efforts.
The control product companies have over their products makes it significantly easier to identify and empower POs than in system integration engagements. Product company POs have fewer stakeholders to answer to and, typically, fewer external dependencies to manage. They also have the advantage of starting with a company-defined Product Vision. In systems integration, Agile-Scrum teams work with a customer PO to define a Product Vision for a solution the PO does not own and that must address many disparate, and often conflicting, needs and wants of internal and external organizational stakeholders.
It quickly becomes clear that the role of PO in a large-scale system integration effort cannot be filled by one person alone. Due to the many stakeholders that need to be included, the Voice of the Customer can easily become a cacophony of voices without some structured way of harmonizing them into a chorus. Adding to this complexity is the fact that large-scale system integration efforts typically involve multiple teams from different companies. Each of these teams requires a PO, assuming they are all executing as Agile-Scrum teams.
Large system integration projects demand a level of planning and coordination that pure “team-level“ Agile cannot handle. I am not proposing engaging in Waterfall-style, Big Planning Upfront. Even in complex system integration engagements, the Product Vision can be defined over time in an iterative approach, as prescribed by Agile.
Large-scale systems integration requires a product management approach that informs and coordinates team-level PO decisions and prioritizations across program and portfolio levels. Each team works with a PO who manages the stakeholder community that depends on the team’s feature set. Each PO also coordinates with other POs through a product management structure. This product management structure is a core feature of the Scaled Agile Framework (SAFe).
Since scope in Agile “floats”, having an empowered and engaged PO is vital to ensuring teams deliver real value within agreed upon budget and time constraints. The definition and realization of the solution’s TO-BE state depends on POs. For Federal software system development projects in particular, the PO role should be played by a government employee who is empowered to make decisions, capable of leading a stakeholder community, and tasked as a full time PO to the teams he/she supports. Anything less introduces risk to Agile projects and breaks the alignment between development teams and the sponsoring organization.
Reload document 
Open in new tab