Why We Do Not Recommend Trying To Break Products Into Small Independent Pieces For Small Teams
Just today I heard two people give the same naive scaling advice: divide products into independent pieces for different teams to work on. This advice 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:
- As you may know, agile developers try to avoid big design up front. Designing an organization around which teams will work on which parts is big prioritization up front. 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.
Instead we want teams working together toward a shared product vision and priorities.
