Agile Scrum BI: The Product Owner’s confusion

As a speaker at a conference on Agile BI in mid-December 2012, I provided a session dedicated to the role of the Product Owner. The content of that session was based upon a mix of real-life experience as a Product Owner, and on theoretical reflections.

I concluded that the role of Product Owner is hard to fill in the ‘right’ way, which makes Agile Scrum hard to kick-start and makes the process feel either flawed or incompletely designed and/or described. This observation remained true when I applied Agile Scrum BI in practice as a member of a Product Owner Community. This article zooms. in – again – 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 he/she 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.

Fig.: a schematic representation of the Proxy Product Owner role

 

During an earlier Agile Scrum start-up assignment, 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. Drawbacks of a Proxy Product Owner are, however, that:

  • the distance to the business is too great despite all efforts to bridge the gap;

  • there will probably always be a 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/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.

Skills and commitment necessary for a good Product Owner

A couple of years back, I was part of a BI development team that decided to make the strategic shift towards an Agile Scrum BI organization. Despite all the time we had to prepare this – guided and supported 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 frequently debated many months after ‘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 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 Business Intelligence does not equal application development, and we 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:

  1. business analysis (thorough understanding of the customer needs);
  2. product lifecycle management;
  3. configuration management;
  4. organizational marketing;
  5. active stakeholder communication and management;
  6. consensus building;
  7. IT program management;
  8. 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/product will satisfy those needs (vision!);
  • to be able to manage solution development and to actually participate in high-level solution design decisions;
  • possessing a degree of innovation and an 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.

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’.