Product owner ability to change how a team plans

It sounds like the old way might indeed need to be "deprogrammed", but the new way also needs to be challenged. Neither seem to be reflective of good Scrum practices. Why isn't the team getting sufficiently granular to understand its capacity and ability to deliver? Is it up to you to provide a salve to this problem? What is the Scrum Master's take on this?

This is answered in the sprint planning chapter of the scrum guide: 

Topic Three: How will the chosen work get done?

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

 In my BSA role we were tasked with a lot of the responsibilities of the PO and Scrum master (priorities, running ceremonies, planning etc.) 

Based on that statement alone I would suggest that you deprogram the old way out of your head because it doesn't indicate that Scrum was being utilized properly there either. 

It is more of a quasi kanban method.

Based on that statement, your new company isn't following the Scrum framework either.  That being said, the Scrum definitions of Product Owner aren't entirely applicable to your current situation.  

It does appear that both your old and new company wanted to have some agility in their practices so take that as your starting point and not the Scrum Framework.

Does the PO have the ability to facilitate a change in doing work?

They hired you to come in with new ideas.  Why wouldn't you voice them?  Should you force anything?  Absolutely not.  But having conversations with your team on how it is difficult for you to do the job you were hired to do is something I encourage.  A self-managing, self-organizing team should be willing, and able, to adjust based on new situations.  A new Product Owner is a new situation.  Let them know how you have seen things work well in the past and then discuss with them how to adjust the current system so that everyone can benefit from it.  Then inspect the new system and adjust it as needed.  Then inspect the newer system and adjust it as needed. (I think you get the idea from here.)

When a company is agile it expects and embraces that environments change and that they will have to change in order to be successful.  

@Benjamin - this is a great question.

I am a developer on a project which I am beginning to understand is being micro-managed.

There are multiple teams.

The product owner decides and delegates the work to each team.

A typical sprint now looks like this where X, Y & Z are main features in the overall product

Team A

Do something in X

Do something in X

Do something in Y

Fix bug1

Team B

Do something in X

Do something in Y

Do something in Y

Tech story1

Team C

Do something in X

Do something in Z

Do something in Y

Spike for new feature

Product wants stories to be refined & estimated for 2 sprints ahead and they prioritize the stories that go into the sprint.

Is this OK? Or is this micro management?

If this is micro-management then what can I, as a developer - with ZERO EMPOWERMENT, do to try and implement improvements?

@Benjamin - what is the motivation for having the granular information? Were there fixed deadlines? The development team needed this level? Indeed, some development teams unfortunately want to be micro managed.

If this is micro-management then what can I, as a developer - with ZERO EMPOWERMENT, do to try and implement improvements?

Is your Product Owner participating in Sprint Retrospectives? Has the Scrum Team openly had a discussion around what's working and what isn't with regards to the process?

You mentioned "they prioritize". Is there more than 1 Product Owner for your Scrum Team? There is something called the Santa Claus rule. No matter how busy Santa gets, there can only be one Santa. But Santa can ask for help from as many elves as needed.

I am also curious to know if you have a Scrum Master helping to bring transparency to the issues raised?

hi @Chris - thanks for your questions:

* There is only one PO. Each team has a Business Analyst. There is also only one product backlog, thankfully.

* The PO does not participate in the retros. There are multiple teams and so therefore multiple retros, there is not enough time to participate in all. 

* We do not have a full time scrum master. However, I think some discussions are happening but not with the full team.

* The Scrum Team has not had an open discussion around what works and what does not work. As the retro only consists mainly of the dev. team there may be a belief that there is not much we can do.

@Seamus Finn, you are using a lot of Scrum terms but you are in no way using the Scrum framework. Your description sounds like waterfall project management.  You need someone that actually knows, understands, appreciates the Scrum framework to help others achieve the same.  You need an organization that is recognizes that they want to change while also being willing to accept that they will have to change and constantly adapt the way that work is planned and accomplished.  

As someone with "with ZERO EMPOWERMENT" I think you are underestimating your influence. Even if no one but the Developers are present in the Retrospective you can still have these conversations.  If all of you feel that there are changes that would help you be more efficient and successful, implement them.  If they require the Product Owner be involved, then involve them. Explain to them why all of you feel this is a needed change and help them understand the benefits it provides. As a group you can start to be empirical in your behaviors and help others see how that can be used for the benefit of all.  If the developers feel that having a full time Scrum Master would be beneficial, then start lobbying for it with your management team.  But make sure you know what it is you are wanting. Read the Scrum Guide (https://scrumguides.org/scrum-guide.html) paying attention to the artifacts, events and roles.  But remember that you are not reading a methodology, you are reading a framework.  As a developer you should be familiar with how frameworks can be used.  

hi @Daniel

you are using a lot of Scrum terms but you are in no way using the Scrum framework

thanks for making this official in my mind.

You need someone that actually knows, understands, appreciates the Scrum framework

Yes.

So what would Scrum done properly look like? Many in my project would argue we are doing Scrum by following the rituals etc.

My issue is that I know & feel deep down that what we are doing is not Scrum, but I do not know what it should look like.

So what would Scrum done properly look like? Many in my project would argue we are doing Scrum by following the rituals etc

Outcomes will look different when comparing a mechanical Scrum Team versus a Professional Scrum Team living the Scrum values of respect, courage, focus, commitment, and openness. Outcomes you might see from a Professional Scrum Team by observing trends over time:

• Self-management and autonomy is clearly evident. Decisions are driven down to the Scrum Team.
• Everyone is clear on the team's vision and goals
• The Product Owner is fully respected and has all the full authority to make decisions, acting as an entrepreneur 
• Psychological safety is evident - no one is afraid to make mistakes, run experiments, and the team has each other's back
• Developers work together on PBIs rather than as individuals
• Context switching is limited
• Dedication to continuous improvement is demonstrated; in other words actions from the Sprint Retrospective is more than lip service
• The Sprint Goal is met every Sprint, and at least one useful, valuable, and done Increment has been created by the end of the Sprint. And this is celebrated by the Scrum Team. If the Sprint Goal is not met, everyone takes it to heart and collaborates on how to make the next Sprint better

Many in my project would argue we are doing Scrum by following the rituals etc.

There are no rituals in the Scrum framework.  @Chris Belknap provided some great things that will happen.  Some others

• Work is planned a Sprint at a time
• All work done during a Sprint is for the purpose of satisfying the Sprint Goal that is determined at the beginning of the Sprint.
• Each Sprint updates the Product Backlog based upon information gained while doing the work and from feedback given by stakeholders.
• Developers are respected by everyone, including the Product Owner, to manage their own work.
• Everyone trusts each other to do work for good and that no one will intentionally do something that will damage the team, the product or the organization.

I will say that it is not always easy to get to this.  It often takes pain to find solutions so there could be bumps along the way.  But remember when something doesn't go the way you expected, the only failure is if you choose not to learn from what happened.

@Chris, @Daniel - thank you both for being so engaging. These conversations are lacking in our project.

@Benjamin - I have hijacked your thread, my apologies. However, I would still be interested in knowing what the motivation for the granular information is from a PO point of view.

Let me address some of the points above

Work is planned a Sprint at a time

We do plan each sprint at sprint planning. Stories have been refined / groomed and estimated for the most part and the goal is assigned when we finish defining the sprint. The goal is normally a list of features.

The Sprint Goal is met every Sprint, and at least one useful, valuable, and done Increment has been created by the end of the Sprint

We are delivering business value at the end of each sprint. Most of the Sprints are completed and deployed to production a day later.

A question on decision making then:

Decisions are driven down to the Scrum Team.

The Product Owner is fully respected and has all the full authority to make decisions

Is this not contradictory? My exposure to Scrum has been that Product decides and that is that. Development teams can only make technical decisions. They don't know the business. Is that the difference?

Is this not contradictory? My exposure to Scrum has been that Product decides and that is that. Development teams can only make technical decisions. They don't know the business. Is that the difference?

Correct, the Product Owner of the Scrum Team has full authority to decide the "what" amongst other things (like owning the product vision, managing budget and deciding how to spend it, release planning, etc.). In other words, they are not simply a scribe acting as a business analyst detailing the Product Backlog items, or a proxy Product Owner who has to go ask someone else outside the Scrum Team for permission. If your Product Owner cannot make fast decisions because they have to "ask permission", that may be a sign they don't have enough authority. In some larger companies, I have seen hierarchies of Product Owners created where a "Junior Product Owner" reports to a "Sr Product Owner". In Scrum there is one and only one Product Owner. And for the record BAs are awesome, I am just pointing out the Product Owner accountabilities and authority are much greater.

The Developers of the Scrum Team (as of the Nov 2020 Scrum Guide there is no longer a Development Team, it is one team) decide the "how", aka the technical decisions. As long as no technical person from outside the Scrum Team is interfering or overriding those decisions, then that seems like a good situation. The Developers also get to have the final say on how much work they can pull in for a Sprint, the effort, and "how" they will turn the Product Backlog into a useful, valuable done Increment by the end of the Sprint. 

You had mentioned micro-management in a prior post. Perhaps an example might help? Red flags go up for me around that term because it may impede self-management.

@Chris,

* There is only 1 Product Owner. The PO is empowered to make decisions without having to ask for permission AFAIK. And we have a very good experienced BA with us.

* The developers (team) are not influenced externally by technical decisions, those decisions are made by the developers (team) only. The team decide when their capacity in a spring has been reached in the sprint planning.

With regards to micro management:  Our backlog is broken into user stories that can potentially fit in a sprint. Product decides who does what and when that should be taken on when there is capacity. So product knows roughly what will be tackled in the upcoming 2 or 3 sprints. This is what @Benjamin also describes in opening this thread when he talks about granular detail.

Tech stories which may have refactoring (yes, the big bad word!) efforts are pushed back by Product when possible. So the teams are told what they will be expected to work on in the upcoming sprints and do not for the most part get to decide the priority of their work. Product is not concerned with the technical implementation, nor interferes with those decisions, they are only concerned with the amount of time to complete the story.

To try and explain, here would be what our upcoming sprints could look like. This is just for 1 team (Team A in this example). Each team has the next potential sprints assigned with stories.

Would you consider this micro management?

Current Sprint for Team A

User Story 100

User Story 145

User Story 122

User Story 103

Next Sprint for Team A

User Story 144  (refined & estimated)

User Story 135  (refined & estimated)

User Story 88

User Story 89

User Story 112  (refined & estimated)

User Story 124

Sprint After Next Sprint for Team A

User Story 101

User Story 110  (refined & estimated)

User Story 111  (refined & estimated)

User Story 116

User Story 321

User Story 137

Product Backlog (No Teams Assigned)

User Story 350

User Story 353

User Story 349

User Story 357

. . .

etc

The situation you described shows that the Product Owner doesn't respect the Developers to do the work that is necessary.  If the Product Owner feels that they have to plan out 2-3 Sprints in advance stating exactly what will be in those Sprints, he doesn't believe that the Developers will do the right thing.  If the Developers are in fact not delivering the items that need to be, then the Product Owner is not doing a good job of communicating the needs. 

I understand that Product Owners are accountable for being able to forecast delivery.  But there are ways to do that which still allows for freedom of decisions.  ActionableAgile provides many metrics and data points that can be used for that.  I suggest that your Scrum Master and Product Owner read the book by Daniel Vacanti (It is available from many places if you Google). There is also a toolset that was created with his cooperation (https://actionableagile.com/) that is invaluable. And if you use Jira, it is available as a plugin. 



There is a difference between forecasting and dictating.  Forecasting allows for flexibility. Going to my stand by explanation of forecasting.  When you hear forecast most people's minds will jump to weather forecasts.  But how long in the future do you expect them to be accurate?  Long term weather forecast might help you decide if a big event 3 months from now would be possible outdoors.  But you would still monitor it, adjust your plans, and make continingies until you get closer and the forecast can be more accurate.  This is the key to agile software delivery.