Certified Product Owner role in Scrum teams

Certified Product Owner role in Scrum teams

The Product Owner role is the most important in the Scrum teams along with the Development Team and the Scrum Master role. The Product Owner role in the Scrum framework is responsible for product development and project requirements. Communicates with stakeholders and creates so-called User Stories in the Product Backlog.

Product Owner Certification

There are many Product Owner certificates. This role must have in-depth knowledge of the product and consumers. However, he must be well versed in Scrum practices. That’s why Product Owner certification is needed for the leader of an Agile team. PSPO and BVOP Certified Product Owner are some of the most popular certification programs. Reference: https://bvop.org/productowner/ No matter which certificate you choose, this document can guarantee you good career success.

Situations related to the certified Product Owner in real teams

To get more real clarity about the activities of the certified Product Owner, we will share real possible situations.

The director of your organization wants to start developing three new products and informs you that for the largest product in terms of volume, he wants a team of 10 people. The available specialists for all new products are a total of 15 people.

These are 3 different products, the largest of which wants 10 people (out of 15). However, we divide them, when it comes to Scrum way of working team of 10 is a lot. The maximum number of developers is 9. By forming a team with more than 9 developers we risk losing orientation in the project and complicating the work process. Focus is lost, orientation in who is doing what and at what stage, communication becomes more complicated.

It needs to be clarified whether these 10 people, along with the big product, will be involved in the development of the other 2 smaller products – if so, we are not talking about Scrum at all. From what we have learned so far and seen in practice, I see that this, if not completely forbidden as a practice in Scrum, is either quite atypical or almost impossible. So far I have not read anywhere that it says that members of one development team can sometimes (or in parallel) participate in another development team, but it seems to be quite illogical, judging by the fact that they have to estimate their time to and in the definitions. project.

In the above I say ‘project’, but I understand it as a product (a project develops only one of the listed products). I understand the task as 3 separate products, but all three may be part of the same project. Then, however, we again touch on the issue of maximum participants.
In any case, some balance must be found – it does not matter if all three products are part of the same project (for which there is only one team of developers). They just shouldn’t be less than three and no more than nine.

The director does not want a certified Product Owner for a low-priority project

These are 3 separate projects with one product each. Ie there must be 3 different teams. According to Scrum, the Product Оwner should always be there. The Certified Product Owner is part of the Scrum team, no matter what. As well as the Scrum Master role. It doesn’t depend on how priority or big the project is, it’s just a written rule in Scrum.

Even if the product is a lower priority, the work of the product team should nevertheless be prioritized and the quality and performance of tasks and progress should be monitored.

The role of a certified Product Owner cannot be avoided as he is the person who oversees these things. Reference: Product Owner Certification online programs in 2021 and 2022, https://pgov.org/productownercertification/ He is the person who helps the development team with communication with the stakeholders, if necessary – the explanation of the tasks. If there is no Product Owner in the team, then who will create and prioritize the backlog and tasks? Who will be responsible for the release management and who will be responsible for all the work to the stakeholders?

If there is no certified Product Owner in the team, then the whole project loses its meaning – there will be no specific tasks to solve, nor will anyone be responsible for what is done.

When the Scrum Master role should be the manager

Here we return to one of the questions on previous topics. The director is a director – he is not directly involved in the Scrum team. The director is part of traditional senior management and is not part of Scrum. There is no such position as ‘general manager’ at Scrum. If he wants to be part of the Scrum team, he can be either a Product Owner or a Scrum Master, or part of the development team. As described, the role is most similar to Product Owner – setting tasks daily, but setting tasks should be done according to Scrum’s practices – through prioritization and planning (sprint planning).
This, with the requirement of reports from each member, is not a Scrum practice, or at least it is not recorded as such. At Scrum, no one requires reports from anyone – it is believed that the team voluntarily informs about the work done and the problems of the events organized for this purpose Scrum. Of course, there are situations in which the status of one of the team members must be required, but this should not be taken in the sense that someone is necessarily watching everyone under a magnifying glass and in no case should be accepted as a normal practice. . Of course, this should not sound like the project is going well – there is always monitoring and analysis of progress, but it is not every day. In general, a lot relies on the self-organization and initiative of the team and the responsibility of each member to the tasks and their implementation.

Certified Project Manager instead of Product Owner

The director tells you that for each product, the client has appointed a project manager, who in case of urgent requests, will assign to each member of the team, a priority task for the day.

That he wants to hire a certified project manager is OK. It seems a bit strange to me, however, that he considers some of the products to be less of a priority but still wants to have a project manager for each of them. But that’s OK for me as a member of the Scrum organization, I shouldn’t have anything to do with it.
Regarding the intervention of the project manager (and any other managers) in the work of the Scrum team, I will comment that this is a bad, if not completely wrong practice.

The development team receives its tasks from the Product Owner after the Product Owner and Scrum Master agree and are aware that this work will be done in the specified sprint. Reference: What makes a good Product Owner and what do they do? (Scrum Time, ISSN 2652-5445, 2020), author: William Anderson, https://scrumtime.org/what-makes-a-good-product-owner-and-what-do-they-do/ Tasks do not come from other managers in the organization – or at least if they do, they are not assigned by the management directly to developers. Here SM plays a key role – it protects the team from any external interference that can defocus and slow down the work of the team. Such intervention is possible, but it is not direct but is agreed with the Product Owner and Scrum Master before being set as a task for the development team. The task must be prioritized (by Product Owner), specified and described (again by Product Owner) as such – to exist in the backlog. Plan in a release and sprint (Product Owner, with the assistance of Scrum Master) and make sure the team understands it and will have time to complete it. Reference: What are the responsibilities of the Product Owner role in Scrum?, https://eduwiki.me/what-are-the-responsibilities-of-the-product-owner-role-in-scrum/

My last comment is that it sounds a little confusing and frightening that someone may suddenly come and give you a task for the day – this may be possible in some extreme situations, but this moment of surprise should be avoided. The team should work calmly and with tasks planned and known in advance, and not work should be planned from day to day, let alone on the day itself. Again, it would be considered out of focus and stress if managers ‘drop’ tasks that suddenly become so important that they can’t wait until the next sprint planning and need to be resolved immediately. Sounds like a problem in planning or knowing the product, if that’s the case.

When a senior programmer will be Team Lead

One of the senior programmers of the teams told everyone that since the team is large and he has a lot of experience, he will officially accept the role of Team Lead. He adds that he will choose technologies, offer a way of work to each member of the team, and monitor the progress of the tasks.
A basic principle of working in a development team is that no one can declare himself a leader and set tasks or tell others how to complete the tasks. The team decides for itself which tasks to choose for development, without anyone else giving them. The work in the development team is based on equality and high professionalism in the specific field. There are no leaders or people with more authority in the team. Everything is decided by common consensus throughout the team.
As for the fact that this senior specialist will choose for himself what technologies to work in and how to solve the tasks – this is again contrary to the understanding of Scrum. He can offer the team new technology, but he can’t impose it. If the team considers by consensus that the new technology contributes to the product, then there is no problem to accept it as a solution. But this should be done with open discussion and general agreement, and not for someone to impose something. Here it is important to mention what you write in the lecture – that the fact that this specialist thinks that the new technology is very good does not mean that everyone else on the team feels confident in using it. If there is such a sharp change in the tools used, it leads to stress and mistakes and the team is not effective in their work.

When novice developers run away from responsibility

A new employee in your organization, hired recently, tells you that because he is a novice specialist and is still on probation, he prefers not to interfere in team decisions and does not want to take responsibility for working on the product.

From the very beginning, we explained that very often in the Scrum teams there are people with different qualifications and fields of activity, as well as different levels of this qualification. Scrum implies teamwork and openness and awareness – a member of the team should not feel threatened in any way if his qualifications are not at the level of others. On the contrary – honesty in the relationship is considered an advantage and is encouraged.
Each member of the team contributes to the development of the product – those with lower qualifications, too. One cannot break away from the team on one’s own and not want to participate, as this is considered a lack of interest and commitment to the project and the work.
If a person is insecure, it would be good to talk about their problems with Scrum Master and tell him that he needs additional qualifications, this should not be hidden, because it interferes with efficiency and expectations. This is not a problem of the specific team member, but should be considered a problem of the whole team and solved as soon as possible.
The successes in the Scrum team and in particular the development team are common, but the problems are also common.

The development team works remotely

You understand that most of your team members have already talked to your HR manager and received permission to work outside the office.

I think it is problematic for everyone to negotiate with HR or someone outside the team on their own before discussing the problem with the team itself. If office work is a problem, then this should be resolved with the general consent and participation of the team, and not everyone should talk to HR alone. As stated in the question, only part of the team was allowed to work outside the office, but some did not, or did not consult, HR.

The team should physically be in one place during work, I think this is also mentioned in the Scrum bagpipe. I understand what the problems may be here – again related to unclear communication, distractions from the environment, even a bad internet connection (if there are frequent calls or video conferences).
However, I dare say that the business is slowly learning and getting used to the idea that people can work in a team perfectly, even when they are at a distance. In my opinion, this is a slightly outdated notion that we must sit in one room. Recent experiments and analyzes now, in connection with the Corona situation, prove that things are entirely possible, even when people do not have direct physical contact.

A member of the Development team works alone

A member of the Development team introduces you with joy and delight that outside of working hours, he has written a large collection of program code that he can easily add to the product, and through it speed up many of his tasks and some of those of the rest of the team.

In general, I don’t see anything wrong with someone working on a project in their spare time – as long as they do it of their own free will. Of course, one must also take into account the fact that one needs to take time off from work to be more efficient when at work.

The only problem I see here is that he may not have coordinated his development with the rest of the team. If he did and everyone on the team is aware and agrees with the solutions he offers, I don’t see a problem with the code being added to the increment. However, the goal is common – if the decision helps others, it is welcome, but it must be with their explicit consent. Provided that the code also solves the tasks of the other members of the team (who have committed themselves to the task and have taken responsibility for it), they must give their approval for the decision after having read it in advance. However, the tasks for solving the task are the time a person spends working on the task – people are not expected to work extra from home (and some companies do not even pay for these hours).

When the certified Product Owner estimates the tasks

The development team offers you the idea that you set an estimated time to complete the tasks, and that they focus on their work and devote their time to the tasks. They shared this with the Product Owner role, and he was quite pleased. Reference: Responsibilities of the Product Owner – Questions and answers, https://brightonbot.com/responsibilities-of-the-product-owner-questions-and-answers/
This is against Scrum. Estimates are something for which the development team is responsible and is done by him alone. This is because they are the ones who have to solve the tasks – according to their own pace and abilities. No one else can do it for them.

Reorganization of teams

The teams of the three parallel products being developed by your organization have decided to reorganize. Their desire is to be divided into teams according to their profession and qualification. One team will be programmers, the second designers, and the third quality control. You have been nominated as an activity coordinator.
Again, it doesn’t match Scrum. The goal of the Scrum development team is to deliver a sufficient, complete, and complete product. By dividing the tasks in this way, none of the teams can create a team to provide an MVP that can be tested and work according to the requirements for what is developed in the sprint.

When your Product Owner prohibits logging defects

The Product Owner has asked one of the team members not to temporarily report problems and defects on the product publicly in your defect recording system, but to fix them himself.

He is obliged to register them in the system because otherwise, he will use the time that is estimated for other tasks. After the repair, it may be necessary to test again (by quality control and/or stakeholders) – they will not know how to plan their time or what to test. This is completely wrong, as it is possible that the problem is not a ‘problem’ – a small, minor, or non-priority defect that does not need to be corrected now. Furthermore, the developer can never be sure that the problem is exactly what he thinks (unless it is technical, due to his work), and he cannot be sure that what is fixed is actually what is required (no acceptance criteria).

Leave a comment

Your email address will not be published. Required fields are marked *