Write E-mails to Stakeholders (Sales/Client) Who Ask a Question That Can Be Answered
When you are in the process of figuring things out, it's really easy to give that laid back, relaxed feeling others in conversation. The no-pretense, "What do you think?". Don't ask open ended, non-focused questions like that to stake-holders. Be direct, and know the type of feedback you want before hand. If you do, 1 of 2 things will happen, both of which are good. Either the salesperson/client will answer your question in written form so you can refer to it later and thus continue working on your GUI, or they'll have no clue, in which case you can propose some ideas and look straight pimpin' (really smart and capable).

Recognize an Opportunity and Take It
If your sales/client has no clue what any form of Agile is, or what a "build" is... find a way to educate them. That is, find an appropriate time and place to introduce the concepts. Don't start ranting about Agile Development on a sales call for example. Instead, if you have a question about how a certain section works on a design comp the client sent you, use that as an opportunity to send them 2 builds, and choose the one they like, or perhaps choose a different one. If they respond positively (or not negatively), boom, you win. You just set the expectation you can send them working prototypes to play with. Suddenly they'll be hip to the notion you're sending them working software to play with that is representative of what they'll actually be using... and that's a pretty accurate assumption on their part. Their shaping of it also ensures you're never wrong because you're basically doing what they tell you to do. Obviously, famous last words for a programmer. Either way, if your the IA/ID or not, you can also use this opportunity to suggest ideas, again giving yourself an opportunity at least appear intelligent.

If there is a client phone call/meeting, and you have the opportunity to attend, do so. If it is appropriate, start a dialogue to challenge your assumptions about their comments to the recent builds you sent them. Engage with them (and/or sales) in the process.

Use a Phone, Not E-mail or IM
If you're unsure about something, and you have access to sales, go talk to them in person. Make sure you brushed & flossed first, obviously. If they are unavailable, send them an email. If they are remote, call them, and then only email if they aren't around and don't return phone calls. In person dialogue is ideal, whereas phone voice dialogue is 2nd best. Email and IM are not the best form of communication, and communication is the most important thing in a software project. Use the best kind you can to ensure success.

Caveats and Gotchas
There are some caveats and gotchas. The more time your team is writing tracer bullets, the less time they are moving forward with traditional visible results. The Agile crew would argue that it is better to spend four hours on two ideas, allowing the client to pick one they like as opposed to spending one week on requirements and then two weeks on development for an implementation the client won't like, which then ends up being another two weeks to code to the new idea. Even two weeks of bouncing ideas with near production code is better than two weeks of "coding off a spec"... well, unless you're doing government work. It's hard for some to see the value in writing code that has fake data, and an ever changing interface, seeing the same things in different ways without seeing in their eyes tangible progress on milestones. My retort is they can't prove their milestones are accurate without the client having some form of involvement in confirming those milestones were met without allowing the client to play with a build that shows that milestone in action.

Regardless, it's hard to argue with a Subversion log that says "everything under the View's folder has changed a lot the last week, but everything in the Cairngorm business, command, and events folder has not... what exactly HAVE you accomplished this week? Can you name one requested feature you've completed?". Valid question, and one that management & sales need to manage; IA/ID & developers can help, but ultimately they aren't accountable for resource management. Look at it this way: You'll either be re-coding this at beginning more quickly with less stress using a series of tracer bullets as opposed to slowly at the end with less malleable code under more stress. Use that fact to empower sales. Take the initiative.

If you don't have leadership approval, it won't work. If your manager looks at you funny when you send a "half finished application" the client, you're already in deep trouble.

If the client doesn't care, you'll really need to leverage your sales rapport. You'll need to educate the client how software works, and that is extremely hard... but fun. If you don't, they'll just expect it to be "done and finished by X date". That's not how things work in the real world and they need to realize no matter how much money they spend, they can't change that. It's in their best interest to get a good feeling with the software early because it's easier to change early, harder to change later. If you get those feelings early on, most changes later won't be so drastic as completely changing workflows.

Regarding MXML, I'm a big fan of writing my components in all ActionScript. That way, I can re-use them since I have lower level control and can make them really flexible. Again, Flex Builder won't render these unless you convert them to a SWC (via a Flex Library project for example), so save the uber-OOP for later. If you stick with pure MXML, the tool will work well, and you won't be fighting it to adopt your best practices. If you have a lot of members on your team, this is also something you can throw at other developers to handle, even junior ones. They can cut their teeth on making a reusable component while you continually define the app via multiple iterations.

A couple notes on branches and prototypes. First, I'm not a big fan of using branches for one Flex Dev to make some design iterations while the rest of the team "moves forward". The Flex Dev(s) doing the design iterations should be in the real code. If the rest of the team has qualms with this, you'll need to setup an easier way for them to test, whether by writing formal/informal unit testing for them on GUI & non-GUI code. For example, one of the benefits of Cairngorm is that it allows multiple developers to work in tandem. One strategy is to have multiple developers handling all Events, Commands, Factory, ValueObject, and Business Delegate code. This leave the Views in the hands of whatever developer(s) handling building the tracer bullets to show sales/the client. The rest of the team can either use the latest build in source control to throw data at and see what happens, and just comment out the actual Cairngorm Event dispatching when they check the code in, but I've found it's easier to just make informal test cases; MXML applications that test your whole Cairngorm use case setup. A la, you build a simple View with a GUI control data bound to the Model, dispatch an event, and see if it works.

Regarding prototypes, for larger projects I think these are more the than justifiable. Throw away code is quicker to write than tracer bullets, and it's always good to play with some code ideas before committing more rigorous practices to it before you know the idea will actually fly (strong-typing, encapsulation, etc.). There comes a point though where you should start leveraging the code you are writing in a good base, and really put the code to the test in early builds to see if she holds up.

Finally, being intimately familiar with Flex Builder helps. I think I'm pretty adept at it, and I'd say that significantly contributes to my ability to quickly modify code without making it spaghetti. My experiences in Director and Flash have contributed to my ability to fake a lot of interactions for the sake of communicating a point. Finally, using OOP, encapsulation, and strongly-typed code to get the tool to help you find errors are all ways to write flexible code. While the temptation is to not even use strong-typing, and use a procedural approach, you'll spend too much time trying different ideas because you can't share code easily. Remember, it's ok to do this stuff on paper or your favorite UML tool first. I just use paper, personally and plaster comps on walls in front of my desk. Now, that experience doesn't just happen over night. Regardless, I was responding to bi-weekly changes on software projects at my first job of which I didn't know OOP or how to write classes, nor did I know what design patterns were. I didn't even know how to return a value from a function (I just modified global values instead). Yet, I found a way, so you can too.