The roles understanding in the agile development / Is the PO always right?

Question

We have some problems in our team which I would like to describe here:

• The test is almost only represented by a test in the agile team. He is entrusted with all eventualities. From planning, structuring to acceptance test, exploratory testing. The tester criticizes this massive work overload, and that for months in the retro. But there is no solution, or no solution is offered. Thus, the sense behind the retro is not given here.

• We also have a big difference between the Project Owner and the UX development team. Yes, it is true that the PO has to take the decisions alone, what will be done in the next sprint, whether technical orientation or UX. But does not the UX team have any rights in an agile team? How can this topic be solved sensibly, currently almost every retro drifts off.

Where do you have the role understanding within an agile development? If problems are not solved in a retro (Too little time / Too little money / too few developers) how to handle it?

If a PO can not solve the problem. Because he is offered no solution by the management. How can he then solve the role of understanding in decisions accordingly?

From my point of view, we are coming to the limit of the feasible here. Whether agile or waterfall.

Can the PO but according to a "You make it immediately" mentality prevail?

Even if he actually harms the team, because the actual problems (even if not his problem) are not solved?

Here are several problems:

• No understanding of management for agile development

• A PO that does not teach management that you need more people and capacity

• An ambiguous view of the PO but also the agile departments.

• Is the PO really always right?

• Can the PO also decide to harm the team?

• The retro does not work because there are no solutions. The other major issues can not be solved.

  • The team feels betrayed both by the PO and by the management. This leads to angry reactions.

As you can see, it is not going well. And so far any attempt to change this situation has failed.

We tried as a team to talk to the PO and the management.

We have suggested solutions.

In one-on-one talks, we also have the chance to talk to people at eye level apart from the retro.

Maybe you have an approach that we have not thought about yet?

Answer 1

As long as the PO is responsible enough to take the blame if the product fails, it should not be a concern. The project team will be concerned if the PO shoves all the blame on the development and the design teams for a product failure. There will be differences in opinions. When the PO requires something to be done in a certain way, the only way to prevent that from happening, if experts in the team think otherwise, is to communicate what can be and what is, and explain the differences as much as possible and the pros and cons. It requires any agile team time to stabilise and achieve good velocity.

Answer 2

Testing

The job of testing in an agile project falls to all team members. It makes senses to have a dedicated test engineer on the team. But when they start to get overwhelmed with work, other team members, especially developers. It should be part of the code review process to actually checkout and build the changes and test them. This may be a bit more effort, but it results in increased quality and less test / fix / test loops with the dedicated QA people.

Project Owner

The project owner's job is to tell the team what the software should do, not how. Especially on the externalizes, it is not uncommon that the PO can give some suggestions on how certain things should be. But the team experts should have the last say on how something works. For example if the PO suggests to put 1TB of data into Excel, the team should push back and use a proper database instead.

In the case of UX, this gets a bit complicated. The look and feel of an application is a bit of the what and a bit of the how. Often it's more about taste and learned usage patterns. Here it helps to do usability testing. If you can't run a proper external usability test, get people from the inside the company that kind of match the expected users and show them the application. Learnings from the usability testing should override both developers and PO.

Answer 3

Regarding testing, there is no test role in a scrum team. People may have affinity with testing and might describe themselves as testers, but that does not make them responsible for the test activities. The entire team is responsible that all the needed activities to come to a potentially releasable product are carried out.

---

The PO is supposed to have a vision regarding the product that the team is making and based on that create backlog items that are steps towards that vision. This vision may contain UX aspects, so there might be a balancing act between the vision of the PO and the professional opinion of the UX designers. The PO is certainly not always right, but the UX designers are also not always right.

---

One role I did not see mentioned in the question is that of the Scrum Master (SM). The role of the SM is twofold:

1. The SM should see to it that the Scrum process is followed. This includes ensuring that an active sprint is not unduly disturbed by scope changes.
2. The SM should resolve impediments that hinder the team in reaching their full potential. This could include escalating issues to management, for example if there are too few team members with testing knowledge. Or problems that come up in a retro and that are outside the team's ability to resolve.

Answer 4

The test is almost only represented by a test in the agile team. He is entrusted with all eventualities. From planning, structuring to acceptance test, exploratory testing. The tester criticizes this massive work overload, and that for months in the retro. But there is no solution, or no solution is offered. Thus, the sense behind the retro is not given here.

Why is there no solution? The solution is obvious. If a teammate has so much to do that they become the bottleneck, you help them. That means the whole development team is responsible for testing, as it should be anyway.

But does not the UX team have any rights in an agile team?

Matter of fact, they don't. Because there is no such thing as a "UX team" in Scrum. There is the PO with their vision and there is the development team with the abilities to implement that vision. Assuming the development team contains UX experts, then when the stories are refined there can be a lively discussion whether a feature should or should not contain a specific UX, but in the end, the PO decides what they want the product to look like. The job of the development team is help with this decision by bringing the experience to the table and mentioning "costs" (or development time) of each variant. But if the PO wants the product to be blinking pink, then that's their call.

---

I will no quote the rest of your questions line by line, but let me ask you something: does the development team get a say how much gets into a sprint? Because that is the only problem I could see with what you describe.

Sprint planning is a collaborative process. The PO cannot put something into the sprint that the development team did not agree to. As a start, normally the sprints self-adjust based on velocity. Basically you look what you managed in the last sprints and base your current sprint on that. So (very simplified) if you only get 4 stories done of 10, the next sprint you will only start with 4 and hopefully finish all. And then the development team and PO can adjust that. But only together. Bottlenecks or not enough manpower are not a problem of the development team. They will work to the best of their ability. That the product is not ready as fast as the PO needs it? That is the PO's problem. And if they cannot get more resources from management, management will have to live with the fact that the product is late.

---

Scrum is not easy to get right. It looks easy, but it's more than just the guide. I would suggest you get a good Scrum coach or a very experienced Scrum master to get you through the transition. You also need management approval. In actions, not words. If you don't have that (and you hinted at that) you are bound to fail. Scrum is not a grass roots movement. You cannot do Scrum against your management. Because it's a collaborative process and if management does not play ball, it will not produce quality results. And it will come back full circle, when management sees the poor results and says "see it does not work" when in fact they were the one's who made it fail in the first place.

For some reason management is more inclined to listen to a consultant they already paid big bucks to listen to, instead of believing that their own people might actually have a brain, too. So if that's the case... get a consultant. Make management pay for the same thing you could tell them, because to them, advice is worth more if it had cost more.

---

Transparency is a key value of Scrum. You cannot solve all the problems in the team and you cannot make management buy you out of all either. Maybe there simply is no budget to hire another person. Your job is not to work for two, or nag management over something they cannot change. Your job is to make the consequences of that decision transparent. Maybe by providing charts on progress or estimates or simply explaining that it is not economically viable to have a developer test all the time when a specialist could do a much better job. But in the end, that's where your responsibility ends. You reported it. Made it visible. Anything else is up to them.

Answer 5

No understanding of management for agile development

This can probably be solved by handing the managers some basic information, e.g. link to agile manifesto and some blogs about the subject. They also have to understand that no process management format is a silver bullet. Neither agile, waterfall or whatever else you can come up with will automatically solve all problems. Ultimately the quality of the people involved determines that. And I mean quality in terms of role specific skills, but also soft skills.

A PO that does not teach management that you need more people and capacity

Management may or may not be able to afford more resources. And the number of resources should only determine how fast a project can move, not how well it functions. So if they are happy with the speed then there should be no need to add more people.

An ambiguous view of the PO but also the agile departments.

Either role in a Scrum team should have a clear understanding of what their responsibilities are and what the other roles responsibilities are. If that is understood then there should be respect for the decisions each responsible person is taking for their role. Here is a brief rundown:

Product owner: Is ultimately responsible for the product. Hence she can determine what will be developed. But she is doing that through maintaining the product backlog list only.

Scrum Team / Scrum Master: The team is responsible to work on the highest priority topics from the product backlog. They are also responsible for determining how long development tasks take and for organizing the work in the team. Team members should all be technical and everyone should be able to fulfill development tasks. That includes testing and QA related tasks. Many organizations hire "testers" as a separate role from "developer" (often lesser paid) and that seems to be the case in your organization. From an actual agile team perspective that distinction should not be made and a developer should be able to write tests for the SW his team develops. Incentives should ideally be made to the whole team and not individual members. Scrum Master should ideally be a role that is passed to someone else every Sprint (underscores the fact that the development is a team effort).

The team is responsible to estimate their productivity and commit to a set of product backlog items to be developed during the next Sprint. The team should make their best effort and if they frequently miss their goals, then they are bad at estimating and should learn to improve.

A scrum team should not have more than 5-10 people. If it is larger it should be broken up into multiple teams.

Is the PO really always right?

See my previous point. He is always right when it comes to determining what are the priorities for items in the product backlog. This will determine what will be chosen for development in the next Sprint planning. He needs to be trusted in terms of those decisions, but he cannot be involved in determining development timelines or technical implementation decisions. He can only influence development by providing the right backlog items with descriptions for the next Sprint planning. He cannot influence development during a Sprint and he does not even need to be part of Sprint planning if the user stories in the backlog are well described.

Can the PO also decide to harm the team?

That is an absurd question and the answer should be obvious.

The retro does not work because there are no solutions. The other major issues can not be solved.

The retrospective feedback should be mostly for the Scrum team internal organization, but if there are suggestions to management they should be documented and sent in written form to the responsible managers (with CC to upper managers if no reaction / response happens).

The team feels betrayed both by the PO and by the management. This leads to angry reactions.

Fixing the teams feelings should be your first priority. Keep in mind that you absolutely have to trust the PO on his backlog decisions and on the other hand make sure he can trust the teams development estimations and results. If you are frustrated because of a lack of additional resources, then you should organize your scrum team differently. Have some of the developers help with testing tasks and make sure to include those efforts in Sprint planning. This will mean the team can develop less features in a Sprint but everyone will be more happy with the results.

Please note that it is very hard to fix a toxic workplace and it is only possible if everyone wants it to happen. If it happens to be the case because of toxic managers then there is nothing you can do but find another job.

In addition to actually reading the agile manifesto I recommend to watch pragmatic Dave's "Agile is Dead" speech or read his blog entry. With that and a little common sense there is probably no need for a Scrum trainer or consultant.