I was wondering this as well. This all seems like the complete exact inverse of shaping in some ways and reenforces some others. Generally for small, extremely skilled teams, the Shape Up methods are hyper efficient and can focus on a product/engineering goal, notably it forces management to define deliverables in clear and specific terms that outline a developer's jobs to do and semi-long term goals. This allows the dev to work on building something in whole rather than parts but with defined time and outcome goals. (~6 Weeks in the Shape Up Guidelines). An interesting Shape Up Guideline, (also seen here) is the idea to avoid excessive long term planning or backlogs.

Agile is shown as God in this post but..why is Agile so good according to the author? The main advantages is the ability to course correct fast and be reactive but if you are making good work, Agile blinds you from seeing the whole product and causes bad, segmented, low-focus mistakes. If you are TOO agile you may build a DB/API/Logic/Data structure that is too narrow and limiting of the eventual goal.

Personally the real danger of this thought process is that it limits developers from understanding the whole of what they may be building. That's downright draining, makes every sprint seem like going to a run to nowhere. This method and plan seems just like an excuse to let management do less and define and shape work to be done less so that you can avoid the dangers of 'Waterfall'.

Hey, thanks, didn't saw it before. For who may be concerned : https://basecamp.com/shapeup/shape-up.pdf