Agile. Scrum. Cross-functional teams. UX/UI. Responsive design. These are just a few things that I see misrepresented all the time. Since I've already talked about the difference between UX and UI, let's tackle agile next.
According to Wikipedia, agile is "a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams."
Software development. Not web development.
So why doesn't agile work for web? Web development typically follows the waterfall methodology, where you finish one step at a time before moving to the next one. You do research and requirements gathering first, then you prototype, then you design, then develop, then QA, and THEN you launch the site. It's a pretty tried-and-true method, and there's nothing wrong with it.
In my experience, people try to say that our web projects are "agile" because we work on more than one thing at once. I see two problems with this.
1 - Working on the second thing before you finish the first thing wastes time.
2 - Project managers usually don't understand how the site is actually built.
So let's address these, shall we?
Working on the second thing before you finish the first thing wastes time
I used to work with a CTO who said that design should start once UX is about halfway done. Once the first iteration of the wireframe is done, design should start building it, and the wireframes and designs will be updated as the client gives us more feedback. So, that already sounds like a bit of a sham.
But what happens when the client hates our strategy? Or if we got the strategy completely wrong (yes that has happened before)? We start from square one to change it. So what does that mean? A beautiful design that your designers have slaved over and worked late on for the past few weeks has been thrown away. Not only was it thrown away, but when they do that all over again to create a new design based on the client approved wireframes, they will have to iterate through their design a few times anyway until the client is happy.
So if they have to change their work so much down the road anyway, why ask them to invest so much time and effort that early on? The better strategy is to have your separate UX and UI designers working together to create an awesome wireframe that everyone is happy with. Never create in a vacuum.
Project managers usually don't understand how the site is actually built
I've heard project managers over-promise things to clients all the time. I've accepted this as a normal thing, even though I don't agree with it. I worked with one project manager who thought that fully coding out 2 pages of the website would be a much smaller development effort than finishing the site. She said that we should show the homepage and an article page to the client, "...but that's all!"
If you know anything about CSS, you know that front-end development deals with lots of global changes. If you completely finish 2 pages of a website, you've probably finished at least 80% of the entire site. Clients typically aren't (and don't have to be) technically-inclined; That's why they're hiring us. But a good project manager should talk to the development team to see what can be finished to show off to a client.
The problem is that clients usually like to see lots of huge, beautiful changes overnight, and that's just not possible. You could build out one widget or block or feature at a time, and show that progress to the client, but they don't care if you got your h1, h2, and p tags fully styled and responsive. They want to see a complete page, and who can blame them?
What can I do about it?
This is why setting expectations is key. Web projects do not translate well to agile, so don't promise agile to your clients if you're building a site. Building an agile website would translate to launching the minimum viable product (MVP), and then slowly iterating on it over time. But people don't associate a fully functioning, complete website being delivered via waterfall methodology with being "agile," even though it is.
...And, since I'm a user experience designer, I always recommend doing iterative changes to your site based on results from user testing and reviewing your analytics over time. After all, it's pretty rare that you actually need to redesign a site from scratch!