Skip to main content

Product owner 'not comfortable' with developers self-organising into squads

Last post 07:22 pm April 11, 2023 by Oliver Flaggl
5 replies
10:16 pm March 28, 2023

Hi there,

I wanted your thoughts on a situation I am encountering.

BACKGROUND

We are a team of around 20 (developers, testers, UX, PO's, SM) and will be splitting into 2 squads in the near future. A question then arose regarding how we will split into these squads. 

MY PROPOSAL

I initially proposed that the potential squad members (excluding the PO's) would be given an overview of the products each squad would manage, in addition to examples of the backlog for each squad. They would then be left in a room to decide on the squad structure for each squad. There would be high level rules such as each squad should be of a equal size, not exceed 10 (as per the Scrum guide) and be balanced in terms of the resource type and skills. 

MY RATIONALE FOR PROPOSING THE ABOVE

  1. There is a question in the scrum exam regarding a scrum master having to split 100 developers into teams. The 'correct' answer is that the developers should be left amongst themselves to do it.
  2. My proposal is promoting the 'self-organising' aspect of scrum guide
  3. Facilitating the developers in self-organising themselves without the Product owners present, will help minimise any bias that the product owners could impart upon the situation e.g. certain product owners may have 'favourite' developers who they want in their squad. They could then influence the session to ensure they get the resource they want.

SQUAD REACTION

  • Upon hearing my proposal, no developers voiced any concerns.
  • A product owner said they were 'not comfortable' with my proposal
  • The product owner then said the team 'was not ready' for this

MY POSSIBLE RESPONSES

I plan on holding firm with my suggestions and addressing the product owners comments with the following:

  1. The developers seemed happy with the approach, as such we should go with it. Whether the product owner is 'comfortable' or not, is not relevant to our task of splitting in to two squads.
  2. The developers did not give any indication that they as a group were 'not ready' for this
  3. The product owner is undermining the developers by proclaiming they are 'not ready', when they haven't said otherwise.
  4. We would be following scrum guidelines by letting the developers self-organise
  5. We could possibly 'revisit' the structure of each squad every quarter or six months, to assess as a team whether we think it is working well (the retros and other measures would also help us with this).

Any thoughts or feedback would be greatly appreciated. 

Many thanks!


04:39 pm March 29, 2023

Your proposal sounds reasonable enough to me, but I wonder if you've made a rod for your own back by advocating squads rather than Scrum Teams. It's a different term, presumably with a different meaning. For all I know, the company understanding of a "squad" is one in which self-organization is unexpected.

The vocabulary we use gives transparency over what we mean, and without a new vocabulary to remind people of the change Scrum entails, they might well hold on to strange notions and prejudices.


06:53 pm March 29, 2023

Why exclude POs? 

Within a Scrum Team, there are no sub-teams or hierarchies.

While Developers know how best to balance themselves to ensure they are cross-functional and able to turn Product Backlog items into Increments of value, that is only one of the Accountabilities for a Scrum Team. Product Owner and Scrum Master are also part of the Scrum Team and I think they too have a part to play in team formation. 

I know Ken wrote about this 10 or so years ago, recommending Developers do it, but that was at a time when we still referred to Developers as the Developer Team. Now there is just the Scrum Team with 3 Accountabilities. Shifting from roles to Accountabilities opens things up as well where we recognize that someone on the Scrum Team may be a Developer who is also taking on the Accountability of Scrum Master (as an example). 

Agree that is not the POs call on the team's readiness.


08:14 pm March 29, 2023

I like your suggestion and wish more companies would use it.  But alas, there is always the corporate hierarchy that isn't comfortable with it.  

I think what you have actually found is that the Product Owner is "not ready for this". The Product Owner does not seem willing to let people doing work self-organize in a manner that they feel is best.  

Did you propose this in a meeting where all of the impacted individuals were present or did you approach the Developers separate from the Product Owner?  If so, did anyone ask the Product Owner how they had arrived at the conclusion that the Developers were not ready? 

If you did not do this in a group meeting, then I suggest you reconvene with everyone together.  Let the Product Owner voice their concern to the entire group and give the Developers a chance to question the decision. 

If a team is going to be self-managing and self-organizing, they will have to be comfortable having difficult conversations in the presence of everyone.  They will also have to learn to respect other's input and compromise on actions.


09:12 pm March 29, 2023

Product owner has NOTHING to do with how, and what you do. Even with Scrum ceremonies(its Scrum masters job)

Product owner own a PRODUCT not a team

He can of course reject accepting the product you develop after the Sprint, but after all its HIS A** on stake with stakeholder about developing value at the first place.

One of the key aspects of scrum is avoiding the Scrum becoming a power game issue. This si acase here, and the Scrum master of your team(if you have any) should educate PO about this


07:22 pm April 11, 2023

Please understand that the fact that no developer raised any concerns is not necessarily a good thing. It’s your job to get as many concerns as possible out of them. Leadership 101.

A product owner is part of the team. Simply ignoring their concerns is not a great move. Learn what the specific concerns are. What problems come to their mind?

BTW: The Scrum guide talks about self-managed teams, not self-organized ones. That’s not the same. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.