Miten SAFe ja UX design saadaan toimimaan yhdessä?

Jos organisaatiosi tuottaa digitaalisia palveluita tai kehittää uusia tuotteita, käytätte todennäköisesti jotain ketterän kehityksen menetelmää. Scrum on käytetyin ketterä viitekehys, jota käytetään laajasti ohjelmistokehityksessä. Se on erilaisiin tilanteisiin sopeutuva, nopea ja itseohjautuva kehittämistyön menetelmä, joka on suunniteltu yhden tiimin toiminnan ohjauksen tarpeisiin.

Jos organisaatiosi on suurempi, sen tuotteet ja palvelut monimutkaisia ja digitaalista kehittämistä tekee useampi tiimi, tarvitsette monen scrum-tiimin yli tapahtuvaa koordinointia.

Joissakin organisaatiossa tämä on ratkaistu siten, että yksittäiset kehitystiimit toimivat scrum-mallilla ja sitä suurempien kokonaisuuksien hallinnassa sovelletaan vesiputousmallia. Tällöin osa ketterän kehittämisen eduista saattaa jäädä toteutumatta yrityksen tasolla. Käytetyin koko organisaation ketterän kehittämisen malli on Scaled Agile Framework eli SAFe, jossa kokonaisuutta ketterien tiimien yli koordinoidaan lean-menetelmien avulla.

‍

Päätimme koota ja jakaa parhaita käytäntöjä, joiden olemme havainneet toimivan, kun suuremman organisaation ketterässä toimintamallissa työskentelee palvelumuotoilijoita, UX/UI designereita ja käyttäjätutkijoita.

‍

Uusia palveluita tai tuotteita suunnittelevassa ja kehittävässä yrityksessä työskentelee nykyään todennäköisesti myös palvelumuotoilijoita, designereita ja käyttäjätutkijoita, koska designin ja asiakaskeskeisyyden merkitys asiakastyytyväisyydelle ja liiketoiminnalle on laajalti tiedostettu (ks. ROI of Design -blogimme). 

Olemme itsekin tehneet muotoilutyötä ja vetäneet muotoilutiimejä suurissa yrityksissä. Usein olemme kuitenkin kuulleet designereilta tai käyttäjätutkijoilta, että heidän on vaikea saada oma työnsä sovitettua ketterän kehittämisen sykliin. Heillä ei ole näkyvyyttä tulevaan tai heidän vastuunsa tuoteomistajien ja kehittäjien rinnalla tai välissä on epäselvä. Heillä ei usein ole aikaa kerätä palautetta käyttäjiltä tai he kuulevat kehitystiimin tai projektipäällikön valittavan, jos he tekevät töitä useamman kuin yhden kehitystiimin kanssa.

McKinseyn suuren design-tutkimuksen havaintojen mukaan yritykset, jotka tehokkaimmin hyödyntävät designia, kasvattavat liikevaihtoaan ja omistaja-arvoaan miltei kaksinkertaisesti verrokkiyrityksiin verrattuna. Tutkimukseen osallistui 300 pörssiyritystä 5 vuoden ajalta useista maista ja teollisuudenaloilta, kulutustavaroista lääketieteelliseen teknologiaan ja pankkipalveluihin. Esimerkiksi nämä mainitut hyödyt jäävät saavuttamatta, jos design-työtä ei ole järkevästi integroitu yrityksessä käytettävään ketterään toimintamalliin.

Päätimme koota ja jakaa tässä niitä parhaita käytäntöjä, joiden olemme havainneet toimivan, kun suuremman organisaation ketterässä toimintamallissa työskentelee palvelumuotoilijoita, UX/UI designereita ja käyttäjätutkijoita.

Keskitymme SAFeen, koska se on käytetyin suurten organisaatioiden ketterä toimintamalli. SAFe julkistettiin vuonna 2011 ja vasta sen versioon 5 vuonna 2020 tuli mukaan design, paketoituna Design Thinking -otsikon alle. SAFea on kuitenkin sen jälkeenkin toistuvasti kritisoitu käyttäjäkeskeisen näkökulman unohtamisesta. 

Toivommekin, että seuraavat vinkit antaa sinulle välineitä organisaatiosi toimintamallin kehittämiseksi!

Esimerkkejä mitattavista avaintuloksista design-ympäristössä:

1. Jos design-tiimissänne on DesignOps-vastaava, hänen tulisi perehtyä yrityksessänne käytettävään ketterään toimintamalliin, oli se SAFe, tai jokin muu. Design-työn integroiminen fiksulla tavalla tuoteomistajien ja kehittäjien työhön edellyttää heidän käyttämänsä toimintamallin tuntemista. SAFe:n roolit, vastuut, tuotekehityksen vaiheistus ja toimintamallin kokonaiskuva tulisi siis olla design-operaatioiden kehittämisestä vastaavalla henkilöllä hallussa, jotta hän voi muotoilla designin tehokkaaksi osaksi kokonaisuutta.
2. SAFe kuten muutkin ketterät mallit ja tuotekehitysprosessit rakentuvat toistettavien rutiinien ympärille. Samalla periaatteella design-tekeminen tulisi systematisoida läpi organisaation. Jos yksittäiset designerit tai design-projektit noudattavat eri toimintamalleja, yhteistyö yhtenäistä ketterää toimintamallia noudattavien kehittäjien ja tuoteomistajien kanssa on vaikeaa.
3. Design tulisi olla integroitu yrityksen tuotekehityksen kaikkiin prosesseihin, sopivassa määrin tuotteen elinkaaren eri vaiheet huomioiden. SAFe ei tarjoa tähän yksikäsitteistä ohjenuoraa, vaan kyseiset toimintatavat tulee rakentaa sen rinnalle ja SAFen ketterä malli kytketään tukemaan jo mahdollisesti systematisoitua design-toimintaa. Jos design-työn ohjaaminen jätetään SAFe-viitekehyksen varaan, päädytään tilanteeseen, jossa design-työn tarvetta arvioidaan jälkijättöisesti PI-jaksojen alussa tai sprinttien jo ollessa käynnissä. Tämä johtaa reaktiiviseen malliin, jossa design-työtä ei kyetä johtamaan, suunnittelemaan tai ennakoimaan. 
4. Designerien tulee tehdä yhteistyötä tuoteomistajien kanssa asiakkaiden ja käyttäjien tarpeiden selvittämiseksi. Eri organisaatiokulttuureissa tämä vastuunjako tai omistajuus on usein ratkaistu eri tavoin, mutta yhteisesti sovittu toimintamalli ja relevanttien käyttäjätutkimuksen menetelmien käyttö varmistavat, että organisaatio saa työnsä pohjaksi käyttäjätarinoita (user stories) jotka kuvaavat riittävästi ja kattavasti käyttäjien tarpeet. Design kannattaa ottaa mukaan asiakasrajapintaan ja käyttäjätarpeiden määrittelyyn jo ennen tuotekehitysprosessin käynnistymistä. 
5. Käyttökokemuksen suunnittelun aktiviteetit tulee olla mukana backlogeissa. Nämä tehtävät tulee priorisoida niiden merkityksen ja vaikuttavuuden mukaisesti. Jos design-tekemistä ei ole mainittu backlogeissa, se harvoin tulee huomioiduksi riittävän aikaisessa vaiheessa tai riittävällä intensiteetillä.
6. Design-työn vaikuttavuuden maksimoimiseksi designereille tulee taata mahdollisuus tehdä työtään relevanttien muiden tiimien ja roolien kanssa. SAFe-tiimitasolla UX designerin tulee tehdä läheistä ja päivittäistä yhteistyötä uusia ominaisuuksia toteuttavien kehitystiimien kanssa. Käyttäjätutkija tai käytettävyystestaaja voi tukea tätä työtä tarpeen mukaan, mutta usein yksittäinen kehitystiimi ei tarvitse pitkäaikaisesti omaa täyspäiväistä käyttäjätutkijaa. Informaatioarkkitehtuurin suunnittelu tulisi integroida ketterään kehitysjunaan (Agile Release Train, ART). Samaten käyttäjätutkimussuunnitelmaa tulisi luoda, ylläpitää ja toteuttaa ketterien kehitysjunien Planning Interval (PI) -suunnitteluvaiheessa. SAFe-portfolio-tasolla tulisi portfolio-tiimissä olla mukana UX-strategisti/arkkitehti tai kokonaisuuden hallitseva lead designer.
7. Puhtaassa SAFe-mallissa ei ole projektipäälliköitä tai program managereita, vaan tekeminen sykkii product management governancen tahtiin. Release Train Engineer on kuin suuremman kokonaisuuden scrum master eikä delivery manager. Jos näitä roolituksia ei ole yhteisesti sovittu organisaatiossa, design-työnkin tekeminen palaa helposti jonkinlaiseen ketterään vesiputousmalliin. Prioriteetit ja käytännöt menevät ristiin, jos odotukset designereiden työlle tulevat samanaikaisesti vanhan mallin mukaisesti projektipäälliköltä ja uuden ketterän mallin mukaisesti tuotepäälliköiltä.‍
8. SAFe-mallin noudattaminen ei poista ihmiskeskeisen suunnittelun tarvetta. Käyttäjätutkimus, informaatioarkkitehtuurin suunnittelu, designin prototypointi, käyttäjätestaus ja käyttäjäpalautteen kerääminen on edelleen hyödyllistä ja välttämätöntä.

‍

Alpha Design Partnersin DesignOps-osaajat ovat apunasi, kun haluat yhdistää design-tekemisen organisaatiosi ketterän kehittämisen malliin.

‍Ota meihin yhteyttä jos haluat puhua aiheesta lisää!

‍