November 15, 2012

The Impacts of Iterative, Barely Sufficient Design

Like many people, I am a design and architecture enthusiast. Last week I had the pleasure of giving a keynote presentation at the Nordic Project Zone Conference in Copenhagen, Denmark. Most of the attendees were from Scandinavian countries (Denmark, Sweden, Norway, and Finland) and the conference was hosted at a Scandic Hotel. I also met a number of presenters who consult in these countries as well as the US, India and the remainder of Europe. Amongst them there was a common consensus that Scandinavian countries adopt agile practices well, and there is a close alignment between agile values and prevailing cultural values.

I discussed this alignment a little with Thursara Wijewardena who was presenting on “Making Agile Work on Virtual, Physically Dispersed and Diverse Teams”, she commented that many Scandinavian companies have flat hierarchies and a high regard for employee respect/empowerment which fits well with the values agile aim to instil.

With it being my first visit to a Scandinavian capital, I was also impressed by the minimalist design approach apparent at our venue. “IKEA inspired” is the wrong term, since this was all high-end furniture and fixtures, but to anyone not familiar with Scandinavian design it helps capture the idea of the sleek, stripped to its core form and purpose style. To me it seemed no surprise that a culture used to pairing everything back to its minimal form, would take to agile that also looks to “maximize the work not done” and use “just enough” and “barely sufficient” documents and constructs.

As an example, my hotel room looked bare upon entry, a low bed, a thin wooden chair and desk; clean, Spartan, efficient. The phone was a small, thin handset slotted in the wall; the bathroom shower had no stall and emptied onto the tiled sloped floor. Even the toilet seat was thin, narrow and just enough to cover the bowl. No waste basket, just a plastic bag clipped to the wall on a wire, the coffee cups had no handles.

It was all an impressive display of continuous simplification and removal of waste. You could imagine the designers asking “Why do we need a frame?”, “What can we remove still further?”, “How do we making it cleaner and simpler?” No wonder agile is a natural fit for the Scandinavians, simplification, refinements, and elimination of unnecessary structure seems to be baked into their DNA or at least introduced into many of their lives and homes at an early age.

After first revelling in this pursuit of leanness, after about 3 days at the hotel, sleeping on the thin low bed, sitting at the sleek wooden desk on the hard narrow chair, using the sharp toilet seat and wet bathroom floor (from having no shower cubical, not the toilet!) it all became a bit uncomfortable. I wanted a comfy chair, larger bed and things to keep stuff separated. Maybe living in North America that often appears the opposite of barely-sufficient design and more like unsustainable-opulence had made me soft, but I wanted some comfort too.

Then I wondered if anyone missed the comfort removed from project processes and what we build. Are lean approaches uncomfortable, do people miss the luxury of having system features they don’t really need? Are we forcing people to use sharp toilet seats by Asking Why Five Times, writing light documents and only developing features with high business value? I don’t sleep well when I travel so maybe I was just delusional, but I had never considered the downside of barely sufficient until experiencing it physically.

My thoughts were cut short when I moved to Budapest to teach a 2 day Agile Project Management course and stayed in a fancy 5 star hotel. Budapest features incredible architecture in Gothic, Renaissance, Baroque styles (amongst others) with amazing details and accoutrements with fractal qualities where even the decorative knobs have decorative knobs on them.

The buildings are beautiful to look at and must have taken ages to create, the antithesis of minimalist design and a beautiful legacy.

By comparison are we building in Lego instead (a Danish invention, of course), are our designs, blocky, bland and bare? Does the practice of iterative simplification to both process and product change what we create? Are the systems we build through short iterations of simple design and process more akin to Montreal’s Habitat 67 complex?

Has the art of grand designs and ornate detail been stripped away and is that good or bad? Is there a place for decoration and luxury in systems design or am I just still jet lagged? Let me know if you think I’m onto something or just on something.

Mike, I think you've encountered the failure mode for many projects. You were simply given the key to your room and left to discover on your own. Consequently, even though you admire the principles behind the design decisions, you reacted to the difference, rather than the result. I had a similar moment of discomfort the first time I encountered a Japanese toilet.

Admittedly, your Danish hosts don't think of you as a user, and don't think of the difference between their hospitality and what you're used to as "change." Consequently, they don't try to manage it. But change management can make the difference between simply changing the artifacts and changing how people work.

Dave, thanks for your comment, but I don’t quite follow your point. I was questioning how the repetitive simplification like we exercise on agile projects may impact the final product. I don’t think my Danish hotel failed, they did a first class job of providing a quality room, it needed no explanation of expectation management, everything was very easy to find and use. Please help me understand the failure mode you mention and how this relates to how we avoid Habitat 67 type systems. Thanks, Mike

This is a great observation and I enjoyed the article. It supports the role of instinct, intuition, and insight in the design process that our industrialist approach sometimes lacks. I have a foot in both worlds as an occasional writer of software and a lifelong visual artist...code is DEFINITELY similar to art and as coders we can learn from the historical working methods of artists, including how to deal with clients that demand more for less (as if this were a simple replicative manufacturing process) while being unable to visualize or describe the result they are looking for. IMNSHO, the factory metaphor is bogus and harmful to the end result. Art and code both require imagination, and force a high degree of innovative thought because each app and each work of art are solitary and unique creations. That's the point! We should never need to write the same app twice, just like a painter or sculptor wouldn't create the same work of art twice. Both have to interact with the human brain which requires a similar mental trick of imagining the unfamiliar perspectives of others who will encounter your work. Agile is great for some things but like Lean and a dozen other methods, it isn't a panacea. To quote Bjork, "there is more to life than this!"

Hi Mike,
I think that our designs are blocky, bland and bare due to the fact that these are more effective (cost-saving) for us to produce instead of the forms that are produced by the nature (or the Gothic architects, for example). In this sense, even simplification can't be understood without understanding the current level of the technology and probably the culture, thus affecting what we finally create. I don't think our stakeholders would not be satisfied, hovewer. Greetings from Budapest!