Design Agile >> How to Work with the Scrum Methodology in UI/UX Design

_{Written by Oliver Schellner, UI/UX Designer}

Why agile? – A little bit of history

Nearly a year ago, we decided to transition to an agile company because developing a product seems to be way faster in this setup, but we are still dealing with several issues. One we are currently working hard on is how to integrate UI/UX designers like me better.

In our previous setup, which was a cross between the ›waterfall model‹ and ›agile‹, we struggled with some common issues. Development was taking too long. If somebody requested changes, you often had to start from scratch. Most processes were pretty linear, and when we were working on the hottest app, we lost sight of the others. Although the designers aligned with the devs on a weekly basis, we were not able to structure the workflow as efficiently as we are doing it nowadays. Many designers worked on one product at the same time and so did the developers, shifting work from here to there just to finally release another mobile app.

But things changed. We took a closer look at other companies and how they organize their daily business and finally transitioned to an agile working company using a model based on the Spotify “squads” framework. Now we are working with Scrum as a basic setup and adapting it here and there where needed.

Scrum, a short insight into the Runtastic workflow

With scrum, our squads are building a product step-by-step based on iterations in a never-ending process to improve the product constantly. Those iterations, known as ›sprints‹, are set up by forming small working packages out of important requirements from the backlog, splitting them into tasks and assigning those to different persons. The squad then works on its tasks to finally develop a usable piece of the product at the end of the sprint. Therefore, we have people from the different scopes like developers, designers and testers working together in one squad. Those people are then again led by a scrum master (SM), who also takes over the organizational stuff for all sprint-related meetings and is aware of barriers that could cause problems in the development process. And last but not least, we have our product owner (PO), who takes over all the technical requirements, prioritizes them and leads us as a team on our path to a wonderful product.

Ok, but what’s the issue now with designers?

Before explaining what doesn’t work, let’s take a quick look at the benefits of scrum.
Thanks to sprints, which usually last from 1 to 4 weeks, the squad is always delivering a functional part of the product at the end of one iteration, and so everybody gets in the habit of finishing things up. And this feeling of achievement keeps everybody motivated. Furthermore, everyone finds it way easier to estimate the effort needed for the tasks, and that’s why the failure quota is lower. Moreover, the whole squad can address issues immediately when they arise, and if anybody comes up with some great new idea, it’s easy to put it into an upcoming sprint. So, for example, we experience designers get the possibility to make valuable changes to the user flow, which can then be translated quickly.

So far so good, but now to the dark side of scrum and how Runtastics suffer from it.
One major issue we designers have to face is that the tasks of a sprint should result in a usable product piece or feature which can be implemented right away.
But what devs are actually implementing on the frontend are designs that have already been made, and most likely not in this sprint, but a previous one. And that’s a problem because if designers don’t work in the actual sprint, they might not get tasks for it. And if you don’t have your tasks, you simply lose important structure and usually get less attention from your SM and PO when it comes to estimating the effort, which makes things way more difficult.
Another issue that we have noticed is that sometimes we don’t know what’s happening in other squads because our attention is so focused on the product we’re developing in ours. That’s why we have created collaborations between the different squads. After every second sprint, we add an additional week called a ›platform week‹ where all employees of one scope have the chance to align and update themselves across all products. They also get the opportunity to set up style guides, figure out rules to follow, specify components or even evolve new strategies for working within the squads. So, in this instance, we found a solution.
But some people think that there isn’t enough time in an agile setup for creative processes within bigger software implementations. Due to the fast iterations and cutting everything into as many little pieces as possible, UX designers don’t have enough time to think through the entire process. People start to get worried about not finding the right solution within a fixed period of time and feel the stress of having too much to do and too little time to do it.
Therefore, lots of design experiments have been done, and now there are many different techniques for tackling such issues, but we still have to improve continuously.  

A solution?

So what can be done to integrate designers into an agile environment better?
There are several different ideas for improving business workflows which have been developed by different people and companies who have faced similar difficulties. For example, the Objectives and Key Results (short OKRs) method founded by Intel co-founder Andy Grove and first used at Google. These OKRS not only show the main goals of a company but break them down into smaller goals on a quarterly basis. And that’s why it fits pretty well with an agile environment. If you then build a roadmap based on the OKRs, everybody knows the next big steps, and so it has become an important tool at Runtastic.
There are also some other ideas for improving communication in and throughout the squads via a whole series of meetings to align different aspects and thus increase efficiency. These include sprint retros and backlog refinements, just to mention two. And we designers also got the chance to join some of those meetings, which are usually just for developers. Most of us felt that we got a better understanding of what things were realistic to build and which were not.
But Tommason Nervegna has developed another pretty interesting technique for integrating designers called ›design waves‹. His theory is that most companies fail hard because they’re trying to unify two kinds of people with different ways of thinking. So his idea is to combine the necessary elements of design thinking, lean UX, and agile by doing a 5-day design sprint followed by an additional 2-week sprint before starting the normal agile iteration. And we are trying to do the same thing here at Runtastic.

So to sum it up, I think agile can be seen as both a guide to prioritizing values and as a basic setup on which you should feel free to build your own company-fitted structure. Just a foundation and not a big strict plan full of rules you have to follow. As every product and client is different, companies need to be agile, and there is always a way to deal with the problems that arise.

Better design together. How do you integrate designers into agile? Got any ideas on how we can do it better? Feel free to share your experiences with us by leaving a comment below.

***