Integrating UX & Agile At Yousician

Tuomas Saarela, Noe Falzon at UXDX Community: Helsinki. Video: https://youtu.be/vAWLn7v4owM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

How teams work at Yousician

[00:00:00] My name is Tuomas Saarela. I'm a UX designer at Yousician, and my talk will be joined with Noe. He is a Scrum Master in our Engagement Squad. How many here know what Scrum is? Quite many. Okay, that's good, because our original idea was to also talk about Scrum, but then we realized that half an hour is impossible. You cannot really even scratch the surface, so we left it out.

[00:00:43] It's been almost 40 years since designers started to work in the software industry, but it seems that we still have lots of room for improvement. At least at Yousician, when I joined, design wasn't always easy to do in this very agile environment. When I was requested to talk here, here's the request. Already in this request there is something that, from Yousician's perspective, is wrong.

[00:01:28] At Yousician, our team structure goes like this. We have small teams, which usually means less than seven people. They are efficient, which means that all the skills needed for day-to-day operations are present in one of the team members. If you need some certain resource, be it design or data analysis, you have to have it in the team. And finally, empowered: teams have clear goals which are set for them, and within those goals the team can independently decide how they're going to work. If you want to learn more about Yousician's working culture, visit company.yousician.com.

[00:02:23] In our team, called the Engagement Squad, when I joined there was a product owner, three app programmers, a back-end programmer and me as a designer. Then last October we decided to give Scrum by the book a try. One of the things we found out during a Scrum retrospective was that we didn't have all the resources in the team. For example, QA was a huge bottleneck. So during the autumn we hired a QA specialist and also a data analyst for the team, and the team structure in the end was something like this.

[00:03:21] I could easily give a two-hour presentation on Scrum, but in short, in my opinion one of the biggest benefits was the power of the retrospective. Almost all of the things I'm talking about today were found out, and we found the solutions for them, during the retrospective. That's something I really encourage every team to do.

Problems with the old workflow

[00:03:56] How did we typically work in the autumn in the Engagement Squad? Usually there was some kind of feature request from the product owner. Maybe the idea came from other managers or someone else outside of the team. Then that idea was handed over to me to work on the design. Sometimes research was also involved. Then that idea or feature got into backlog refinement and sprint planning, and it was only at these points that the rest of the team ever saw those ideas. Until that point, developers were totally unaware of what was coming. They didn't have their say on the feature, and of course you can imagine that brings problems.

[00:04:56] Then the feature got implemented. The Yousician way is also that we measure every experiment. Any change in the app, we put in as a separate experiment, which we then A/B test on a certain number of people, so we always see where the changes are taking the product. For that, having a dedicated data analyst in the team is a huge benefit. It wasn't always like this, though. Sometimes those feature requests skipped the whole UX design and research part and went straight into the sprint, and that can also cause a lot of problems.

[00:05:48] One of the problems was that design was often not ready in time. These are, by the way, straight quotes from the retrospectives we had. Then, we were working in silos. People felt that the designs were often presented only in the meeting when we should already start to take some action on them. So there was almost always some kind of need to tweak decisions that had already been made, which was time-consuming and very inefficient.

[00:06:30] One piece of feedback was that we were working too much in Slack and email and Jira comments; verbal communication was wanted. Then there was this mysticism of design. The design process, or the tools I was using, were not transparent to the rest of the team. I was also not using the same ticketing system, so the UX and design tickets were never in the same backlog. It was just very mystical to the rest of the team how the design actually happened.

Staggered sprints and dual-track agile

[00:07:14] One of the solutions we decided to try is called a staggered sprint. If you know Scrum, you probably know the idea: you always do design up front, so you have the design ready at least one sprint before. Then when that design gets into implementation, you start the design for the next sprint. At first this seemed like a good idea, but very soon it happened that the designs were again not ready in time. It felt like the handoff point was always problematic. I was still working mostly alone, only collaborating with the product owner, and in a way this also felt like a kind of mini-waterfall approach.

[00:08:14] Has anyone here heard of the concept or book called Lean UX? Some of you are. At this point in the autumn I happened to read this book. Really nice book. I'm not going to go too much into detail, but it's basically an evolution of product design and team collaboration, based on the lean startup and agile software development thinking. The main message of the book is that the first attempt we make is probably wrong, so the sooner and faster we get it out in the field, the sooner we will get feedback on how we should revise that iteration.

[00:09:03] One of the ideas the book suggests is called dual-track agile. It's the same process, but all the tasks related to finding out whether we're building the right feature (will this work, how did it work) are called product discovery, and the rest of the tasks are product execution. The idea is that the team is split into these two units, but it's not the same as the staggered sprint. In dual-track agile, discovery is a continuous process. For execution, sprints are actually quite a nice idea: you have these two-week slots. But that doesn't work that well with design or research. So dual-track agile offers an interesting way to make this learning process more transparent and available to the team.

[00:10:13] The feedback we got from dual-track agile was good. People who were validating the feature in the discovery track were also present in the execution track. Some feedback we got was that it was a great initiative to put the discovery out there, but you always have to dedicate time and resources to keep that discovery track alive.

Collaborative design

[00:10:47] Is the sound circulating only for me, or for you too? If there's anyone, a musician, who could help with the sound, I would appreciate that.

[00:10:56] One of the things the book suggests is collaborative methods: collaborative research and collaborative design. Next we're going to talk a little bit about this. At the end of December we were entering the first sprint of the year, and we really didn't know what to build. The backlog was mostly empty. This was the first time we really decided to give these new discovery methods a try.

[00:11:38] At the end of December we held a short design sprint. Not the full-week thing; we got it down to three days. We started from the research fact that advanced players don't consider Yousician as a way to play songs. Sorry about the mess; this was the only photograph I had from that workshop. But basically, instead of having a ready-made idea or feature, we started from the actual problem: what is the problem? We really dug into the data together as a whole team. The result from this was totally different from before, when the team was handed these ready ideas.

[00:12:35] I will show the feedback later, but in our experience that was a really good experience. Thank you. Ownership was high. And when we finally transitioned to the implementation, it went the smoothest ever.

Collaborative research and handoff

[00:13:08] We were also experimenting with collaborative research. In our case, that meant we started doing user testing every week. Even when we didn't know whether we had something to test, we still scheduled users to come every week. That was good, because then the whole team had the comfort that if you are unsure about something, we are only a few days from the next test, where we can actually validate whether that hypothesis is right or wrong.

[00:13:49] Before, I was doing all the research alone. I did maybe five or six tests and then presented the research results to everyone. What we started to do instead of me being alone with the user in the room was that I always brought someone from the team as a note taker. They were taking notes, and very often they also had some question in mind that I didn't figure out to ask. The rest of the team was watching the test via stream. Maybe not everyone was always able to watch, but usually immediately after the test, preferably on the same day, we had a debriefing session.

[00:14:44] Instead of waiting the whole week and then presenting the results of the research, because there was a note taker in the room who had their notes, and a couple of other team members had already taken notes, we had this debriefing immediately after the session, where we went through the findings. It turned out there were so many findings that I alone couldn't always find. It not only brought us more findings; the feedback from the team was also that they started to understand who our users are, and they started to have more empathy towards the users.

[00:15:30] Here's some feedback on the method. Our team really thought that they were no longer fed with ready-made ideas, but that they could actually take part in the whole process. The synergy we got from this, we couldn't even have imagined.

[00:15:58] Quickly, I'll mention the handoff tool. We were also experimenting for the first time with using InVision Inspect as our handoff tool. Instead of handing over screenshots and text, I was creating this Inspect in InVision, where the developer can actually see all the specs of the assets and elements on the screen. If you haven't ever tried out InVision Inspect, or also Marvel, which has its own inspect element, I really suggest trying that.

The updated workflow

[00:16:39] The updated workflow in the end was pretty much similar, but we had that discovery part always going on. Instead of feeding the team those features, we started to work from the user problem or outcome from the start. Something else that came up during the retrospective was digital prototyping. We haven't really got results from that yet, but one piece of feedback we got from the developers was that making these experiments is always such a huge thing. You have to take into account so much of the existing code base, and you already have to think about how it's going to get rolled out to others, and refactoring, and everything. So developers thought that being able to prototype without thinking about making clean code is very valuable.

[00:17:53] So in the updated workflow, the idea was to bring the team in early, introduce problems, not features, have constant user testing going on, have the discovery track always going on, and keep all the discovery tasks in the same team backlog. In the end, we think the mentality in the team changed, and all the team members felt they could have a better impact on what we're building.

[00:18:44] This is the last quote. After trying out these collaborative methods in the first sprint in January, this was the feedback from one of the team members. So it was a successful experiment. Any questions?