Multiple Component (or even Feature/Product Teams) Teams, sprinting concurrently != LeSS
Is this and attempt to scale? This is copy-pasting, at best.
If different products are involved, why same sprinting schedule matters?
If teams build the same product but do not share a backlog/PO – what is the benefit of concurrency?
Is this just a political checkmark: we are on ‘enterprise-wide schedule’? All ducks are put in a row. Dotting Is and crossing Ts.
“LeSS Huge – Is Our Ultimate Goal” – this is a really a sound and smart goal.
Advice: keep things small (Scrum)
Advice: go Scrum -> LeSS -> LeSS Huge – only IF a product is big or grows. NOT because your organization is big.
1-2 Teams per [Product] Requirement Area != LeSS Huge
Your best case scenario: if you deal with a real product and-if real feature/product teams, then you still deal with: scatter of knowledge, local optimization, silos
Your worst case scenario: you already deal with component teams, pretending that they ‘do Scrum’
Technology Area != Requirement Area (of LeSS Huge)
The problem has its origin in mistakenly taking component/delivery teams for being feature/product teams, and therefore, defining a product, based on technology, not on business.
“Area Product” (meaningless term) != [Product] Requirement Area. This is probably:
Inability to separate noise from signal, by unexperienced people, trying to interpret LeSS terminology, without due attention
Example of hijacking terminology: “we heard the term, it was eye & ears appealing, so we shall just re-use for our own needs”
Indicator that a real product definition is missing
