I think saying that Agile development is broken because it is too developer-centric is BS. It is all about implementation. XP for example is meant to be custom

I think saying that Agile development is broken because it is too developer-centric is BS. It is all about implementation. XP for example is meant to be customer-centric. The point of it is to complete working functionality for the customer, and the customer should drive the development and what features are needed. Scrum is similar in that the customer can define a bunch of requirements and prioritize them and the team works on those priorities. The problem with any development being about development and not about the customer's needs has to do with management. I've seen and heard of many mismanaged Agile teams, but none where the problem was Agile. Agile might have been the excuse for lack of organization and direction, but good management that focuses on the customer needs as well as the developers' needs is what is needed- that can be done with Agile (e.g. XP, Scrum), Kanban, and other methods focused on quick incremental delivery usually much more easily than other methodologies (e.g. Waterfall). With regard to: "As Igal pointed out in this summer’s webinar, what is a unit that is tested in a unit test? Business logic." Strictly speaking, yes, but generally if you describe what a unit test is doing to a user, assuming it is really a unit test, most of the time they would not agree that it is business logic. Business logic is usually considered a lot more high-level. Human-language-based customer readable test definitions can potentially be created in Cucumber and similar BDD frameworks. There are also products that use UI-based behavior driven test definitions. But, in my experience, even these haven't really defined solely the business logic; there is always some level of implementation detail that creeps in. But, you do what you can. From what I've seen and heard, sometimes having the developer or analyst work with the customer to define tests is a good idea, and other times it is a wash or is a time sink. Do whatever it takes is basically the rule of thumb- i.e. there are no hard and fast rules to these things. Good luck to the guy that ditches Agile because it is "broken".