The discussion was really frustrating. About three minutes into the description of her project (including the people and politics involved), I realized that an Agile approach to their project was fraught with peril. It reminded me of something that you won't hear me say very much: there are times when it is a BAD idea to use Agile, or at least, unnecessary to do so if there's any organizational inertia.
Let's cover a couple of non-negative situations where Agile isn't a necessity to successful project delivery.
Short Projects
Projects that would typically encompass only one or two Agile iterations are probably easily handled via any methodology. As such, don't feel like you have to jump through all the ceremonial and artifact-centric hoops that are required for most Agile approaches. To be clear, you CAN run these projects in an Agile manner, but it's not necessary. Note that software package/solution spikes fall into this category for me (since they take anywhere from a day to a couple of weeks at most).
Simple Projects
A short project isn't necessarily simple, and a long project isn't necessarily complex. I'm defining "simple" projects as projects that are solving problems that have already been solved in well-known ways, or projects whose outcomes aren't very important. R&D projects might fall into this category. For me, secondary ETL projects are commonly in this category: a client needs to add a new data feed to an extant data stream, and the input mechanism is going to be the same as the original one. This is probably pretty simple, and doesn't mandate an Agile approach.
Fixed Triple Constraints Projects
For projects where each side of the triple constraint triangle are truly fixed, Agile approaches aren't necessary. Contracts with governmental agencies might be this way, for example. Projects where the budget is fixed with a hard deadline and a specific scope can succeed with a Waterfall approach. I would still argue that the team *could* improve delivery iteratively via introspection and subsequent changes, but the project could still be successfully delivered without this.
Alright, now let's get into the less happy reasons to avoid Agile. Note that none of the following reasons are indictments -- Agile practitioners should also be pragmatists, and that's where these observations come from.
Teams Lacking An Agile Spirit
Not everyone can embrace change. Not everyone is confident enough to be kindly yet firmly honest with their teammates. Not everyone cares enough to do more than "their share." Not everyone wants to take on the responsibility of self-direction and organization. That's all OK -- Agile really isn't for everyone. If you have team members that are REALLY against Agile practices, it might not be worth trying. Or, you could see if there is another team on which those folks would fit better (which would be my advise). However, sometimes there aren't *any* teams that want to do Agile, because...
Organizations Lacking An Agile Spirit
Some organizations hear about Agile, send people to training, and then try to become Agile by using all of the Agile tools without understanding that Agile is a way of thinking about solving problems and interacting with people. Most of the organizations I've gone into trying to do Agile transformations (moving from traditional to Agile approaches) fall into this unfortunate category. They try to fit their current roles into Agile role titles. They try to create a Gantt chart on an Agile information radiator. They don't understand that Agile is about doing something fundamentally different, and instead fall into the trap of doing something operationally familiar with new tools.
Organizations Where Agile Has No C-Level Support
If you want to make a transformation from traditional to Agile project approaches, you *have to* have high-level executive support. The change is painful for most organizations, and there is typically incredible inertia in every aspect. Having someone high up that can mandate the changes until they are done makes this more possible. The fundamental problem with Agile approaches when no muckety muck is directing the change is that too many people/things in the organization can accidentally or intentionally sabotage the efforts.Back to the discussion with my friend...
We wound up going through the twelve principles described in the Agile Manifesto. The groups involved with her project could legitimately enact a couple of them, had a chance of adhering to a couple more, but would absolutely fail to adhere to at least half of them. If you an go through that list and be honest about your ability to live them out, you should have a pretty good idea of whether your project is a good candidate for an Agile approach. At the very least, you'll have lots of good talking points about places/things you'll need to change in order to do Agile projects in the future.
In my friend's case, I suspect that the client mainly wanted to "do Agile" with them because they wanted visibility into why it took so long and cost so much to do what I would classify as "simple" projects. I advised my friend to talk to the client and ask if they simply wanted to be on some daily standups to see where the churn happens. Something as simple as that might satisfy the client without having to do a full-blown Agile implementation. I haven't heard back yet, but suspect that this is the track they will follow.
So the next time someone unexpectedly wants to do an Agile project with you, take the time to make sure it's a good candidate. Look for the pitfalls of team and organizational challenges. If the project clears the Agile principles pretty well, go for it. If not, it's worth more discussion before launching into an Agile approach that might've been doomed from the start...