Agile is Reducing the Value of Your Design Team

Dave Malouf
Amplify Design
Published in
7 min readJan 12, 2017

I have been interviewing a lot of folks around the world about their current design operations (whether it is intentionally so or not, it exists). What I have heard is that the vast majority of design organizations are working in a Scrum or similar capital-A, Agile environment. There are many exceptions, but the overwhelming majority are working in 2-wk sprints, sometimes getting a sprint-0 in to do “discovery”.

In my work to amplify the value of design in organizations for their customers, I have noticed that organizations that work in Scrum and other hardened and “certified” Agile methods, aren’t designing their designs at all and thus not able to bring the value of design to the organizations that are funding this design investment. They are shipping. They are even getting prettier designs, and engineered designs.

First off, Scrum is not a process ever designed for designers. Further Scrum is probably the worst example of agile based on the agile manifesto. It corrupts it by taking something that at its core is meant to be fluid, and makes it rigid and well not very agile. It becomes dogmatic. But if we look at what makes design, design vs. engineering, it is three things (minimally): empathy, creativity (this is the big one) and vision (the 2nd big one). Without these 3 components, you aren’t designing, you are just developing or engineering. At best you may be doing bad designing.

So some people might be confused. What does it mean to design a design vs. engineer a design. Aren’t all designs designed. I’ll use an analogy here. You could say I cook my food. I don’t. I’m not worthy of the word cook and my outcomes are barely worthy of the word food, let alone “cuisine”. Though I guess if I throw tomato sauce on it, it is Italian cuisine, though I boiled water, threw dried pasta in the pot, and poured sauce out of a jar. No, I don’t cook food. I prepare food. Now this example is maybe a little more derogatory that I intend, so I apologize in advance. I do not want to insinuate that engineering is bad and design is good. In fact, the value of design is in its uniqueness and in its special type of outcomes that compliment design (as a verb) and we couldn’t make excellent products and services without it. But I still want to be clear that engineering is not designing because of what it doesn’t do, not because of what it does. Because of that, I want to go back to my 3 items as they are what makes designing unique from engineering and I’m not about to define either design nor engineering. All I care about is the difference in this article.

In Scrum, single track, standard Scrum, there is no room to create empathy. If a sprint-0 is all an agile UX team gets to do discovery, what they are really going to do is work with a PM to understand requirements. At best the Scrum schedule will allow for validation of design (getting to understand if the designs they’ve done are done correctly). What a sprint-0 can never do well enough is the empathetic approach of determining first if it is even the right design to be designing in the first place. Lean UX, as Jeff Gothelf’s puts it, puts the brain (and I’d say adds a little heart, too) to agile’s muscle. Actually the quote of “Agile doesn’t have a brain” comes from Bill Scott (full article here).

But Agile even with Lean approaches still doesn’t give products a soul through a fully enriched heart. This requires more than hypothesis invalidation. This requires the depth of a team, together, diving into understanding their customers at an emotional level.

Let’s put empathy aside for a moment. Because it is actually the easiest to overcome in a large enough organization that are running Agile certified systems. Just do research outside of the sprint cycle that creates its own stream of insights that are referenced during sprint-0. But there is more to this, but still relatively simple.

Creativity and Vision are much more challenging because these need to exist as much outside of the sprint-0 as inside of it. Today I was speaking to a former employee of a major internet financial services organization. We were talking about their design operations (for good or for bad). What was clear was that “the sprint” as unit, and agile as philosophy in general broke or outright prevented these two important qualities of design from happening.

Creativity

I’d say there are two aspects of creativity that are important in design. The first is quite simple, the diamond, or more commonly spoken about as a double-diamond throughout the entire product lifecycle. But each diamond is the same. The single diamond separates diverging thought processes from converging thought processes.

A diverging thought process is one that starts from a strong trigger or set of principles, but then without judgement springs from that point outward, ever widening and with ever increasing freedom from limitations.

A converging thought process is then where all ideas from the diverging process are filtered, validated, vetted, judged, etc. utilizing specific methods based in design systems.

In my conversation with this person, it was really clear that the world he was forced to live in because of the engineering-based agile method, forced him to be divergent and convergent at the same time. He asked his Jr. designers to “innovate but keep it feasible within these constraints.” While obviously as an end result this is totally what we want as both engineers and designers, he knew that it was a broken request from a designer’s perspective.

In the TV clip called “The Deep Dive” the design team is working on the creation of a brand new shopping cart. They were in the divergent or ideation phase (they were doing this in a week sprint). At one point Ted Kopel asks David Kelly is all of this valuable. David Kelly’s response (paraphrasing) was that you have to have the baby in the velcro diaper idea in order to be successful at ideating. You need it not because it will be used, but because the idea itself tells us something about the material of the solution that other ideas won’t, so you need it as fodder to pull from and associate with other ideas towards coming up with feasible solutions later.

This is the associative nature of creativity in a design context. It is lost if you add convergent, evaluation to the same moment as divergent, ideation. You are breaking design.

Vision

Then there is vision. Few design organizations are even given the time to work on anything other than the #.# release. What’s next week, next month, this quarter that we can ship. Yup, some of this is of value, but much of it is shipping for shipping sake. Something that Jeff Gothelf properly calls out as a “vanity metric” devoid of value or learning.

But what is so important about a longer view at things. What does that give the designer that could be so valuable. Associative thinking as minimally described above is one side of the design as verb coin. The other is abductive thinking. Sometimes this is also called deconstructive thinking.

Designing visions is part of an ideation thinking process that gets framed or evaluated in reality of feasibility and desirability through the process of designing it. It also provides the business value of being an alignment tool for the team, to talk about where all the .next iterating they are doing is meant to be heading. But from the “broken design” issue most of all it keeps designers from taking advantage of abductive thinking through a deconstructive practice.

Design is best when it tears away. The only way you can know what “just enough and not any more” is if you know what more than enough is. So designers need to be able to go deeper, do more, and then tear away.

Without this ability and with the Diamond process and further without deeper empathy you are asking your design organization to work hamstrung. Then what happens is that you as a business leader begin to question the value of your design investments and when crunch time occurs every budgeting cycle it becomes are more difficult fight to give your design teams the resources they had before let alone what they really need to succeed. In essence, business owners are just creating self-fulfilling prophecies of design’s failure to truly create value for their organizations. When it is time to make cuts, it is always easiest to cut where those failures take place. When it is time to invest it is always hardest to invest where you have the least confidence of success.

I am not against agile (little-a) at all. Concepts like Lean Startup, Balanced Team, and the agile manifesto are value contributions that help teams deal with the age of digital transformation. But big-A, Agile is just too focused on the needs of developers and in doing so breaks the core value proposition that design can and should be providing to the organizations that invest in them. We can do better and should do better.

I’m not suggesting “big design up front” at all. I’m suggesting systems like Dual-track combined with Kanban. #noEstimates movement. And even the values of Balanced Team and Mob Programming can all in part or in whole be combined together with core principles of design methods to create something new and balanced for your organizational culture to bring out the very best of your product, engineering and yes even your design teams.

UPDATE: I have taken away all-caps when writing Scrum at the bequest of an agile UX advocate. I had a silly reason for doing it. And so this is better. The person was right.

--

--

Amplify Design
Amplify Design

Published in Amplify Design

Amplifying your design team’s value through design operations (DesOps)

Dave Malouf
Dave Malouf

Written by Dave Malouf

Dave Malouf is a specialist in Design Operations with over 25yrs experience designing and leading in digital services. I coach ppl and act as a thought partner.

Responses (34)