[trhway]

>But either way it's essential to have stable APIs and clear design contracts before building any dependencies on top of common core upstream components. Again this is all orthogonal to agile versus waterfall.

in the ideal world you'd have that stable API, contracts, and delivered components satisfying them from day 0. In the real world you have back and forth iterations which are just fine under waterfall and which are heavily impeded to the point of impossibility by the sprint cycling in agile. On practice in waterfall the upstream and downstream components are developed almost in parallel, and they have active feedback cycle between them. On practice in agile you can't really start consuming a component until it reaches the stage of deep maturity (and reaching such stage under waterfall is significantly faster due to almost immediate feedback cycle from downstream components as mentioned above) and that makes agile process into super-slow component dependency serialized process, a "component-wise waterfall".

[nradov]

There is nothing in agile which prevents upstream / downstream teams from working in parallel and iterating on components. Nor does agile require that components reach the stage of deep maturity before they are consumed; in reality it's completely the opposite. I can't fathom where these misunderstandings are coming from.

Again, if your project is organized in component teams then you're likely to have those problems regardless of methodology. The optimal solution in most cases is to reorganize around feature teams, plus have a small cross-team group of technical experts for each major component who can provide stewardship and review major changes.

[trhway]

>There is nothing in agile which prevents upstream / downstream teams from working in parallel and iterating on components.

a task (for example acting on a feedback, fixing a bug, etc.) can't be taken in mid-sprint because it would affect the sprint's deliveries and thus a replanning mid-sprint would be needed which thus makes all this ritualistic sprint belly-dancing pointless. So, the downstream has to wait until next sprint for any actions by the upstream wrt. the feedback while that downstream is still responsible for meeting its current sprint deliveries which it has hard time to satisfy given the unsatisfactory delivery state from the upstream. After being burnt this way several times the downstream team finally learns from experience and refuses (or fights pretty heavy against management pressure) to take on in a given sprint any tasks which depend on components which haven't reached deep maturity by the sprint's start or any maturity at all and hell no to any promises that that upstream is coming down mid that sprint (any deliveries from upstream, even if scheduled for mid-sprint actually almost always come at the end of the sprint). And if it is the first version or a major change you can't even seriously plan on working with it next sprint - see feedback sprint cycle above - the best you can hope is the end of the sprint next after the next... That makes even idea of iterative parallel process pretty much impossible, a bad joke slow as toothache.

>Again, if your project is organized in component teams then you're likely to have those problems regardless of methodology.

Agile worsens these issues couple orders of magnitude compare to traditional relaxed [i.e. we aren't coding F-35] waterfall.

[nradov]

No that's not the correct way to do agile project management. As I have repeatedly pointed out, you can prevent most upstream / downstream iteration delays by organizing the project around feature teams, not component teams. But if you persist in using component teams for some reason then obviously both the producer and consumer teams must build in sufficient time into their story point estimates for iterating on the interface. As for defects that come up mid-sprint, either every team should keep a percentage of their capacity in reserve, or on larger projects you should dedicate a full Kanban team to maintenance.

Sure there are some managers out there who implement agile incorrectly by failing to follow best practices. But all of the problems you described are self-inflicted and easily avoided on agile projects with competent leadership.