Good afternoon, everyone. Thank you for coming to my talk.

Allow me to introduce myself. My name is CJ. I use they/them pronouns. I have been doing UX design for over nine years. I now work at yamaneco, an agile startup as the Head of Design.

I have a few hobbies. (laughs)

I do glassblowing, and I'm making a visual novel called Terranova that will be releasing on Steam this year. I also like taking photos with my adorable black cat.

You probably can tell just by looking at me, but I'm from the U.S. Japanese is not my native language. I'm also not a scrum master or an agile coach — I'm a designer. So why am I here in front of you speaking Japanese?

Because I want others to do the same. Even if it's difficult, even if we make mistakes, to bring the worlds of agile and design closer together, we need to change both our words and perspectives.

"Agile and design will never get along." This is what I thought before I joined yamaneco. To understand how I got from those words to today, let me tell you a story. Previously, I worked at an international design agency by the name of frog. I used to harshly criticize high level executives' software and products.

“Your product sucks,” I'd say, “You need design to fix it.”

Every problem could be solved with design, I thought. Our clients looked to their backlogs for decision-making, not the customer's voice or the product vision. Because I saw them say they wanted to improve their customer experience but give up because of tech restrictions, I also harshly criticized both scrum and agile.

From the outside, I mistook agile and scrum’s purpose as “just to make a backlog.”

So, why did I so harshly criticize scrum and agile?

In 2017, I jumped from outside of product development to inside. Where I previously viewed developers with coldness, I began to empathize with my team's struggles and worries. I started to understand that scrum and agile were not the same thing, and their intrinsic value. I wanted to integrate the design process that I learned at frog with the scrum framework we were using as a team.

But there was one problem. The design process and scrum events don't agree on what is a team and what is an individual decision.

I'd like to introduce the double diamond, a framework used by many designers. In order to make a product that solves users' needs, we use the process of divergence and convergence to first understand the problem and then to find a solution. Because this is a framework, consider this similar to scrum, not agile.

In divergence, in order to generate new information and ideas, we take a few options and increase them. From this divergence, new ideas are born.

An example might be drawing application screens on a whiteboard before developing a feature.

Typically in scrum, this kind of divergence is done between the PO and the designer and then the result of the brainstorming is talked about in the sprint planning or the sprint demo.

In scrum, the word “developer” is used to include both engineers and designers, but in the product world, there still remains the thinking that a developer's role is “to write code” and a designer and PO's role is “to create ideas.”

In convergence, in order to decide and prioritize, we take many options of ideas and information and reduce them.

For instance, when prioritizing the backlog, we collect user stories, and from those stories we pick up ones to focus on, and then decide what stories to work on in the next sprint.

In teams that I have observed, everyone participates.

Why is that?

Well, one reason is because in order to converge on the right items, we need the estimation and the technical opinion of the developers.

By the way, in order to make a strong design that has a consistent vision, has validated user needs and is easy to understand, designers diverge and converge many, many times. In order to do this, feedback and critique is necessary. It is best to have design critique either once per day or once per every two days. If the designer is receiving feedback once a week, or once every two weeks, from a design perspective, the process is moving too slowly.

In scrum, typically sprints are two weeks, where the team showcases their work in a sprint demo, but there isn't much time to dive into thoughtful conversation. So, how do we make this kind of space?

In scrum, typically sprints are two weeks, where the team showcases their work in a sprint demo, but there isn't much time to dive into thoughtful conversation. So, how do we make this kind of space?

These kinds of issues came up over and over again within our product team. Even if we tried to integrate, even if our scrum and our design's vision was in agreement, if we could not agree on who decides what, we struggled.

Can I make a confession?

Even though I was within the product team, I still didn't know how to solve these issues. One day, an agile coach from a company called yamaneco came to our team. When they did, mostly I complained about scrum. We fought a lot.

When I quit the product team, yamaneco reached out again with a proposal for me to join them.

“Why would you ask me to join? All I did was fight with your agile coach...”

“That's exactly the reason why we think you can integrate design and scrum.”

“What??”

So, the designer who thought integration was probably impossible joined yamaneco. I found that designers in agile teams also struggled with the same things I did. Next, I'll share what I learned in working with and coaching these teams.

Even though design is collaborative work, most product designers are alone.

For the past two and a half years, I was yamaneco's only designer. I did everything alone. Customer hearings, idea generation, decision-making — everything was done on my own. In most of the agile teams that I coached, there was only one designer on the team. Most designers I spoke to gave up long-term design work such as making pattern libraries to focus on short-term work like exporting assets for the team's engineers. Just as technical debt accumulated, so did design debt grow larger and more unmanageable.

In order to balance the load of short-term and long-term design work, it is important for the team to collaborate together. Brainstorming, idea generation, and feedback on sketches and mockups is not just the PO's responsibility, but the entire team's. As I mentioned before, it is best to have design critique either once per day or once per every two days. It is impossible for one designer to critique their own work with that frequency alone.

In order for conflict to safely occur, it is necessary to have psychological safety.

In order for convergence to happen, the team must be able to safely have conflict, which means they need psychological safety. It is normal in convergence for ideas to clash and for debates to happen, and so, if the team does not have the necessary psychological safety to do that, the design will be blocked.

For instance, in one team that I coached, there was a lone designer who would always converge on decisions on his own. When a decision involving the design needed to be made, he would not involve the team. During sprint planning, he told the team he was blocked and needed to converge on an idea. However, the team didn't trust him and didn't want to be made to feel stupid, so no one offered up their opinion. The task was stalled, and because the designer was frustrated that no one spoke up, the team started to fight.

Throwing away everything to make a new framework is scary.

When I first began coaching on design and scrum integration, one of my teams was having a conversation around “throwing away scrum.” They said they were scared to throw away the entire scrum process they had worked so hard to learn.

But what if we tried another framework rather than throwing everything away?

Mobius Loop is a framework that combines both agile principles and design thinking. Discovery, Ideation, Picking Options, Measuring Impact, Learning — all of these phases are summarized in an easy-to-understand process. Mobius Loop looks at first blush like the double diamond, but also includes important points that the double diamond does not, such as integrating learnings into new, interesting ideas.

yamaneco proposed this framework to the team, and their initial fears turned into a lively conversation. They compared Mobius Loop to their current processes, and talked about what parts they wanted to add, what parts they wanted to improve, and what parts they wanted to throw away entirely. This is just an example of one such framework. You can make your own framework to meet the needs of your unique team!

I thought this once. And I am happy to say that I was wrong. I am thankful to both my coworkers at yamaneco, and for our wonderful clients for teaching me this.

Before, I harshly criticized scrum and agile because I didn't understand it or the jobs engineers were doing.

But now I will criticize scrum and agile for the exact reason that I understand this world if only a little, and that I love it. In order to make a strong design, it is important to critique it. Up until now, conversations around integrating scrum and design have been about “how to integrate design without massively changing scrum” or “how to include scrum events in our pre-existing design process.”

This, I think, is wrong.

Is anyone here married?

This year will be my seventh-year anniversary. (applause)

Aw, thanks. (laughs)

Before that, I perhaps thought, “I won't have to change my lifestyle or my opinions, and my partner and I will always be lovey-dovey.” But we all know that's not realistic, right? My partner and I are two different people. It's normal for our opinions to clash or for us to have conflict. That's why we create psychological safety around that conflict, try our best to understand each others' feelings, and even if it is hard, or even if we are scared, we walk forward together, with our eyes open.

Scrum, agile and design can be married, too — but it's not always going to be lovey-dovey. Conflict is naturally going to happen, so even if we're scared, why not just do it?

We do this kind of coaching in the design div at yamaneco. And this is the reason why I created a design div within an agile company.

If you listened to this talk and thought, “I want to try the Mobius Loop framework,” or if you are interested in design thinking in your own process — even better, interview a designer. Or if you want to throw everything away and make something new, do it.

Even if we fail, if we grow, we will be stronger—together.

Thank you very much.