Thread by @tastapod

That's a valid challenge. Allow me to clarify:

Scrum as a method is outdated. It was groundbreaking in the early '90s but has hardly changed since. Some of its presuppositions have become invalid, ironically through its own success.

Two examples, the Product Owner and Scrum Master roles:

The Scrum Master was originally about coaching people from different org. silos who had never worked together and who often harboured mutual mistrust. It has become a cipher for a traditional PM role, assigning work, setting sprint commitments/targets/forecasts/what have you, etc

The Product Owner similarly was about showing the team they were building a product not turning requirements into code (as a dev), or turning code and test plans into bug reports (as a tester). It has become an order-giving proxy customer, and adding an extra level of indirection

The original sprints were six weeks, so you would do two sprints and then a release at the end of the quarter. This made sense in a context where people assumed a feature would take several *months* to write, but not when you can build several features in an afternoon.

A two- or three-week "sprint" is exactly long enough to run a mini-waterfall project, with all the transaction cost, stress and blame that implies, with planning and estimation theatre at the start and testing squeezed at the end. Madness in this day and age.

So that's the process itself. The shilling is execs being told they just need to sheep-dip train (@andyhunt's lovely expression) their several hundred delivery people at huge expense, and they will magically become "agile".

You and I both know this is nonsense, but it doesn't occur to the (usually well-known) person or people brought in to conduct said sheep-dipping to communicate this, so the transfer of cash, certificates and time ensues, and two years later nothing has fundamentally changed.

and now "agile" has a bad name, and folks like us are on the back foot trying to explain that there really is value in looking at flow and focusing on the customer, and taking technical rigour seriously, but it's an uphill struggle from an unnecessary disadvantage.

/ends

oops, I meant @PragmaticAndy of course.