I remember a few years ago, I and my colleagues at the consultancy firm I worked for back then were offered the chance to attend a scrum master course. Almond everyone said yes.

The firm was quite small, with only about 20 people at my office and only two UX designers. Our teacher was great, a guy with 20 years of experience and even though all of us have worked in scrum teams for years, he had tons to teach us.

Just before lunch, we discussed how UX and UI designers fit into the scrum team. We discussed their role, whether it was a good idea to include them in the team and how UX and UI design could be included in the sprint.

My fellow UX designer colleague argued that the UX designer needed to be a step ahead. Researching and designing story’s for the upcoming sprint. The teacher argued that she was wrong and that we needed to read “Sense and Respond” by Josh Seiden and Jeff Gothelf.

I was really curious and decided to get the book right away, because my experience was also that the research and design needed to be done ahead, and finished before the sprint planning for the upcoming sprint. Could we do it differently? The way we were doing it wasn’t always optimal.

The biggest problem was that sometimes we would spend a few weeks researching and designing a feature, and then it was prioritized down. And by the time it was included in the sprint the design was obsolete.

Sometimes it was never included, so we basically spend a few weeks designing something that was never implemented. I know that it is not a big deal really, it happens all the time, everywhere. But still, could we do it differently?

Traditional design process — Waterfall model

Before we take a look at Sense and Respond let’s take a look at the traditional design process. Before the agile way of working with software development was common practice, the waterfall model was used.

The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of a task. People within the company work in different departments that do not collaborate, the different departments are viewed as silos within the company.

It can look like in the image above. All design is done before software development. This means that the design is probably finished mounts or years before the software development begins, and there is usually not much room for making changes.

Within the waterfall model designers usually follow the 5 stages in the Design Thinking Process. Empathize, Define, Ideate, Prototype, Test. I will not describe this in-depth but the Interaction design foundation has a great article where you can read more, 5 Stages in the Design Thinking Process.

The agile way

On the contrary, the agile team is a mix of people with different professions. Developers, testers, designers. There is also a product owner that is responsible for delivering value to the customer. And a scrum master that facilitates all the scrum practices.

Compared with traditional design, the visual and UX designers in the team can not, for example, design the whole new website while the rest of the team is waiting. Design, software development, and test need to happen simultaneously.

But as a visual or UX designer, you can not design the same part of the website while the software developer is coding. The design needs to happen before the development, but how far ahead? There is some mixed opinion about this as you could read in the intro.

I will describe two ways of doing this. When the designers work one sprint ahead and, Sense and Respond, when the design and development of a feature are done within the same sprint.

1. One sprint ahead

The UX and UI designers work one sprint ahead and finalize the layout and user flow before the actual sprint where the feature is developed. The final theme and design can be prepared in the same sprint as development. So the team needs to plan two sprints. The scrum team could have two different sprint boards. One for design or one for development. Or the team could share one board and have one design column.

My experience is that this is the most common way to do it. It is a good way to do it but as I mentioned in the intro, sometimes it is difficult to plan. So, by the time the feature is to be developed the design is obsolete.

2. Sense and Respond

“Sense and Respons” is written by Josh Seiden and Jeff Gothel, the authors of “Lean UX”. The core principle of the book is that companies need to engage in what Josh and Jeff call a two-way conversation with the market. They need to try out new things, learn from consumer interactions, and adjust their plans quickly. Sense and respond.

They write that agile teams need to prioritize learning over delivery. They need to have small feedback loops with continuous communication with the users/customers and continuous delivery. For example, the authors write that Amazon releases new software every 11,6 sec.

“Start by creating a conversation with your customer so that you can learn first, and refine and deliver later. (…) Without the learning, you risk delivering a product or service that no one finds valuable.”

One way to do this is to for the team to ask themselves the following questions:

• What is the most important thing or things we need to learn first?
• What is the fastest, most efficient way to do this?

Because the sooner you find out you were wrong, the better.

Working according to Sense and Respond requires the team to collaborate tightly. This usually means that all the team helps with all the different parts of the development process. The whole teams help out with the research, helps design, test prototypes, or develop an MVP.

As a designer in the team, you are responsible is the design but your teammates can help you out with ideas. As a designer, you probably do not write code but you could help out with something related. Writing release notes? Finding answers to questions? Solving other problems that do not require writing code.

This is where the magic happens. I have worked in teams that have tried to implement this way of working a few times, but without the support of the managers in the organization, it is very difficult to stick to it. It requires commitment from the whole organization.

To conclude. Working by the Sense and Respond methodology is great but it required that the whole organization commits. It is quite difficult for a single team to do it by themselves. Working one sprint ahead is fine, but make sure that it is only one sprint ahead, do not design months ahead. Or your risk wasting your time designing features that will be obsolete by the time they are developed.