Polarized opinions in a team
Hi, recently I've joined a new team as a Scrum Master. My predecessor noted that the team often suffers an issue with highly polarized opinions about the architecture of the system they are developing. The situation is also a bit tricky as the PO was a skilled coder and the product is at a very advanced stage, but got lost somewhere while developing this system on his own before he turned to us for help. For now that's all the information I've got. My questions are:
- is appointing a technical team leader a good solution in that case? If yes what's the best way to do it and who should it be?
- do you have experiance in this kind of situations and how did you solve them in your teams?
- do you know any ways to enchance the team to solve such issue on its own?
Thanks for each and every answer.
Can you clarify what you mean by the product being "at a very advanced stage"? Has there been any release into production yet?
Oh yes, the product is on production. As it is a very complex one, some elements are on maintenance and some are still developed. There where several sprints already.
If it has been possible to release the product iteratively and incrementally, so that its value is maximized, then that is evidence of the viability of the architecture.
Architecture should only be changed if the delivery of value is at risk. For example, if the architecture will not support foreseen changes on the Product Backlog, or if technical debt is causing delivery to degrade, then it may well be necessary to pivot to a new architecture.
The Product Owner is responsible for value based product decisions. Since your PO is an ex-developer, and is presumably able to evaluate technical development choices that affect product value, the Scrum Team is in a strong position to collaborate on this matter.
So, what does the PO think about the architecture?
Thank you for that explanation. The issue here is mostly between two developers working on the same product with highly polarized approaches to each subject. They both have similarly valuable, yet opposing, ideas on how to solve a certain issue. What I was thinking about is a technique that would help them to cooperate and enhance them to reach compromise faster and with mutual understanding, without further antagonizing each other. At this point the rest of the team is fed up with their quarrells often withdraws from the discussion and from making any decision.
From your description I guess the PO and some developers are on one part of the polarization (attached to the existing architecture) and others want changes.
IMO an architecture should support the business in 3 ways:
- Sound technical base to build the product
- rich enough to build functionality in a reasonable clean way
- versatile enough to support the type of changes that can be expected for the product roadmap in the foreseeable future.
If I was in your position, I’d coach the team to make transparent what the current and expected product features are that need architectural attention, and inspect how the current architecture matches this need.
In response to your question, I would refrain from singling out anyone within the team as a "lead" or "expert". That is not a good practice. It undermines the team's self-organization and suppresses collaboration.
You also may be perceiving an issue that isn't there. Patience is an often overlooked but key attribute for an effective scrum master.
Allow the team to find it's way on it's own. I'm reminded of a quote from Lyssa Adkins: "The team's bumbling is better than your perfect plan". You shouldn't burden yourself with the responsibility of "solving" anything. Your focus should be on the team, and helping them work better together and grow as a unit.
Good luck!