Last time, we looked at how Scrum has become the de facto definition of Agile, and how it is uniquely lacking in technical practices compared to the other methodologies that were involved in creating the Agile manifesto.

This lack of technical good practices and craft causes some obvious deficiencies, but first I want to look at some of the second-order effects. Starting where we left off last time, one of the problems with Scrum is that product has an owner, the Scrum process itself has a master, but no-one is empowered to advocate for development priorities. (This is part two of my "How Scrum destroyed Agile" series; part one is here.)`

The Product Owner in a scrum is typically someone from the business or product side of the business. They are not there to advocate for technical priorities; and indeed, this is fair enough, because someone needs to advocate for business and customer value. Scrum intends them to be “responsible” and “accountable” for the product backlog, and therefore to work with others to create backlog items, but in practice, they are typically the sole person creating the backlog. So, they are setting the direction of development, but without any thought as to practicalities of the development process.