Reading About Talking About “Getting Real”

The Adobe Design Center, an online magazine exploring all manner of digital creativity, has just published an interview that I conducted with 37signals front man Jason Fried. At first glance, the presentation of the article looks misleadingly as if it focuses on me, when in fact it’s actually a serious conversation about Fried, 37signals and their “Getting Real” approach to Web application development. I tried to pose a string of serious questions as to the practicality of “Getting Real,” both to satisfy my own curiosity and also to try to get Jason to respond to some of the contradictory experience and feedback that I’ve heard about the approach. I think I did a pretty decent job that sheds a little bit more light on this emerging developmental philosophy, but you be the judge. You can read the interview here.

  1. You had the following question that Jason could not answer “So the question is: Is this the only way to integrate your methodology into a big organization? Can a big organization ever fully integrate it except in pirate exceptions?”

    The answer is yes with a twist. We have a core cross-disciplinary team that makes the decisions. We supplement that team with specialists to execute and provide feedback based on their experience. This keeps our core team focused on serving the customer instead of programming HTML or keeping up with the latest software features. Do you really need to have all your team members keep up with database throttling techniques in a multi-tiered environment?

    We deal with established clients who have infrastructure, processes, and staff that can’t be negotiated. Each client has a different make up so one day we’ll be doing a Microsoft-centric implementation, the next one on LAMP, and the third using a legacy Java system. You have to be a specialist to provide the right recommendations within their budget and timeframe.

    Within our core team we have tried various ways to work. The one approached that we never changed is direct contact with decision makers, brutal honesty and humility. Everything else is based on experimentation and experience.

    Each client needs different types of management and process. We provide a service to mid to large size corporations. This may be much different for someone who provides a product to a niche market.

    Sidenote: I keep reminding people… Software 2.0 will come out but it will always be Problem 1.0

  2. I love Marketing… “Getting Real” is just a variant of Agile , Agile is a software development methodology and I’d say it works for 37 signals because they produce small, simple applications.

    Agile can work if you’re building something small and simple and you’re your only client (37 signals – and 2.0 startup in beta). It can also work if you’re just iterating over an existing framework (Yahoo!, Dell, NYT), where one of the main variables (design/UI patterns) are relatively static. Where it falls down is large complex builds that require intensive technology and design.

    I think of it this way.. Yes if you’re just building a shed in the back yard it’s pretty silly to go make blueprints for it, but how would you feel if someone tried that while building your house, or your office building?

  3. “Where it falls down is large complex builds that require intensive technology and design.”

    The failure there is complexity and intensive technology, not small agile teams. Ask yourself why what you’re building needs to be so complex and do technologically intensive.

  4. I thought the interview was very enlightening. It certainly has applicability beyond software program development. For example, I see the future of brands as one of “agile brands” where brands are programs to create value, fine-tuned to customer needs. Brand teams, which are now bureaucracies, could be energized by the “Real” approach.

Thank you! Your remarks have been sent to Khoi.