Why you need a damn good Product Owner for your Agile project

One of the problems we hear a lot is "it is difficult to get business involvement in our IT project". While this is a problem for any project it is particularly difficult for Agile projects that rely on a fast cycle feedback loops with the business to prioritise work and ensure the project delivers maximum value to the business. Having insufficient business involvement in an Agile project erodes all four core Agile values - individuals and interactions, working software, customer collaboration and responding to change.

For your Agile project to succeed, not only do you need strong commitment and involvement from the business, you need a damn good Product Owner.

In the good old days...

In the good old days project teams used to work with representatives or subject matter experts from the business to understand, document and communicate business requirements. We'd write sizable requirements documents which we'd get reluctant business owners and business stakeholders to sign off. As requirements inevitably changed (either because the business changed or more likely the business understood what they really needed as the project progressed) a formal and very slow change control process was used to enable signed-off requirements to be changed.

What we know today is that this onerous process is time consuming, expensive and brittle to change and ultimately businesses often don't get what they need. The business would blame IT project team for not delivering what is required and the IT project team would explain that they delivered against the requirements signed off by the business. No one was happy.

Business involvement in Agile and Scrum projects

Agile projects rely on business involvement regularly throughout each and every iteration or sprint. The business representative who represents the business on an Agile project is normally referred to as the Product Owner.

What is a Product Owner and what do they do?

The Product Owner role is the most important role for ensuring an Agile project successfully delivers value to the business.

The Scrum Guide describes the Product Owner role as being:

"Responsible for maximizing the value of the product resulting from work of the Development Team."

The role is critical for maximising the return on investment from the project and so Product Owners are responsible for managing the 'product backlog' of work. This involves helping describe work items and then prioritising the product backlog to maximise the value that the development team delivers to the business.

The Product Owner role faces two directions, towards the business and its customers and towards the Agile or Scrum development team. According to the Scrum Guide the Product Owner is a single person; they represent the business on the Agile project and the both the business and the Agile team need to respect the decisions they make.

What makes a damn good Product Owner?

A damn good Product Owner:

• Has the trust of the business leader paying for the project and can represent this leader's needs
• Understands intimately the business and the problem the project is working to resolve
• Has or can gain comprehensive insight into the needs of the customers and users of the software to be developed
• Is decisive, knows what is going to deliver the best value to the business and makes good quality decisions in the best interests of the business
• Is confident, can defend his or her position, and won't be swayed by politics or the 'loudest voice'
• Is a good communicator, understands the needs of the business and its users and customers, and communicates and prioritises those needs to the project team
• Protects the development team from other business opinions and influences - all decisions on the work the project team does must come through the Product Owner
• Understands Scrum and Agile methods, how projects work, their role and what is expected of them
• Is involved and available to the Agile project team during each and every iteration or sprint and is present for all required events including Requirements Management, Sprint Planning, Daily Stand-ups, Sprint Reviews and String Retrospectives.
• Works well with the development team and Scrum Master, while also ensuring that these team members are working on the Product Owner's agreed highest priority items during each iteration or sprint.
• Ensures that the product backlog is visible and clear to the Agile project team and also the business, so that progress and next priorities are transparent and understood by everyone.

Attending a Certified Scrum Product Owner course can be a useful approach for developing Product Owner skills.

Plan A: Convincing your business to provide a damn good Product Owner

A damn good Product Owner is also a damn good business person, perhaps one of the business's best people. So you can understand that the business may be reluctant to give this person up for some IT thingy.

But, businesses can also gain an excellent return on investment from business systems when these are done well and reflect the business's needs. Consider the savings to a business when complex and manual processes are automated through a system. Or the loyalty, preference, revenue and productivity that comes from a system to provides a convenient customer or user experience (e.g. a mobile banking app). Or the ability a business has to rapidly adapt to changing market conditions when they have modern flexible business solutions. 

Excellent business systems are not delivered by IT and project teams in isolation, they are delivery by project teams working closely with the business.

Plan B: Using a damn good 'pseudo' Product Owner

Having a damn good Product Owner is important. Unfortunately, in reality not every project has one. So some projects have to improvise and use a damn good 'pseudo' Product Owner.

We often find that people with Project Manager and Business Analysis experience make good 'pseudo' Product Owners on Agile projects. Both of these roles face two ways (like Product Owners) to the business (and its stakeholders, users and customers) and to the project team and Scrum Master.

Project Managers have good experience at working with business stakeholders, managing expectations and prioritising work. They do need to remember though that they are now representing the business and the business leader who is paying the bills. They also need to remember that Agile projects are self-organising and so this is not the place for their 'command and control' management style - they need to be firm, they need to lead, but they don't need to manage.

Business Analysts are experienced at working with the business to understand their needs and then communicate these to the development team. But they need to remember that they are now 'responsible' for investment decisions and work prioritisation to deliver maximum value to the business. There is no more hiding behind a signed-off set of business requirements - right now they are the business.

The pseudo Product Owner scenario is not ideal. Because the person does not truly represent the business, they may not have the required business knowledge and they may not have the trust of the business or the business leader paying the bills. If the business feels the product being developed does not meet their needs then the person could lose their direction of the project as others look to influence decisions and work prioritisation.

Get a damn good Product Owner today

It is unfortunate that the Product Owner role is not more strongly understood and valued by project teams and businesses. The role is the most important for ensuring an Agile project successfully delivers value to the business and so it deserves greater attention and commitment.

If you want your Agile project to successfully deliver to the needs of your business, get a damn good Product Owner from the business today.

If you can't, then talk to us at Equinox IT and we'll provide you with your next best option, a damn good pseudo Product Owner.

Valerie Rowe is an Application Delivery Manager based in Equinox IT's Wellington office.