Cliff Berg
1 min readJul 11, 2020

--

This model (Scrum) works fine for a small single team product. But at scale, it is horribly limiting. A separate QA function is essential to make sure that the products overseen by the various POs are all aligned per the organization's goals and sources of risk. Giving a PO carte blanche is not reasonable.

Also, Scrum's view of everyone on a team being equal does not scale, nor does the assumption that everyone is "full stack". Today's stacks can be very deep; and often there are critical microservices used by many products, that can only be maintained by a particular set of teams. Further, teams often need testing experts to make sure that the behavioral test coverage is sufficient (not talking about code coverage). Programmers are - by nature - terrible at ensuring coverage.

Many of the assumptions of Scrum about human nature are wrong. E.g., the idea that no one wants to be recognized individually - that is just wrong. Scrum's gaps and flaws are not usually an issue in a startup, where everyone is very aligned and share a common goal to launch; but in a mature organization, Scrum's practices lead to dysfunction and so Scrum needs to be modified or scrapped altogether.

--

--

Cliff Berg
Cliff Berg

Written by Cliff Berg

Author and leadership consultant, IT entrepreneur, physicist — LinkedIn profile: https://www.linkedin.com/in/cliffberg/

Responses (2)