Build Workflows, Then Build Use Cases
A task that the user needs to accomplish is solved by an effective workflow. A workflow is the way a user accomplishes that task by being guided or "led" via the user interface. These are the most important parts of an application and need to be nailed down first. They are also the first cement to dry when coding your application (meaning hard to change later without drastic consequences) so it's best to really think these out based on sales/client dialogues. More is better. If you have more than one idea to make an interface that allows a user to create a widget, go for it. If it's up to your information architect or interaction designer, let her/him know in no uncertain terms the clock is ticking.

Once you get a workflow down, "The user is shown a list of their savings plans. They can then interact with these savings plans," it's now time to build use cases around them. One is the user needing to upload a file, and another is the user needing to be able to filter visible data. Use cases are things the user needs to do. They usually collectively make up the task the user needs to accomplish. Sometimes, they can be task in and of themselves. The point here is to ensure you have a solid workflow first, then start working on satisfying your use cases.

Both should be put in builds and thrown at your client with abandon. It's okay to walk them through it in guided demos; this is brainstorming, not user testing. This is how your application will effectively work, so make sure your clients can do what they need to do and can see what they need to see.

Use Copious Amounts of Tagged Builds in Subversion (or Whatever Source Control You Use)
If you get a working build with specific functionality, make a tagged build in Subversion. If you are not using Subversion, mark the current build in your repository with a special label (in CVS), or some other verbose comment with an accepted convention so you can find that exact build of code later. No source control? ...just make a copy of the code.

This way, if you or the client wants to refer to an older example, you have the item on ice, and can thaw it in minutes, ready for any meeting.

Componetize Sections
This has less to do with OOP and more to do with MXML readability. Because FlexBuilder is nice in that the Design View will write all the code for you via dragging and dropping controls on your forms, it doesn't have that human touch. So, even if you don't format it by hand, you'll still end up with a ton of MXML tags spewed out over hundreds of lines if you build an entire application in one MXML file. The first pure MXML application I ever saw  was a pure MXML RSS Reader posted on Flexcoders. While I respected MXML's power, I couldn't read it.

If you have a big form, put it in a component. That way, 30 lines of MXML becomes "". Omg, 1 line of meaningful code... I can read that at lightning speed! Furthermore, if you hold Control (Command on Mac), you can then click on "UserForm" as a hyperlink, and open the file in question. Supa-fast!

Use Canvas First, Panel Later
While Panel gives you a nice container for the mini-components of your application, they merely serve as pretty-looking trappings for your lack of requirements insecurity. Use Canvas, set horizontal and vertical scroll policies to off, and let it be raw. You need to see the gaping holes in your UI, not hide them in pretty chrome.

Make Builds Easy to See
The point of builds is to get client feedback, and get it early with real software. If the client can't see the software iteration, they'll question "this whole 'Agile' thing." Don't send EXEs over e-mail, nor SWFs. Find a reliable FTP site, upload it, and run it. This is easiest if you don't have any local file dependencies, the SWF makes no data calls (locally or externally), and doesn't require any weird arse things to make it run ("Oh... well, let me reset my host file to be localhost, and then reploy the war file...". What? Dude, just upload the SWF with the accompanying HTML file. If you can't do that, you're not writing a Tracer Bullet, but instead a real application build that wasn't meant to be agile.

If the sales person/client can't see the SWF, neither will your users. If you don't want to deal with Flash Player install issues, don't do Flex development. Once you get it out of the way, you can always depend on your salesperson/client being able to see your latest build from there.

Use Fake Data from Real ValueObjects
A great way to point out immediate problems, and make your application feels more real, is to throw fake data at it in the form of ValueObjects populated with data. Obviously, you may be way ahead of the server team (yours or the client), so it helps to have factory methods: functions that can generate a bunch of fake data for you quickly. You can then throw this at the GUI time and time again to test something. Pain in the neck to write, but you'll use them a tons afterwards.

Furthermore, this ties in really well with the "make builds easy to see." Instead of praying that your database call works while the client is viewing your SWF, or if the back-end guys will have their code done by the meeting, you instead don't have to worry about it; it's embedded in the SWF and will work even if the Internet connection suddenly dies (after they've downloaded the SWF).

For Cairngorm, a technique I learned from Darron Schall was using "Mock Commands". You make two Command classes: one for real data that may use a Delegate to make a call to the server, and one that just gets fake data from a Factory class and has a timer to simulate a delay. That way, you just change one line of code in your Controller class to switch to fake-data mode.

Put Event Handlers in Script Tag, Not in MXML
The thing that'll change the most as you hop around files modifying GUI stuff is your MXML. Since most MXML is for showing GUI controls, it'll be volatile from the get-go. Putting code there is just asking for it to get in the way, and maybe even get waxed. So, instead, have your Buttons for example call a function in your Script tag for their click handler instead of do things directly in the MXML. That way, you can even delete the MXML, replace it, and then easily wire it up again.

Find a Friend in Sales (or a Stakeholder at Your Client)
Sales can go either way. They can be a developer's worst enemy, or you're biggest fan base. I prefer the latter. I've been in too many situations where sales sold something that was impossible and I had to make the impossible possible. AKA, "Flash Developers at Design Agencies."

The first thing to do is find out who in sales (assuming just one individual) is interacting with the client, and basically catering the project to their needs. Start up a dialogue with this individual, assuming your project manager doesn't mind, and get to know the client. You may wish you hadn't, but do it anyway. Learn the needs that sales is trying to satisfy by using your code as a conduit. When they start asking for specific functionalities, you'll know why, and be more informed in suggesting ideas, changes, or options.

The ideas are cool because sales usually perceives engineering being "fun governors"; depending on the organization. The last thing they expect is more things for the developer to do coming from the developer. The changes are good because as an engineer, you know how hard something will be to make, how it may work differently in practice, or know the ramifications of a design path, whereas sales might not. Rather than saying no, you can make an informed suggestion about how to get the result sales is looking for. This may seem like something you can do in a meeting, but trust me, it's tons easier when you already have an established rapport with the individual, and almost give the suggestion in passing, almost like you and the sales guy have already got it all planned out.

Finally, options are key here. Being successful at software is the middle ground between doing everything sales wants, and coding just enough to get it solid and working. Enough flair to make the sale, enough OOP to ensure it doesn't blow up. Combined, you win. A lot of times, you as a developer may not know what that balance is. The easiest way I've found is to put the ball back in sales or management's court. If they ask for five things, you spec them out, give time estimations with risk assessments, and any additional optional ways to implement certain features in increments. Giving sales options is way better than ultimatums. It's important that your time estimations for your articulated options with possible incremental milestones are valid. You need to be sincere, honest, and thorough. If it was easy, they wouldn't call it "work".

Naturally becoming friends with the client is dangerous. It's all fun and games until business gets involved. That doesn't mean you still can't build up a rapport to better communicate with the client, and thus understand where they are coming from. I've seen a lot of managers in my time offer to shield me from meetings. If the meeting is with the client, I highly recommend you lower shields, and go. Even if you don't converse in a dialogue, you can still listen.