> We can also lay some blame at Agile's feet. I've seen UX and UI designers genuinely struggle to fit their work into the sprint treadmill. 2 weeks' notice is not enough time to do any sort of serious usability design study.

Windows 95 significantly overhauled the desktop GUI metaphor, in a way that is still the skeletal structure of desktops today.

Its U/I design since Windows 3.11 came about because of agile, not in spite of it. https://socket3.wordpress.com/2018/02/03/designing-windows-9...

> We recognized that we needed much more opportunity to create a design, try it out with users (perhaps comparing it to other designs), make changes, and gather more user feedback. Our desire to abandon the waterfall model and opt for iterative design fortunately followed similar efforts in other areas of the company, so we had concrete examples of its benefits and feasibility.

You're right that you can't go start to finish on a design in a single 2-week sprint. But that's why you have a repeating series of sprints, you're not supposed to go from start to finish in a single sprint.

The Windows 95 team always had a shippable OS to demo internally to devs, QA, beta testers and users invited by the UX designers for usability testing. Just because you demo something to the product owner does not require that you then release the result immediately to end users. Decouple development from deployment and from release and you'll find agile methods can work just fine.

I think the trick here is to not co-mingle the development of UI toolkits and the software built with them. Agile works fine if the UI framework itself is its own project with its own lifecycle, suitably long sprints, etc.

This goes against the pattern that's most often observed in the past decade of every product hand-rolling its UI from scratch, though.

When the end of a sprint is a hard cutoff point for tasks, agile is done wrong. Just carry unfinished work over - it won't go away, anyway.