Agile is not a Design tool

What if I told you that Agile is not a Design tool? 

Talking to a friend over coffee, the conversation quickly turned to a classic: What are the most misunderstood aspects of Agile? Obviously we started with “Agile mindset vs. toolbox” and how the mindset and philosophy often matter more. Quickly we moved to another aspect, less discussed: 

Agile is essentially for production not for design. 

It is smart and flexible. It is design-friendly, it is probably the best software delivery framework, the most enjoyable, the most efficient, with baked-in continuous improvement. We love Agile. It does little though about designing the right product though. Efficient (building something right, no waste) but not that effective (building the right thing, value delivered).

And a lot of friction in Agile project delivery comes from that, from BA's and PM’s delivering code efficiently, "delivering requirements" efficiently... But when the user metrics come back and value feedback/“insights” are poor (uptake/ UX/ NPS/ monetisation/ CRO, etc.) everyone rubs their eyes in disbelief, then quickly starts running around pointing fingers. 

There is a better way, and it implies bridging that gap between design and production.

Why is the gap between design and production hard to bridge?

A lot of modern, high value BA/PM'ing work these days goes to bridging that. Making sure the production team understands as well as possible the ideal outcome that their user is looking for, how, why, and how to collectively engineer that. 

It’s not easy. 

Different people, different skills sets, different languages:

Designers do not speak the same language as developers. UX Designers feed off the energy of a second opinion and set of eyes, a tone of voice to bounce ideas with. UX implies an emotional component that they must constantly immerse in. Their work is innately social, emotionally aware, experiential, communicative, user-centric and interactive.

Developers on the other hand speak naturally in an engineering, rule-based, prescriptive language. And they have to be prescriptive and fact based, otherwise, ludicrously unfeasible ideas would filter into the delivery sprints. Developers can pore over an algorithm for hours, capable of feats of focus and relentlessness that most UX designers would balk at.

Bridging that gap is a lot about becoming simply aware of this. Of realising that different professionals have different skills sets, and how they complement. That the creative design needs a smart interface to work intelligently with the rule-based engineering and business stakeholders.

That the smart interfacing in question is a lot about building shared understanding. User Story Mapping is the one activity, if there had to be one that works best I find. A 2 hour session can weave design with production and business cross-functionally and save huge amounts of time, $, while delivering higher end value. 

The powerful illusion of obligatory code scalability:

There is another related element to this design vs. engineering issue. It is, broadly speaking a hyper-engineering view of things, that things intangible (communications, culture, etc.) don’t exist or have less value than things tangible or engineering sounding.

Specifically we can point here to the fallacy that everything in digital must scale. AirBnB famously turned a huge corner the day they stepped away from code scalability for a moment and ventured into non-scalable. It is only then they hit the game-changing design insights that turned them from a seemingly doomed $400/week revenue start-up, to a colossally successful one. And only then that they “stepped out of the trough of sorrow” (their words). 

“We had this Silicon Valley mentality that you had to solve problems in a scalable way because that's the beauty of code. Right? You can write one line of code that can solve a problem for one customer, 10,000 or 10 million. For the first year of the business, we sat behind our computer screens trying to code our way through problems. We believed this was the dogma of how you're supposed to solve problems in Silicon Valley. It wasn't until our first session with Paul Graham at Y Combinator where we basically… the first time someone gave us permission to do things that don't scale, and it was in that moment, and I'll never forget it because it changed the trajectory of the business.”

Their big a-ha moment, that Gebbia alludes to here, is when they prototyped and experimented, to learn why their platform did not generate more bookings. 

The intuition they wanted to validate was that the pictures were not good enough to entice users into booking. That the visual design itself of their product was not viable/appealing enough to trigger bookings, the one user behaviour behind their entire business model.

So they flew around, with a photographer friend, and took amazing pictures of their few hosts’ properties. That was obviously not scalable, they could not do that for ever for all their ever increasing amount of clients. But the insight was invaluable. And they enticed users, wove that into the host UX, so that they took the best pictures, and the start-up took off.

Design and Design Thinking can be hard to schedule and predict. It can be hard to scale. But it does not have to be scalable or perfectly predictable.

How to bridge that chasm between design and delivery?

In summary:

• The language must evolve in your organisation. People must understand that Agile is design-friendly but it remains for engineering and production, not product design. People must have a better conversation about efficiency, and effectiveness.
• Design/Development experts must be made aware of the unique challenges and skills that each brings to the table. That is essential, even if it can be slow to change. In a mature Agile environment this is a lot easier, the culture is more supportive of new ideas or different skills sets. 
• Build shared understanding: Do a User Story Map, that will inform a cross-functional team very quickly on the ins and outs of the project, dev requirements and UX aimed at. That will physically gather a cross-functional team around a visual map of what they are doing from a user standpoint. Move away from the fallacy of having a HiPPO requirement back-massaged into a "user story" format. Make a bit of time to genuinely discuss the user stories, and map them into a total UX roadmap.