It's OK to feel conflicted.

It's very often best to just admit that you're not 100% sure you want what you think you want. If you have a voice inside saying "I think I want that glowy grabme, but I wish I also had a way to change my mind once I put my hands on it" such a thought is not only normal, but healthy. The nature of the Agile process allows one to push big commitments as far down the pipe as possible to allow all parties involved to have some time to chew on whether or not they really want to do a specific thing. In building a jigsaw puzzle, when one picks up a given puzzle piece, rotates it in hand, and chews on if he/she really wants to use it, typically one has the benefit of surveying how all of the other pieces have come together to date and thus the current shape of things effects the decision at hand more than any other factor might. It is good to have all of the information possible to make an informed decision and it is good to a make decisions that will allow you to make such informed decisions. Running a project with an Agile process will allow one to make informed decisions a lot more so than a Waterfall process.

We are just now starting an Agile process. We are fighting our way through some of the pain points, such as not baking enough story points. We are doing better. We are in a second leg of our project.

In the first leg: A liaison (middleman) between our team and the product owners had written a huge functional spec around what he felt the users wanted and we were trying to jam hunks of the Word document into stories and we were... pretending to have an Agile process around the pseudostories.

There is not an Agile process without stakeholder feedback however. We were chipping away at the functional spec in a Waterfall manner.

Eventually the middleman's management style caught up to him and he felt the need to quit. In his absence we started doing things the right way. We are now interfacing directly with the customers that we had been "protected from."

That said, plenty of time has been wasted in going down tangents:

• We were to build an autonaming feature for a particular object. We spent time planning for it and debating it. It turns out that the stakeholders didn't want it at all. It was an imposition by the middleman.
• We abstracted the name for another object out to a separate database table in the name of... well, I don't understand why we did it. I think it had to do with making sure that no two objects have an identical name. It doesn't really make sense. The middleman wanted it. It was in the functional spec.

I've now seen firsthand, on the same project, the difference between Waterfall and Agile. I wanted to share my tale. The lesson: Don't try to have all of the answers upfront.

It's OK to feel conflicted.