Product Owners span the gap between the business and technical spheres.

Product owners span the gap between the business and technical spheres.

Failure to correctly address the product owner’s role creates a myriad of problems for Agile projects, each of which can and have led to the failure of many Agile implementations. The product owner’s role can be difficult to implement. The potential problems include: not adequately integrating business representatives into the team, reinforcing the perceived divide between IT and the business and substituting proxies for business involvement. Each Agile team needs a product owner, or they risk delivering the wrong functionality.

Not integrating business knowledge and decision-making capacity (i.e. the product owner) into the project will lower productivity, velocity and the quality of any project. Just think of the best projects you ever participated in. I suspect that one of the reasons was that a sponsor, lead subject matter expert or super-user, was always around providing input and making decisions. In effect, they were acting as a product owner. Project teams make many decisions, large and small, on a day-to-day basis.  The choice that the team has is either 1) to make the decision using the knowledge at hand and risk being wrong, or 2) to wait until they can gather more information. The pressure to deliver means that most teams will absorb the risk and the rework. Having a product owner close at hand makes development quicker and increases quality.

Not implementing the product owner role reinforces the divide between IT and the business, thus reducing the efficiency of communication. There are many excuses for why organizations implementing Agile don’t involve the business in projects, but the one that I see the most often is that the project team doesn’t ask.  Excuses for not asking I have heard include: “the business won’t participate because they are too busy,” or “they are not interested” or “they don’t want to have anything to do with us”. Remember that the goal of any project (or at least any project that should be done) is to deliver tangible value based on a need stated by the business. Therefore business personnel have a concrete reason for participation; they should make sure their investment pays off.  The first step in the process to involve the business as a product owners is to ask the potential product owners and their managers to participate, make sure they understand the role and also to understand why involvement is important.

The use of proxy product owners is a copout, and in most cases represents a firm signal that Agile should not be used. An organization I recently visited put their money where their mouth was – implementing a hard and fast rule that if a project did not have a product owner, then the project was put on hold until it could be started using a standard project management framework. Without the infusion of business involvement in the day-to-day operation of the project the organization decided that classic deliverable-based framework was more appropriate. Proxy product owners are rarely the right answer, because they can’t commit and make decisions for the business slowing the development process to a crawl.

The product owner role is critical to linking Agile development teams to the business. Product owners bring business acumen to the development team. That reduces rework and increases the overall acceptance of the product. Not implementing the concept of product owners or using proxies is rarely the right answer. Bite the bullet and talk to the business users about how they can integrate into the process, after all, it is their money.  If they can’t commit consider not using Agile mechanisms (like Scrum), and instead begin the lean to Agile transition with techniques like Kanban.