Just today I heard two people give the same naive scaling advice: divide products into independent pieces for different teams to work on. This advise is so common that it’s become a cliché. It illustrates a widespread blind spot in the Agile coaching and training community.
Pre-dividing products would appear to make life easier for Scrum Teams. But in the big picture, it actually reduces the product development organization’s agility:
- Designing an organization around which teams will work on which parts is big up front prioritization. It adds friction to future re-prioritization, resulting in some teams doing work out of priority order. Isn’t Agile supposed to make it easier to re-prioritize? Please see Large Organization Software Development Misconception #2: Are All Teams Working On Equal Value Stuff?.
- When teams only see a narrow view, we put the important problems in the space of traditional management methods rather than team self organization. Please see Large Organization Software Development Misconception #3: Should Our Team See A Narrow View Or A Whole Product View?.
- Customers want integrated products and solutions, not pieces that don’t fit together. Please see Large Organization Software Development Misconception #4: Will Parts Made By Different Teams Fit Together By Magic?
- It reduces team learning about the world outside their “own code.” Please see My Code, Your Code. Private code policies considered harmful to agility.