Can Design be entirely “Agile”?
Constant sprint-based design leads to shiteration. Design that's rushed with no holistic vision.
The following post has been left in the drafts for a very long time (almost 10 months). I am going to publish it as is, with an addendum (see below).
A few time ago Stuart Eccles, CEO of Made by Many, posted a very interesting piece about how they integrate the design process into an agile development workflow (Scrum specifically). Some clear (and rare) words on how is actually complex making the two process live together, and share the same rhythms. But also implicitly pointing out how exists an effective risk of trivialising the design process in favour of the development process, following blindly the same “rules”, adopting the same set of “mental tool” to solve different problems, focusing only on the very short-term view of the project. Let me just quote an excerpt (but you should read the whole post, it’s worth it):
“Design is a holistic endeavour and it means you need to know how your whole product fits together, especially for the first delivery (your future platform for experimentation). Not in detail, but in concept, meaning and experience. Too often, Agile will churn forwards, continually delivering but with no idea of what makes a holistic MVP.”
Not to mention the comment posted by Jon Gold:
I think the general trend is getting away from religious agile for designers. Constant sprint-based design leads to shiteration. Design that’s rushed with no holistic vision. The flipside is waterfall ‘we’ll speak to developers when It’s Finished™’ design that never ships.
Don’t get me wrong, I am not going to say here that agile design doesn’t work. On the contrary: the agile and lean movements are the the best things ever happened to the software/web-development “industry” (like Stuart says, “we’re making a products – not code, designs and strategies”) and currently not being able to work in an agile environment as I would like to, makes me even more convinced that “agile” is the way (in design, in development, and often in life too).
But I still clearly remember the passionate discussions I had with friends and colleagues – especially with Luca Mascaro in one of the many barcamp held at Sketchin (thank you, Luca!) – when people were beginning to talk about UX and lean/agile design. The reason of the discussion was simple, and still current as you can see: if the “agile” approach always convinced me as a healthy software development process (rational, sustainable, efficient, connate to how we elaborate the code behind a product), when applied to the design context it seemed to me a more forced, less obvious and “natural” approach. Especially if adopted uncritically, in a blind manner, just to follow a trend, a buzzword, or what other people say (not so different from what today we call “cargo cult” behaviour).
For me the problem is aways the same: absolutism and simplicism in the understanding of a problem and the definition of its possible solutions.
Just a few days ago I was attending IxDA London (Interaction Design London) when this slide made me think about this post, and how it was true:
In his presentation, Mischa Weiss-Lijn explained how their agile workstream is always preceded by a wide study to define the holistic view of the product, in order to keep consistency, obviously, but especially to avoid a lot of problems and incurring costs downstream during the project.