0

I am a Product Owner / Scrum Master at a small company, my team consists of 4 developers + 1 QA engineer. As a team we handle 2 separate products with some shared products between them. My team has experienced difficulty in meeting sprint goals and company deadlines, often bleeding work into the next iteration or missing release days. I have done my best to structure the sprint to keep the team under capacity (we work in 2 week iterations, up from weekly sprints when I joined, and schedule 5 hours per day of capacity), however scope creep and needing to bounce between products are, in my opinion, the primary cause of our underwhelming performance.

It is very common for a stakeholder (read: client) to approach one of my 2 Project Managers with an "urgent" request, which I face a great deal of pressure to include in the sprint, often with no compromises made for existing sprint work. This issue is exacerbated as one of the Project Managers (for our Flagship Product) also occupies an executive position in the company.

I try to advocate for my team and preserve the timeline, however I am forced to capitulate to the pressure coming from both the top and sides, which I believe frustrates the dev team and causes us further issue when trying to meet our deadlines. I have tried to speak with the dev team during our Retrospective meeting, however they are loathe to speak their minds, despite my assurances.

I have tried the following solutions to preserve the integrity of each sprint and iteration

  1. Focusing each sprint on a single Product (this can include products that share a codebase)

This was rejected due to the aforementioned "urgent" client requests that we get weekly.

  1. Prioritize client requests internally before providing elivery dates

The Project Managers (primarily the one who shares an executive position) provide the clients with delivery dates at the same time the request is made. Preventing internal prioritization or dev team estimate

  1. Specialize each day within the sprint for certain tasks.

This way the dev team is working on the same product for a set period of time within the sprint.

This has been tough on my QA engineer who finds themselves without work for the first day of the sprint and then constantly playing catch up as the team moves forward.

While not specifically a problem, we have also faced difficulties in that the dev team works across 2 shifts. The second shift does not have access to the QA engineer, which causes a delay between resolving an item and it being closed or rejected, but I do not think this is a significant cause of the problems I have outlined.

How can I better adhere to the Agile process and advocate for my team without fighting a bottom up battle with leadership in the company? Please keep in mind, the company instructs that we use the Agile process, so this is not a square-peg round-hole problem of my own invention.

1 Answer 1

2

Okay, okay... some bad news: this is totally dysfunctional. Now, I am in no position to say whether this company is fine and makes money the way it works. Maybe it does. Great for them. But the titles they gave out do not match what people are doing:

I am a Product Owner / Scrum Master

Apart from the fact that every single publication will tell you that putting those two jobs on the same person is a bad idea... you are not. You don't own anything, certainly not the product. By your own description, you have no capacity to say "no", which means you have zero decision power. Your proper job title would be "Product Secretary", because you are the one the product is dictated to.

It is very common for a stakeholder (read: client) to approach one of my 2 Project Managers

In Scrum, the Product Owner talks to Stakeholders. If you don't talk to clients, they are by definition not your stakeholders. The 2 PMs are your stakeholders, that you meet with and that tell you their needs. There is no "Project Manager" in Scrum.

Project Manager

Oh boy, don't get me started. Someone who just pipes every client request through as "urgent" is not a manager at all. My dad worked from his desk at home when he wasn't travelling (I am old, cellphones were Star Trek level science fiction), I learned at maybe age ten to eleven to take calls, take notes and give them to my dad when he came home. That is all your "Project Managers" are doing. Piping through calls. Every unskilled labor callcenter agent can do that, heck even kids in school can do that. Opening MS Project does not make them managers, if they don't actually manage. Their current philosophy is that of a five year old. "But I want that now." Congrats. Their actual job would be to manage. That means that their current procedure of "omg, this is urgent" is the failure mode. That is how you see managing failed, if something is not properly planned, but urgent. But I am sure if you would ask them, they would pat themselves on the back for being so "flexible" und "customer-oriented". That is one way to describe failing at a job.


So what to do? Well, you can start to talk to your boss and ask if you have any decision making power as a Product Owner. If they say yes, then make a plan and stick with it, see if that "yes" was a "political meeting yes" or a real world yes. The PM would have to adjust to actually do their jobs. That would be a hard change for them and they will only do that if their boss agrees that it is neccessary. That is a tough sell, I have not seen that work in many companies.

If the answer is no... either directly, or though the fact that their "yes" was not backed up later when you actually told a PM "no", well... then it is your decision if you like this job enough to stay in it, although you are not a Product Owner in any capacity.

I know you came here for advice on how to handle this in Scrum. But I am sorry to say that if the rest of your company is not doing Scrum and is your boss, there is nothing from any guide or book on process that would help you.

Scrum is not something you can do against your boss. Or other people. It is a cooperative framework. Cooperation can be mandated by he company, but if it doesn't, you are out of luck.

You said your company mandates "agile". Speak to whoever mandates it. Because you aren't doing it. You will find that person is either an ally in your fight to do your job as described by your job title... or, they just like the buzzword or coporate policy without any real idea what it means. Same decision as before: do they pay you enough to tolerate that. Because you aren't going to change your boss. If you need to "manage upwards", your management action should be firing them (aka finding a better job).

2
  • I was afraid this was going to be the response. I admit I have no formal Scrum or Agile training. I was hired for this job shortly after college, so the bulk of my experience comes from mentorship and training within the company itself. I think the most interesting part of your response is that the PO is meant to communicate with stakeholders. I was actually told the opposite, that I should never communicate with a client, as my advocacy is only for the dev team. It is the duty of the PM(s) to interface with clients, gather requirements and write features for myself and the dev team to work on
    – Saurn
    Commented Apr 17 at 15:00
  • Well, in Scrum that is literally the Product Owners job. Project Manager is not a role that exists in Scrum.
    – nvoigt
    Commented Apr 17 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.