Improving Design & Agile Development At Scale

Harri Kiljander at UXDX Community: Helsinki. Video: https://youtu.be/rwnYBH-7ejI

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.

Introduction and Yousician

[00:00:03] My name is Harri Kiljander, and it's really a pleasure for me to be here with you in this online conference. We actually already had a plan to set this up in the Yousician office in Helsinki, but due to this coronavirus outbreak, we are now attending from our home offices or from any other safe locations. A brief intro for myself: I lead a team of great product designers and marketing designers at Yousician. If you're wondering about this specific picture, we arranged an annual off-site for our teams in Helsinki. We also have a small team in New York. We work and have some fun in some warm location, and this was November last year in Las Palmas [?]. We were working for a couple of weeks, we did some work, we did some summer stuff, we were planting some trees, and we also did an agile sandcastle exercise. More about the sandcastles later.

[00:01:11] Some of you may know Yousician. Now I need to be able to... yes, now you should be able to see my second slide. Yousician: we are a ten-year-old startup in Helsinki, so we are almost like a teenager. The company was founded with the name Ovelin. It was part of the Startup Sauna accelerator program at Aalto University [?]. Our mission is to make musicality as common as literacy. We make the world's best guitar learning app, called Yousician. You can also learn to play the piano, you can play the ukulele, you can play the bass guitar, and you can learn singing with the app, and we have some tens of millions of downloads for that app.

[00:02:01] Then we make the world's best instrument tuning app, called GuitarTuna, and that one has over 100 million downloads. So this is quite a big number of people using our products and services out there. We have roughly about 100 employees, most of them in Helsinki, with a small team in New York. Roughly half of them are developers: that's back end, app development, some DSP, digital signal processing, and web development. And then we have roughly 10 designers in our growing design team.

Collaboration problems at Yousician, F-Secure and Nokia

[00:02:44] How do we make this all work? We have designers, we have multiple development teams, and like with most other development organizations right now, all those teams are following some agile frameworks or practices. There's Scrum, there's Kanban, there's XP, there's streams [?], continuous integration, all that stuff. I've been trying to figure out how designers and developers can collaborate efficiently and effectively for a rather long time. I joined Yousician last year, and when I was interviewing design stakeholders in the company, quite many were raising the question of collaboration: glitches that are caused by manual handoffs between designers and developers. Those were topics that were raised.

[00:03:37] It's quite familiar, because before Yousician I worked at F-Secure as design lead for close to 10 years. F-Secure makes cybersecurity, and in the consumer cybersecurity business unit we were developing products like antivirus apps and VPN; if you've heard about Freedome, that's what we did. We did identity protection, password management and secure Wi-Fi. We did a big reorganization roughly three years ago at F-Secure, and one of the big drivers in that reorg was to streamline and improve the collaboration between the design team and the development teams, so that we'd have the development projects staffed with the appropriate design competencies, and design would not be seen as a bottleneck in the overall product creation.

[00:04:28] It's interesting, because most of the time it's this way, and maybe this is a bit provocative now, but most of the teams, the development teams, usually think that designers are the bottleneck. It's never the other way, that designers would think that developers are the bottleneck.

[00:04:47] Even before F-Secure, I worked in product creation at a company called Nokia. Half of Finland was working for Nokia at that time [?]. This was back in the days when Nokia was still developing its own mobile operating systems, and our plan was to develop the world's best smartphone platform based on Linux and then build phones with that software. This was a massive undertaking for Nokia, and to make it happen, we knew that we had to make the design work and the development work happen in parallel, super smoothly, in an agile way. We had heard about agile, and in our context we had very many unknowns: the hardware wasn't ready, the software wasn't, the partners... we knew we had to build an app ecosystem [?], all that.

[00:05:38] If you look at these product categories, they seem to be quite different, but from a product creation process perspective they are pretty similar. They share the same challenges: how to do the design work and how to do the development work so that the whole organization is working efficiently and effectively, allowing people to do their best work and also learn new things while they are doing that. At Nokia, we worked with some pretty smart software thinkers, and they helped us shape our way of working and build those processes and practices between the designers and developers.

The Agile Manifesto forgot design

[00:06:29] Now comes a bit of provocation. Some of you may have heard about the agile software development movement, or even the Manifesto for Agile Software Development. Back in 2001 there was a developer called Alistair Cockburn, and he invited 17 of his smart developer friends to a ski resort in Utah. In that workshop, which lasted for a couple of days, they produced something they called the Manifesto for Agile Software Development. They wrote twelve agile principles, and even though they were developers, they realized that they need the business people to do their work. One of the principles among these twelve was that close daily collaboration between business people and developers is required. However, they mostly ignored design in their work.

[00:07:27] I got to know Alistair later. He was consulting for Nokia, and I asked him, "Hey, why didn't you include design, say professional designers, in this work?" He admitted that they completely forgot. They completely ignored it. They remembered that they need the business people, and being developer guys, and they were guys only, there were no female attendees in that gathering, they just ignored design.

[00:08:00] Then at Nokia, we were a big organization, a huge company that makes a lot of software. We heard about this great new thing called agile, and we decided to go live with agile. We had a big design team working in the organization, so we were stumbling a bit. "Now we are going agile, agile doesn't say anything about design, we have these designers, how do we make this work?"

Design thinking, Maemo and the agile UX manifesto

[00:08:25] What I had heard and learned earlier, and my thinking was also influenced by a guy called Tim Brown from IDEO. He had presented, around the same time, his view of design thinking. He did not invent design thinking, but he popularized it with this Venn diagram: a human-centered approach to innovation that draws from the designer's toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success. To me this made sense, and this was how we were building the organization. Then we wanted to see how this could coexist with agile.

[00:09:21] We were able to get something done, presumably, because two years later I went to the Scan-Agile conference. This was 2009, two years after we started the Maemo work, and I was sharing our experiences of how to integrate UX design work with agile software development. Some of this is still pretty valid. I had more slides; you can find those slides on SlideShare. The presentation was the good, the bad and the ugly, and this was the good slide.

[00:09:56] Assigning designers to work in agile Scrum teams. Establishing continuous user testing and feedback mechanisms, treating user testing like quality assurance. Using appropriate levels of prototype fidelity [?]: you don't need a super high-fidelity prototype every time; many times it's definitely more relevant to get the testing done super fast. We had to do a lot of marketing materials production, and eventually we decided to branch that to a completely separate team, without burdening the other product designers with that work. And Nokia being a huge organization, there were lots of helpers around our team, so eventually we just learned to say no, even to the vice presidents and their spouses, who had lots of interesting ideas about what we should be doing.

[00:10:53] Naturally, even a bit before, around the time we started the Maemo design and development work, we had the opportunity to work with the same Alistair Cockburn who had kicked off the Agile Manifesto work. He came and was helping Nokia improve its software development practices, and we were able to arrange a workshop with him. The designers were learning agile from him, and he was learning from the designers about design work. This was 2007: we produced a manifesto for agile UX based on this, thirteen years ago. Spiritually it's quite similar to the Manifesto for Agile Software Development; obviously Alistair was an influence on our thinking a bit. There's an interesting element here, by the way: you can see that 13 years ago, slides were not widescreen like they are today.

A pragmatic list for designers in agile teams

[00:12:00] The agile movement in general nowadays is full of different tools and frameworks. I was doing some research yesterday when finalizing these slides, and I counted 33 different agile frameworks. One that has been developed for huge, massive global enterprises, big organizations, is called the Scaled Agile Framework, or SAFe is the acronym. Even SAFe decided to embrace design last year, so they added design thinking and lean UX to SAFe. For a small organization, this is possibly a bit on the overkill side.

[00:12:51] Being a pragmatic person, I wanted to crystallize what I've been thinking into a list of simple things you can hang on the wall and keep in mind. This is obviously context-specific. I've been working in product companies, and I know that the situation, for example, in an agency is different, so this may not completely apply to your setup. But with agile in general, you shouldn't treat it like a dogma. If you read something from a book, you need to be able to apply it in your own organization, to your own product, to your own team structure and customer requirements.

[00:13:41] What I've learned in my current job and the two jobs before this one: staffing the designers in these agile development teams, whether they're called teams or squads, is the way to make designer-to-developer collaboration work. They need to share the same objectives. Designers need to be joining the daily stand-ups of those teams. We've been running design sprints both at Yousician and F-Secure. They are really good for building cross-disciplinary commitment. You need to have the product manager or the product owner, whichever title or name you have for that role, developers, architects, someone from customer support or customer care, and the designers. There needs to be a facilitator who knows how to facilitate it, for a week or two weeks. It's really good, because typically when it's over and people get back to the daily work and the sprint cadence, a lot of the communication and shared understanding is already in place.

[00:14:52] Then what I learned about usability testing: software developers take QA super seriously, and I think it's easier if you can ride on that when it comes to user testing, injecting user testing and validation into the overall product creation process. A feature cannot be released until the QA is done, so if usability testing or user validation is part of that, it semi-automatically gets done as well. Obviously it needs to be resourced.

[00:15:26] Then there's a lot of talk about design systems nowadays. Many times they are just glorified names for UI component libraries. They are definitely good and useful, because you can establish a level of consistency and make your designs cohesive [?]. If you have a bigger company, with a number of products and a number of touchpoints and platforms, the design system will ease your pain tremendously. Also, in the workflow across design, development and maybe even product management, avoid manual handoffs. Jira, Confluence, and other tools like Zeplin or Figma are definitely good, because any time you inject a piece of manual work into a handoff, there will be errors, and those errors need to be fixed, and time needs to be spent on fixing them.

[00:16:24] I said in the first one that staffing the designers in the development teams is really good, but you also need to have a backbone for the design function, be it a team or a chapter, to build design consistency, develop the design system and also develop the design talent. You need to hire new designers, and many times software engineering managers may not really have the skills required to hire great designers. So there needs to be someone else who's hiring the great designers and coaching the designers.

[00:16:56] Sometimes I hear from agile thinkers that designers should have no other work than the team work or the sprint work. But there are also things like insights gathering, strategic foresight, or future concept development and exploration, and usually that doesn't really fit into the cadence of the agile development sprints. So you need to build a mechanism where that work can happen outside the daily grind of the development teams.

Closing

[00:17:37] That was it. Thank you, everyone, for joining us and listening to me. I'd like to remind you that we are hiring in Helsinki. There are some pretty cool positions, so please go and check those out. You can find me, for example, on LinkedIn, and you can find these slides on SlideShare. And about the sandcastle on the first slide, the agile experiment: one of our agile coaches, Alexander [?], wrote a really good piece on Medium about what we did, why we did it and what we learned. Twenty years ago I attended a similar exercise. It was run by some Danish software development people [?], and because they were Danes, we used Lego. But that was 20 years ago, and there was no sand. OK, thank you, and now I'm ready for questions.