Tag Archives: Getting Real

Design sprints, fake apps, and figuring out what you need

I’m so sorry I can’t join you in class tonight, and that it’s take me a while to get over here to post this for you. I’ve been away from my computer more in the past week than any time I can remember since I had a newborn almost 8 years ago. I’m usually more readily available. When we were together last week, we tried to watch the brief video of the Gimlet Media design sprint they did with Google Ventures. I’m putting it here for discussion. Gimlet is the company whose inception and launch have been chronicled in the Start Up podcast, which is a worthwhile listen if you have the time. If you don’t have the time for the whole series, I would recommend listening to Episode 13, “Fake It Til You Make It”. The whole series is an interesting look at how you go from having a big but amorphous idea and shaping that into reality. Of course in their case, pitches and investors are involved, but many of the questions they struggle with–what kind of a company are we? do we do tech or content or both? do I know enough to do this? how do I fix my mistakes?–are about far more than profits.

Have fun further defining your ideas and getting real, as it were. I can’t wait to see what’s around the corner for this class.

“Build, Launch, and Tweak, then Rinse and Repeat”: A Response to 37 Signals’ Getting Real and the rules of Agile Development

37 Signals’ Getting Real clarifies and details the praxis of Agile Development. After reading the wiki on the Agile Manifesto and its basic rules, many of which are captured in catchy phrases or abbreviations such as JBGE (Just Barely Good Enough) or Ruby on Rails’ CoC (Convention over Configuration) and DRY (Don’t Repeat Yourself), this book more carefully lays out how to put into practice this philosophy of quick, lean, and flexible software development. I see how this is a world of difference if you compare it to the days of sluggish development of giants such as Microsoft (CUNYfirst and Blackboard tell us that these days aren’t over yet, unfortunately), but right now, in a time of endless lean tech startups, where small groups of freelancers let their creativity flow in co-work spaces like WeWork, Getting Real does not seem so new anymore. Even so, it is enlightening to read a how-to book like this, maybe because I have not come close to anything so driven by practical concerns and real-life constraints in a long, long time, but also because it is just really helpful to think about your approach and attitude to your project. It is easy to get lost in practical questions about the product itself and miss the importance of having a “vision” and determining the way in which to make and deliver your product.


So it is all about having a small, cross-functional but highly skilled team, about releasing early and often, about minimizing the work (Rule No. 10: Simplicity—the art of maximizing the amount of work not done—is essential), and about flexibility, multiple iterations, and costumer service. It is about reducing features but optimizing the essentials. Realizing that constraints can actually force creativity and that in the triangle of time-budget-scope it is the scope that should be the flexible factor can lower the threshold for a lot of aspiring developers.


What I want to highlight is the use of and emphasis on terms such as “passion,” “emergence,” and “liberation,” and in how in the “easy in, easy out” chapter they argue that you should let customers end their subscription with just one click and allow them to retrieve all their data. This is to create goodwill and trust with your costumer base. Obviously, it gives some relief to read this after years of signing scary binding contracts from large, monstrous corporations just to be able to watch TV or rent an apartment (though these evil empires still rule the world). Again, I associate this more compassionate attitude with the kind of hip start-up founded by passionate twenty-somethings, part of our current “maker-subculture” who, 37 Signals says, should strive for honesty in communication, openness and transparency. If you read it in this way, Agile Development is just as much a philosophy on life and mind as a manual for (tech) startups. And yes, there’s a TED talk on Agile Programming for your Family.


One thing I have to mention as a literature and writing instructor is the value Agile Development places on writing. They cite both Strunk and White’s Elements of Style (“omit needless words”) and Hemingway and Carver. You could say their philosophy is similar to the “show, don’t tell” mantra of fiction writing, but, unlike so many aspiring writers in this city and elsewhere, you have to let go of the anxiety to publish. Your work is never going to be ready, nor perfect. Now that’s something I should really take to heart, and with me many other PhD perfectionists.