We built systems that literally had people say, "Oh, thank God!" when demoed. I haven't seen any other development methodology that matches it. You really have to understand a problem at a deep level in order to reason well about it.
So instead of a quick conversation 30 minutes with helpful whiteboard doodles, I have to compose my questions and decision-tree into an e-mail and wait at least for a day or two for a reply that may or may not be useful.
They would email each other even though they were in the same office more to document everything and CYA than for communications.
On the dev side, I banned internal email for discussions. I told them that they must talk to people first if they are in the office and then send emails of documents, screen shots or whatever.
I also took it on as personal mission to never say "no" to any request and always talk to the person who was making the request - in person - see if we could come up with an acceptable compromise and tell them how it would affect their deliverable.
Later that remote person left the company, and the position was left unfilled for a year and some projects got mothballed.
We would have spent at least 10 times longer trying to get these insights otherwise, if there was even a possibility that we would arrive to the same conclusion.
It takes a little time to get over the fact that you are no longer building this product for yourself (unless you are building dev tools), but seeing customers use your product happily and telling you how much they value it is well worth the investment.
We started with a simple problem that plagues HR departments in every conceivable industry with unions, finding substitute personnel and erroneously assumed that it was a simple fix. Over the past year and a half we have accumulated a great deal of knowledge after interacting with as many people as possible and have finally released a version that meets our original criteria (and much more). It was obviously not a simple fix.
If I have one thing to tell anyone who is looking for business ideas to try out their new programming skills on, I strongly suggest taking the time to learn as much as possible about the people to whom you want to provide a solution, then recruiting one of them to help you build it, lest you become another project that solves a non-issue beautifully.