Enterprise agile development is different. Developing software using Scrum, Kanban, Lean or XP is just not the same on an enterprise scale. Consider the stressed-out, over-burdened, Product Owner.
Is it reasonable to expect one Product Owner to provide all the answers to the software development team’s questions? You can argue that it’s the Product Owner’s responsibility to seek out the right people and get the information. However, that adds a layer of indirection that could slow the team down or result in wrong answers.
Consider an analogy from the construction industry. Have you ever had a house built or had a major renovation done to your house? You hire a general contractor. That person hires specialists for each aspect of the job. For example, the general contractor may subcontract with the following businesses:
- Plumbing Contractor
- Electrical Contractor
- HVAC Contractor
- Carpenter
- Roofing Contractor
- Insulation Contractor
- Painting Contractor
- Flooring Contractor
- Landscape Designer
- Interior Decorator
Each business will have its own designer/planner to plan the work required, estimate the cost/time, and bring in the appropriate people. The general contractor relies on the specialty experts to provide answers and solve problems. No one expects the general contractor to have all the answers.
Product Owners Are General Contractors
In agile software development projects, we require that one person take ownership of the entire effort and provide all the answers. Is that reasonable? Here are a few areas that may require specialization:
Business Relationship Owner – This person builds trust with the business community (customers, clients, partners and internal users). Keeping all of these groups engaged throughout the project is critical.
User Experience Owner – Apple has proven that providing an elegant and polished user experience is a critical success factor. It’s a highly specialized skill that few can provide.
Technology Toolset Owner – The toolset used to build the software is often critical in enterprise development. Deploying a .Net solution into a Java environment (or vice versa) makes little sense. Someone needs to own the toolset decisions.
Information Architecture Owner – Many enterprises are drowning in data. They need solid information taxonomies and architectures to leverage their information and extract full value from it.
Externally Accessible Services Owner – If customers and partners will be accessing software services externally, someone needs to decide what the services will be and how they will be presented.
Externally Accessible Data Owner – If company information will be made available to outsiders, someone needs to decide what information will be offered and how it will be controlled.
Regulatory Compliance Owner – Every company faces legal, regulatory, industry and government compliance issues. It’s unlikely that anyone on the development team has this knowledge.
Documentation Owner – User guides remain critically important even if they are online and never printed. Good user documentation can reduce customer support calls and save money.
Marketing Owner – Someone has to convince people to buy the software or service. That person will need to define the value proposition to the customer and ensure that the software delivers it.
You get the idea. The Product Owner is not all of the above. The Product Owner is the general contractor. He brings in experts as needed. Not all of these experts will be needed for every project but they should all be identified and kept informed of the project status.
On an enterprise scale, for “project” or IT type projects in very big enterprises, this alignment might make sense.
For commercial software development, the model I’ve seen work is a market-facing Product Manager handling relationships within the business such as Sales and Implementations, with customers and analysts, with legal/regulators, and Marketing. The development-facing Product Owner, who pairs with the Product Manager, owns the User Experience, Toolset and Information Architecture areas you list. If the product requires multiple agile teams, you may find the need for Business Analysts to further help the Product Owner on the engineering side.