- A command should be able to do the increment. But with multiple command the product may become unstable because the changes from different commands may create code or functional conflict. Who should solve this problem and how?
One product has one Product Owner and a one Product Backlog.
In your case, the issue is that you have split the application in multiple non-independent parts which are lead by multiple people. These people are not in agreement and have different opinions, creating the conflicts you stated.
The solution is to appoint a single person Product Owner over the whole product. The rest can be advisors and they can form a comitee, but only one person leads.
- We have no architect role (all members are developers without additional titles), and code quality rules may be different in commands. One of the commands may always add technical debt to the product and the other commands will suffer from it. How to solve this problem?
One product has one Definition of Done.
The Definition of Done is a one document which describe the "quality rules". All the Development Teams contribute to it.
All the technical people needs to sit at a table, propose, discuss and agree on the Definition of Done. Then everybody uses it as a reference.
The teams have different components (e.g. A, B, C, D) of the application inside one big monolith project. And some stories requires changes in several components (e.g. A + C), so people from one team (A) can be affected by code in component (e.g. C) of another team.
While scaling Scrum, the Scrum events are common, meaning all the teams are aligned to them and have them all at once.
Remember: There is a single production (monolith application) and the purpose of using Scrum is to deliver a potentially releasable Increment by the end of the Sprint.
It's clear that all the teams need to collaborate to achieve this. So, during Sprint Planning, the User Stories are discussed in technical details before starting working on them.
In this particular case, the Developers of the two teams agree on how they are going to implement the User Story so that it's compatible. They also they agree on when they will be working on it so that there is enough time to put it all together and deliver the functionality by the end of the Sprint.
The level of details is just enough to reach an agreement, because anyway they might change along the way. When they change, the two teams communicate this in a common Daily Scrum, call it "Scrum of Scrums".
I suggest you scale the Daily Scrum like this:
- First, the Scrum of Scrums takes place. It has a timebox of 15 minutes and it's focused on the collaboration of the two teams and integration of work. The Developers from both teams join and discuss.
- Second, each Development Team has its own Daily Scrum.
Any technical topics are discussed right after, with the Developers working on it. They may be from different Development Teams.
To quote Ken Schwaber, one of the founders of Scrum:
Scaling carries with it the responsibility that all of the attributes of the smallest element are found in the sum of all of the elements (100 or so teams perform like one team)
So, when a Development Team grows beyond the optimal size (at most 9 members), it is split into two Development Teams. These two teams need to work together as one or the essence of Scrum is lost.
Scaling Scrum is tricky and is not a one size fits all solution. There are many frameworks that claim to do this, but fall short because the essence of Scrum is lost along the way.
To quote Ken Schwaber again:
The introduction of things like the Scaled Agile Framework, disciplined agile delivery, and enterprise shared services started to reintroduce methodological, prescriptive, one-size-fits-all thinking back into software development, at the same time claiming that it was agile. However, all of these approaches fall apart at the software development level. They typically just say, "use scrum," but scrum is a one-team, one-sprint thing. Also, these methodologies don't tell you how to run large, multi-team scrum projects or programs.
In a successful scrum implementation, when organizations want to execute large projects or releases for up to 3,000 people, they devise their own techniques for working out dependencies, cause frequent integration to unearth festering dependencies, and adopt continuous integration and build.
In conclusion, teams and organizations should use Scrum "as is" for one team and devise their own techniques for working out dependencies when greatly scaling Scrum.
In practice, team and organizations try to customize Scrum for one team (because Scrum raises many issues) and use a fixed framework (SAFe, LeSS etc) when scaling Scrum (because they are losing it completely). This is how the essence of Scrum is lost, but everybody claims they are Agile.