Ignore details early on
In this essay, the main point made is to try and not pay attention to details early on in the project. Focus on the main functionality before diving into details. In symfony, this is easily achieved by using a basic CRUD interface first (removing the functionality you don't need, or adding specific functionality you want). Sure, it's a basic functionality, but it works. Another very powerful option is using the admin generator, which already contains quite a few more bells and whistles out of the box. It takes very little time (as little as a few seconds for the most basic screens) to set it up, and as you really need to start paying attention to details, you'll be able to much easier and with more time left in your planning. You'll be able to experience the big picture before actually thinking about the details.
Race to running software
This essay really builds on top of the previously mentioned Ignore details early on. In it, 37signals tells us to get something up and running quickly. Not until it is running will the project be alive, and will people actually feel part of it. And here again, the CRUD generator and the admin generator will be able to help. With them, in literally only a few seconds, you can set up your basic functionality. People can click through it, do everything, and experience it first-hand. And then, you can work out those things missing, or remove those things that you don't want in there.
Hire less and hire later
Why hire lots of people and think big, when a few people can do an excellent job? Symfony really supports this vision by enabling one or to developers, maybe grouped together with a designer, to deliver a basic working version of an application in a short time. Especially by using plugins that offer specific functionality ready-made, a small team can get things up and running quickly.
Actions, not words
In this essay 37signals says to look at prospective new employees not just from an interview, but also focus on what work he/she has done in the open source community. Because symfony is an open source project, it is easy to see who contributed what. An excellent way to see if your potential new employee is indeed as good as he/she says he/she is.
Of course, symfony will have nothing to do with the basic HTML mockups Getting Real says to make first. But for a new application, applying the mockup you already made is easy. Using an empty module (or even an admin-generated or CRUD-generated module), you can easily apply your basic HTML look and feel to your project, simply be editing a single stylesheet (main.css) and a single layout file (layout.php). Thanks to the decorator pattern that symfony implements, this layout is immediately applied to all modules in your application, immediately giving you a good feeling about your application. It also removes the need for basic black-on-white proofs of concept and prototypes to show your customers. Little work has a big effect. And you can always worry about the details later.
Sure, many people split up the frontend from the backend and the symfony documentation also mentions this approach. But it's not a requirement, it's a way to do it. In this essay, 37signals speak about using a single interface both for frontend and backend actions, and just let the credentials of a user decide what a user can see. Symfony easily supports this, either completely custom-built or by a combination of admin-generated and custom-built code. Just as easy. And the symfony security model makes it easy to control the credentials of users and control what they can and can't see.
Less software means your software is easier to maintain, and has less bugs. This is one of the essences of symfony. Ensure that the lines of code a developer writes is kept to a minimum to save on cost (both development and maintainance) and also on complexity. The framework is already built and tested, so a developer does not need to focus on that. This keeps the actual code to write simple.
Open up your application by providing feeds and APIs, is the message of this essay. Well, feeds are only a few lines of code with the sfFeed2Plugin. OK, APIs are a bit more work, but due to the way symfony is set up, it is very easy to extend the basic behaviour of symfony to support for instance the setup of a SOAP or XML-RPC server. And if you just extend the basic symfony functionality, you only have to write that which isn't in symfony itself.
As you can see, symfony can fit perfectly into a project that is Getting Real. I am not saying however that symfony is the only framework that will fit into the Getting Real vision. A lot will. 37signals is, after all, the company behind Ruby on Rails. And many other frameworks will allow developers to minimize the code they have to write themselves and save time. Symfony will just do this as well, and in my humble opinion, in an excellent way. It supports agility in all its glory.
Ignore details early on