Most of the people I interact with are unequivocally excited about the opportunity to try agile for the first time. Not.
Most people have doubts. And one of the top questions I often get is "can I seriously use agile for a very large project with multiple work streams, and with cross-impacts from other groups who aren't agile at all?" Yes! Yes, you can. In fact, agilists and the agile approach has a particularly strong set of tools for helping you manage cross-team interactions. These tools not only help you scale your "pure agile" project management approach, but also can help strengthen best practices in your "waterfall" PM approach, if you're working in a hybrid environment. So let's talk about that.
First, a few myths that you might have heard, but I'm sure you agree aren't true.
But let's say I concede the point, and agree that every single practical thing that you might do to make agile work at scale makes it not-agile. Let's look at what you can do within a multi-stream project which has agile elements (that would not be possible in a classic waterfall implementation).
You can plan integration strategy with all cross-impact partners proactively. Effective agile teams will inventory their data interfaces during release planning, and for each interface, determine:
You can still do meaningful program-level roll-ups showing progress across the disparate work streams, so long as you agree to use business-friendly metrics like "actual code complete" rather than "points burnt up." And in fact, since the work streams which progress in an agile manner will get to the coding sooner, the program-level dashboard becomes a showcase for the delights of agile over waterfall.
Please don't let the agile-for-tiny-teams-only people get you down. Corporate moguls running ginormous agile programs world-wide, unite! You have nothing to lose but, hm, okay, well, it's actually quite good to be a ginormous corporation. And agile scaling just adds to the benefits.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.