The title is provocative (it's a numbered list, and a rant!) but the author would have been better served with "Seven Ways to Make Agile Better", for no other reason than taking a positive slant. Agile can be built on, its not necessary to tear it down to the foundations first. The article wasn't helpful or illuminating and full of strawmen -- the author is attacking their own definitions of Agile.

Full disclosure, I'm well in to my forties. I can pass for thirtysomething (a reference probably only fortysomethings will get) and once was mistaken for latetwentysomething by someone who was bad at guessing ages, good at flattery, or some of both. But please read the following with full consideration of the biases of age, from which youth is wonderfully immune.

Agile is essentially about shortening feedback cycles. The problem with waterfall was that work products were reviewed when 'complete', when change costs were high and commitments large. Decompose the work products into smaller chunks (backlog items and tasks) and review more frequently -- Sprints (every N weeks), standups (daily), pair programming (realtime). Every work product in a waterfall cycle, not just code, can be decomposed into smaller tasks -- design documents etc. can be constructed iteratively and incrementally, in parallel or sequentially (the latter meaning you can overlay Agile on top of waterfall) with tight and layered feedback cycles.

There are many artifacts, but dwelling on their structure and nature without reference to their essential role leads to superficial criticisms.

When something is broken in Agile always return to the fundamental question of how well the feedback cycle is working and how to fix it. Sprint reviews not providing value? Are they being used for feedback or have they become demo days? Has the standup become a daily status report?