Nope, it has nothing to do with the commonalities in people or roles, sorry I wasn't clear. Let me try again.
It's a knock on all rigid processes and dogma, not agile in particular. I trimmed the rant down by taking out the sections that rip into UX firms, with their Big Upfront Design and cocky rockstar designer personas, but it could just as easily been about them. I only cut it because I thought the parallels were obvious with the diagram on the Epic Consulting website.
What I'm saying is that if waterfall means people are grouped together by specialty - programmers with programmers, designers with designers - each group is run by one dominant process suited to only one of the specializations, and each group tends to work in different stages, then both traditional UX design and agile development are run as de facto waterfall teams, whether by explicit hierarchies or simple stakeholder buy-in.
Consider this - what's the difference between:
1) a PM spec'ing things out in advance and basically telling everybody what to do and in which order.
2) an agile shop coding things up on the fly and telling the designers to run after them to clean up the visuals without making major changes, so they might as well be building to a spec.
3) a UX firm mapping out how the product works before handing off to peon engineers that can't make major changes and might as well be building to a spec.
To end on a positive note, there is one other solution to expertise, by the way. It's grouping teams by product, not role, and figuring out an interdisciplinary way to work together, rather than running the entire team by the methodology of one specialty. That way you're picking good ideas from across different processes and adapting to the company culture to boot. For example, TypeKit does daily stand ups at 10:05am every day and that's an aspect of agile that they've liked enough to use for the whole company, but I'd be surprised if their designers were checking their art assets into Pivotal Tracker or the programmers were writing up UX journey maps of each user persona.
Steve Jobs always liked to describe Apple as the biggest startup he knew and a more accurate description would be that it's a collection of startups, with each one focused on a single product. Seems to work pretty well for them.
This is the paper that was the basis of Scrum: The New New Product Development Game, Harvard Business Review, 1986. [1].
The crux of the paper is that you should be "grouping teams by product, not role, and figuring out an interdisciplinary way to work together, rather than running the entire team by the methodology of one specialty".
If the word "Agile" freaks you out, then by all means don't call it that. And certainly there are a lot of bullshit artists plying their trade out there. Indeed, if someone tells me they are "Agile", by default I don't believe them. But as this 1986 paper shows, there is a lot of good data and good theory out there if you but look.
I agree that "agile" teams that group people by specialty are clueless. Done right, the teams are, as you suggest, cross-functional. That was the original intent for the people who coined the term Agile, but much of that has fallen by the wayside as larger organizations decided Agile was fashionable and consultants rushed in to sell them 3% dilutions of XP or Scrum.
That's a great writeup! I know exactly how you feel except my disappointment was doubled, because I was a hybrid developer/designer for years before completing the switch from developer to designer and I lost the faith in both agile and UX at about the same time.
I wish I had the courage to write up my disappointment like you did, but I'm happy that I've moved on to a meta-process of borrowing from different techniques as needed.
It's a knock on all rigid processes and dogma, not agile in particular. I trimmed the rant down by taking out the sections that rip into UX firms, with their Big Upfront Design and cocky rockstar designer personas, but it could just as easily been about them. I only cut it because I thought the parallels were obvious with the diagram on the Epic Consulting website.
What I'm saying is that if waterfall means people are grouped together by specialty - programmers with programmers, designers with designers - each group is run by one dominant process suited to only one of the specializations, and each group tends to work in different stages, then both traditional UX design and agile development are run as de facto waterfall teams, whether by explicit hierarchies or simple stakeholder buy-in.
Consider this - what's the difference between:
1) a PM spec'ing things out in advance and basically telling everybody what to do and in which order.
2) an agile shop coding things up on the fly and telling the designers to run after them to clean up the visuals without making major changes, so they might as well be building to a spec.
3) a UX firm mapping out how the product works before handing off to peon engineers that can't make major changes and might as well be building to a spec.
To end on a positive note, there is one other solution to expertise, by the way. It's grouping teams by product, not role, and figuring out an interdisciplinary way to work together, rather than running the entire team by the methodology of one specialty. That way you're picking good ideas from across different processes and adapting to the company culture to boot. For example, TypeKit does daily stand ups at 10:05am every day and that's an aspect of agile that they've liked enough to use for the whole company, but I'd be surprised if their designers were checking their art assets into Pivotal Tracker or the programmers were writing up UX journey maps of each user persona.
Steve Jobs always liked to describe Apple as the biggest startup he knew and a more accurate description would be that it's a collection of startups, with each one focused on a single product. Seems to work pretty well for them.
EDIT: fixed a few formatting errors.