[nradov]

You're missing the point. The agile manifesto — and the various agile methodologies in common use today — don't mandate any particular practices around reuse of common core upstream components.

If you want to divide the teams up by component rather than by feature you can do that, but it's usually a bad idea. Most projects can achieve higher velocity and quality by having teams take on vertical slices of functionality through the full software stack; this minimizes misunderstandings and delays when handing off work between teams. 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.

[whoops1122]

Also, a real agile development cycle started from OO design, you need to design the code well enough that each object is relatively isolate from each other before we can talk about Agile.

nowadays, every organization talk about agile development cycle, but few business ppl really spend time to understand what it is, and how much it is involved.

like one of the poster here said, "Agile waterfall"

[nradov]

Well that is one approach and it sometimes works. But usually it fails or least forces excessive rework because much of what you thought you knew at the beginning of the project later turns out to be incorrect. Another more agile approach is to avoid big up front design. Treat design as an emergent property and keep the internal OO design clean through constant refactoring.

https://en.wikipedia.org/wiki/Big_Design_Up_Front#Arguments_...

[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.