Tag Archives: agile development

“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.