Environment – nothing happens without a reason
Companies operate in a world of generally accepted designations and modus operandi. Developers, Designers, Business Analysts, Testers – organizations cannot function without them. There’s a leader above them, someone who takes care of the project to be done on time and who reports his job to a higher position manager. All these is a bit passive approach that puts the project somewhere in between being done or not being done.
Scrum itself isn’t complicated. It’s a very condensed technology, collection of tools likely to be implemented in many strands of business and different industries. The real challenge is to find the understanding of the concept behind it, the change of habits and approach to a specific element of the organization. The prime difficulty at the time of implementation is to convince the managers and the board to company reorganization and the change in approach to projects, work culture and the way of setting new goals.
Let us take a look at Product Owner’s role, which is interpreted in an inappropriate way almost in every aspect. By both the development team and the superiors. Each side pins their hopes on Product Owner in a different and often contrary way. The lack of common vision and understanding is the best recipe to fail in the project, and we do not want that.
I’ll begin with the description of the world we are in. The Scrum team consists of three roles:
- Scrum Master – sometimes referred to as the master of ceremonies. Scrum Master is responsible for Scrum process to be implemented the right way in both the team and the whole organization.
- Product Owner – the owner of the product. Product Owner is responsible for the business aspect of the project or the product. In this article, I’ll focus on this role.
- Development Team – responsible for providing growth in every sprint. These are the people with different competencies and skills, and because of that, they are able to implement projects from the beginning to the end.
Overarching goal of Scrum is to enable providing quick and smooth values. A value doesn’t have to be financial or possible to direct monetization. It can be understood as a new feature, a payment of the technical debt, a review of a prototype, improvement of the customer satisfaction and so on. The point is to implement a new element as soon as possible with small steps and to analyze results with the aim of the best and the quickest strategy alignment for further actions. At the Scrum basis, there is the constant inspection and the adaptation of every element of the project. From the process through everyday actions to a strategy. The inspection and the adaptation are the two of three pillars of Scrum. The last one is transparency, which has the direct impact on how the roles of Product Owner, Scrum Master and the development team are defined.
Product Owner role
The Product Owner role is taken by one and only one person. It supports the transparency (the third pillar of Scrum) within the project and organization. Thanks to this, we don’t have to wonder with whom we have to talk about a given issue, as is the case of many traditional teams. Also it facilitates the flow of information. We don’t have to look for someone responsible, because it’s always a Product Owner.
Product Owner within a Scrum team mostly comes down to or is compared to a Project Manager, known from the traditional project management methods. This is due to the need to match the structure imposed by Scrum that is unnatural for some companies, to the realities that are known to them. It is difficult to go day by day from the linear structure of the organization to a multidisciplinary, composed of independent entities, without a clear leader. Often it provokes opposition resulted from resistance to change, to step outside of the comfort zone and an established operating scheme. However, it is incorrect simplification. Depending on the field, typical Project Manager can have the greater or lesser competences than a Product Owner. The characterization of these two positions, their objectives pursued and operating philosophy are different. The best way is to separate these two roles. As I mentioned, Scrum provides for the existence of three roles and Project Manager isn’t one of them.
Let’s start with the understanding who a Product Owner is and what are his responsibilities to business and Scrum team.
Within every sprint, Scrum team together with the Product Owner set their goals, that is a short description of what they will focus on in the coming weeks. It’s a business value that they need to provide regardless of the stage in which a product is.
What is essential to properly set a goal?
- The knowledge of the long-term goals that are supposed to be achieved by a company/product.
- The understanding of the customer’s needs, business, main stakeholders.
- The access to recipients.
- A product strategy in line with company’s strategy and its long-term goals.
- A fluent and efficient priorities setting.
Abovementioned knowledge is generally distracted. Depending on the product’s character, it can be scattered in the organization, among stakeholders, customers or different data sets. It requires someone, who will gather information, understand them, organize them and on their basis will build a strategy. And what’s most important – will take the responsibility for this.
Let us remember that products or projects aren’t created in limbo. Apart from common restrictions such as time and budget, other factors should be taken into account: stakeholders, competition or regulatory framework. The list can be extended and shortened depending on an organization, the time and characteristics of a project. Therefore, a person who will understand all of those components and link them, who will give a right direction and determine the value of the ongoing work, is required. And that person is the Product Owner. His ultimate goal is to provide maximum value in the shortest time. Testing, experimenting and checking various paths to the improvement in rate of the return on investment (ROI).
Autonomy of action
According to my observations, Scrum works most effectively wherever the idea of the implementation comes from the board, the essential stakeholders or it is a grassroots initiative, but realized with the full support from the decisions makers. Without support, the implementation of Scrum is ineffective or its influence on the way of working is marginal.
Why is this happening? Mainly because of the trust or lack of it as well as a linear and fossilized structure of company. Scrum assumes that the whole development team is competent (possesses the necessary skills for the implementation of the project) and self-organized. Thanks to this, it has the autonomy. It independently makes decisions on the realization of individual issues (in collaboration with the Product Owner) and takes the full accountability for its actions. In turn, the Product Owner has the essential knowledge and the abilities to correctly estimate risk and to define development strategy plus has the possibilities of building the value. They get a full control to make independent decisions concerning the product, but at the same time, they have to take one-man accountability for its success or failure.
Sprint review, a scrum ceremony regarding to a wide range of people, is a kind of test verifying the level of implemented Scrum rules. When the Product Owner loses the possibility to decide about further direction of the development (e.g. supervisor imposes his vision on him), a warning alarm should start to ring in their head. Everyone, literally the whole organization, has to respect the decisions of the Product Owner. The project might be terminated, if it do not bode a success, however unless we face that critical point, the Product Owner should be at the helm.
At this moment, we come to one of foundations as well as the biggest challenge to face, when we implement Scrum in an organization. It’s the ability to make independent decisions by a master of ceremonies. The Product Owner is endowed by a great freedom of action, but at the same time it carries consequences in the form of a huge pressure. The Product Owner has overall responsibility for the project’s success or failure.
This structure reverses the natural course of events, e.g. linear, from top to bottom. A company has a clear vision and goals, but it doesn’t imply any specific actions. Those are a compass leading the direction. The Product Owner is a captain and his responsibility is to get to the target point together with his team. He has to do that in the best, the most efficient and the quickest way. When organization starts to work like that, we might say about using Scrum in a healthy way.
Who is not a Product Owner?
They say you can know a man not by what he accepts, but by what he rejects in his life. Let’s follow this example in this case. A Product Owner is a widely and loosely understood role. There’s nothing wrong in it, because its character is depending on product specifics, industry, environment, competition and many other external factors.
Let’s review, who the Product Owner is not.
- The Product Owner isn’t a group, a team or a committee. Not even a trio or a couple. It’s always one person with the full responsibility. He has the right to delegate tasks, but always holds responsibility.
- The Product Owner is not the Project Manager. He doesn’t have formal supervision over the development team. His responsibilities go way beyond realizing defined goals, because it’s him, who is in charge of identifying and giving the direction within a maintained product.
- The Product Owner isn’t a team leader. He can achieve goals thank to communicating and cooperation with the whole scrum team. But has no formal leadership.
- The Product Owner isn’t the Scrum Master. Although Scrum allows to combine different roles, these should be treated separately due to competing interests.
- The Product Owner isn’t an executor of someone’s will. He’s a creator of the strategy and product.
- Product Manager
IT specialist with many years of experience. Currently Product/Project Manager at Craftware, responsible for implementing projects from an idea through defining strategies to execution and effective implementation. An assistant and a PhD student at the Polish-Japanese Academy of Information Technology, who focuses on augmented reality technology. He implemented projects for companies such as Danone, Hyundai and ABC Data SA.