The article seems quite confusing on a number of fronts. Architects of buildings don't actually use waterfall for a start - they continually adapt and improvis

The article seems quite confusing on a number of fronts. Architects of buildings don't actually use waterfall for a start - they continually adapt and improvise (in response to things like variable materials supply, soil conditions, weather, unexpected archeological finds etc.) The UCD practitioner as outlined here is a type of, or proxy for, a product manager, which would fit in very well with any agile process. The insight about unionisation is interesting, but the fact that agile turns out to share some subset of traits with unions doesn't really say much about agile - as nobody designed agile as a form of unionisation by the backdoor. It could be entirely coincidental and irrelevant or it might reveal something about aspects of unions being an emergent property of labour. (We certainly see unions appear across many industries in most nations.) The point about lean and agile seems misconceived to me. Agile is essentially about preserving your options for change by reducing batch sizes and thereby improving flow of business value delivered. Scrum is just one form of agile, which reduces the epic cycles of waterfall from 6+ months to 1-4 weeks. More lean-focussed approaches like Kanban just take that further to a granularity of individual features. In fact you will have much more measuring and chartism under Scrum. A major lean argument is that optimal program velocity is achieved by continuous flow, even where it means that some individual items move at a slower pace - much like traffic control. This is precisely not an inhumane 'whip the horses harder' PM approach. It is also easier to visualise without needing to constantly measure an refine - bottlenecks should be self-evident from a kanban board for example. Design thinking isn't something I'd say was at odds with agile at all, but in my experience is considered part of the wider movement away from 'throw over the wall' approaches (along with devops and lean UX). It's fundamental to lean startup for example. And Taylorism is misapplied by many people to software development. In one way you can comfortably separate conception from execution with software. You could call them design and production line. The commonly made mistake is to think of coding as a production line activity rather than one of design. In fact the process of software development is one of automation generally - just as a high level of standardisation allows you to have robots building cars, a high level of software design allows you to automate execution. Where you have shoddy design, you end up with an inefficient process with humans doing production line work - that's a failure of industrialisation and Taylorism, not an example of it. This is in fact why software projects that attempt to separate design from technical implementation always run into huge problems. The technical implementation isn't a separate thing but is the actual design (and UCD here is closer to discovering the goals than defining implementation).