Archives February 2024

With the maturing of the software industry and with an overwhelming acceptance of agility, I am still surprised at the inconsistency and overall confusion between what product managers and product owners do. Adding to the confusion, organizations struggling to make sense of the roles and job titles can’t rely on conflicting information widely spread over the internet to clarify roles and responsibilities.

As a speaker at an Agile Business Intelligence (BI) conference some years ago, the focal point of my talk was on the particular role of the product owner. The ingredients for this session were a mix of real-life experiences and theoretical perspectives. I concluded that the role of Product Owner is hard to fill in the “right” way, which makes Agile Scrum hard to jump-start and makes the process feel either flawed or incompletely designed or described. This observation remained true when I applied Agile BI in practice as a member of a Product Owner community. This article zooms in on a couple of important elements of the implementation of Agile Scrum in general, and more particularly focuses on certain points for attention in the execution of the role of a Proxy Product Owner in a Business Intelligence environment.

The Proxy Product Owner

A Product Owner role as described in the Agile Scrum theory is a business profile, and therefore she or he is a member of one or more business departments, not a member of the IT department. Not having a Product Owner in the business is usually considered to be an adverse organizational setup. A Proxy Product Owner is a person acting as a placeholder for the actual Product Owner. In essence, the Product Owner fills two major roles: proxy client when dealing with the Scrum team, and product management coach when dealing with the customer.

Taking a start with Agile BI

A valid reason for kick starting an Agile Scrum BI organization with Proxy Product Owners was the absolute faith and belief in its advantages, and being ahead of the business departments in terms of knowledge of the subject. A partial or full buy-in was projected as a future goal based on the expected success. However drawbacks of a Proxy Product Owner role are:

• The “distance” to the business, despite all efforts to bridge the gap.
• The latent lack of empowerment in decision-making (mandate) about product backlog prioritization, release planning, and whether to accept or reject work results.

In general, a Proxy Product Owner will need to put in quite a lot more effort not to end up in conflicts and miscommunication, a slowdown in decision-making, and a decrease in productivity and morale. Briefly put, Agile Scrum theory describes a User Story as one or more sentences in the everyday or business language of the end user or user of a system which captures what a user does or needs to do as part of his or her job function. It captures the ‘who’, ‘what’ and ‘why’ of a requirement in a simple, concise way, often limited in detail by what can be handwritten on a small paper note card. It is my belief that a Product Owner must master a mature level of business narrative in order to really capture the essence of what is needed. The sharing of knowledge is one of the cornerstones.  User Stories are crafted to generate understanding, not necessarily only action. Why things happened or occurred as they did needs to be translated into a ‘well-told’ User Story. This does not mean narrowing it down to simply transmitting bulleted tasks, actions and values through narrative. All these communicated abstractions are typically dead on arrival. In this sense, to me, a good User Story is much more than a so-called “reminder to have a conversation with the business”. And I believe that mastering the craftsmanship of the business narrative is an undoubted skill of the Product Owner.

The good Product Owner’s skills and commitments

I’ve had the pleasure, on more than one occasion, of being part of a BI team that decided to make the strategic shift towards an Agile Scrum BI organization. Despite all the time we had to prepare this – in some cases guided by an external Agile coach – and despite a relatively high number of dedicated strategic and tactical workshops, the true sense, the content and the responsibilities of the Product Owner were still being debated frequently many months after the go live. This was within a community that needed to start acting as Proxy Product Owners while still being part of an IT department.

In any case, figuring out what to build and mostly what to build first is the core job of the Product Owner. It is difficult. It is probably a full-time job and it demands close collaboration with the development team on an ongoing basis. The team requires guidance and direction (e.g. actively managing the product backlog, answering questions when they arise, providing feedback, signing off work results, etc.). In simple terms, the Product Owner sits in the driver’s seat, deciding what should be done and when the software should be shipped. To deliver value, Agile Scrum requires an efficient, accurate mechanism for determining the vision for a solution and a feasible pipeline for translating that vision into concrete, deliverable backlog items that can demonstrably deliver tangible benefits. It is for this reason that the performance of the Product Owner becomes the prime limiter of the team’s success. Something that we learned at my current customer very soon after go live with Agile Scrum BI.

Since BI does not equal application development, we probably cannot formally define it as a “product” since it is more of a process, the skills required to do a good job are somewhat more demanding. In general, the Product Owner skill set includes knowledge of the following:

• Business analysis (thorough understanding of the customer needs)
• Product life cycle management
• Configuration management
• Organizational marketing
• Active stakeholder communication and management
• Consensus building
• IT program management
• Basic knowledge of how software is developed and deployed

Agile Scrum requires some proficiency in all the above – and the awareness to solicit additional support when necessary. Key for a Product Owner is:

• Understanding the customer’s needs and how a solution or product will satisfy those needs. This requires a vision already rather than a vague idea.
• To be able to manage solution development and to actually participate in high-level solution design decisions.
• Possessing a degree of innovative and entrepreneurial spirit.

This broad skill set implies that ideally, the Product Owner would be a hybrid: someone who is able to look outward, understanding the end customer’s needs, and someone who looks inward, managing the value stream that transforms the customer’s needs into a solution ready to be used by that customer.

What to do and more importantly what not to do

Many of my observations practicing Agile Scrum BI indicate the difficulty of understanding the actual meaning of creating value. Somehow we get easily tempted to interpret Agile Scrum as welcoming all asks and requests resulting in a bulging product backlog and a situation of just spoon-feeding the development teams with User Stories. Even experienced Agile coaches and lecturers sometimes still fall back on proverbial sayings such as “Agile Scrum is about maximizing output” whereas the theory actually intends to maximize the outcome, a very different meaning. This inspires the unwary Product Owner to focus on the number of Stories and maybe also the size of estimated Story Points. The number and the size of User Stories do not correlate with value.

Agile Scrum BI – Body of Knowledge

Knowledge is theory. We should be thankful if action of management is based on theory. Knowledge has temporal spread. Information is not knowledge. The world is drowning in information but is slow in acquisition of knowledge. There is no substitute for knowledge. (W. Edwards Deming)

Early in any development or project process, uncertainty and risk are the Product Owner’s enemies. Knowledge can be regarded as the opposite of risk. When uncertainty is high, the focus should be on knowledge acquisition. This can be done in many ways, for instance using technical spikes, prototypes or R&D experiments to explore emerging technologies. This cannot immediately be translated into value but it is still very important because it reduces risk, an important Product Owner responsibility. The main objective is to stabilize and preferably boost the customer value curve as much as possible.

Any noticeable lack of the knowledge and skills required by a Product Owner as described above, make an Agile Scrum structure fragile. I have learned that Product Owner guiding principles, methods, tools and techniques are not very well documented in Agile Scrum practices (also there are few useful books). You often need to look elsewhere for this information. I see a great opportunity to contribute to Agile Scrum theory by means of a more detailed “Body of Knowledge”.