100% av teamet i en mobb i 12 månader — att ta mobbprogrammering ett par steg längre.

En Guide i mobbutveckling, vinster och utmaningar.

Att jobba nära som team med 100 % förståelse för uppgiften och ett gemensamt ansvar för att nå målet är den stora vinsten.

I 12 månader har jag nu varit UX designer/researcher i en mobb på 6 personer som jobbar med digitala tjänster för framförallt SVT Sport. (Och innan dess 18 månader på Bonnier News i ett mobbprogrammerande team, men då satt jag sällan i själva ”mobben”.) Mitt nuvarande team mobbar allt från utforskade (discovery) till leverans (delivery). Det har varit ett år av utmaningar, med snudd på identitetskris stundtals, och framförallt den mest utvecklande arbetsform jag varit med om hittills.

Så hur har året varit? Det här inlägget handlar om att dela med mig av mina erfarenheter. Alla vinster liksom allt det svåra och hur teamet tacklar det. Vår verktygslåda!


Friskrivning: detta är inte facit, bara hur vi gör. Och helt utifrån mitt design-perspektiv, utifrån mina erfarenhet och olika team jag jobbat i, med eller utan mobbprogrammering. En högst personlig reflektion.


Vad är en mobb?

I korta drag består en mobb av tre eller fler vanligtvis utvecklare (i vårt fall även UX designer, produktägare och testare, plus en och annan ”gäst”) som jobbar på ett och samma problem samtidigt, på samma dator. “Mobben” roterar och vi turas om att vara ”driver” (ungefär som en sekreterare) i fasta intervall. I vårt fall rotationer om 10 minuter. Alla utom ”drivern” tänker och navigerar i lösningar på problemet och kallas för ”navigators”. De fungerar som ”hjärnor” medan sekreteraren ”utför”.
“Mob programming is a software development approach where (all the brilliant minds working on/) the whole team works on the same thing, at the same time, in the same space, and at the same computer.”
– Woody Zuill, mobbprogrammeringens grundare
NAVIGATORS, experter som navigerar i lösningar och fungerar som “hjärnor” medan DRIVERN, “sekreteraren” utför. KOMPETENSER: Utvecklare • UX Designer • Testare • Produktägare • plus gästexpert.

När mobbprogrammering blev mobbutveckling

På SVT interaktiva, är vi många team som jobbar i mobb. Vi i Sport-teamet är det första teamet som jobbar 100% i mobb och mobbar annat än kod. Vi har helt enkelt tagit mobbprogrammering ett eller fler steg längre. Sport-teamet mobbar alla delar i vårt uppdrag, dvs både discovery (utforska) och delivery (leverera, bygga) — från antaganden till hypotes, utforskande faser, design, implementering och test.

Vi kan göra det här eftersom hela teamet är en enda stor mobb med många kompetenser — produktägare, UX designer (jag), utvecklare och testare.

Varför mobba mer än kod? Vad är det för problem vi försöker lösa?

Att ha hela teamets kompetenser i mobben innebär i korthet att du kan ta an mer komplexa uppgifter utan ledtider. Kompetensen finns hela tiden närvarande. Alltid redo att svara eller agera. Inga överlämningar behövs mellan kompetenser, vilket för mig som UX designer alltid tidigare varit den mest frustrerande delen. Förväntningar blir tydliga när alla är med hela vägen. Den första spontana reaktionen efter att jobbat i mobb är en känsla av 100% förståelse för problemet eller uppgiften vi jobbar med. Mobben främjar samarbete. Det är inte jag som löst det här det är vi.

Sportteamet mobbar allt — från utforskande till leverans.

Kortfakta om oss i Sportteamet och vårt uppdrag

Vad gör vi? Jobbar med SVT Sporttjänster på digitala plattformar.

Teambakgrund? Vi rekryterades som ett team med starka önskemål på att jobba i mobb som arbetssätt och utifrån Lean UX som arbetsmetod. För att komma igång hade vi en riktigt bra coach.

Vårt uppdrag? Vårt initiala uppdrag var att flytta hem SVT Sport (som tidigare utvecklades externt). Vi fick stor frihet och support i hur vi skulle ta oss an ”vårt uppdrag”. Efter ett par månaders målgruppsarbete, strategiskt arbete och andra utforskande uppgifter hade vi tillräckligt för att sätta upp målet vi sedan jobbade efter: “Nyheter och Sport — En tjänst, en upplevelse”. Det innebar att Sport och Nyheter till skillnad från tidigare skulle närma sig varandra och följa våra användarbehov och samtidigt inte stå i konflikt med organisationsmål, eller andra teams uppdrag. “Sporten” flyttade hem till SVT.se lagom till fotbolls-VM 2018. (Ett skifte som gick över all förväntan, nästan obehagligt smärtfritt.)
Team SVT Sport 2018 💙

Så vilka fördelar har teamet med mobbutveckling som arbetssätt?

När alla i teamet vet och förstår hur våra bidrag påverkar slutprodukten skapar vi bättre produkter. Så länge arbetet är meningsfullt bryr vi oss om resultatet. Att förstå hur våra bidrag har betydelse är centralt. Att t.ex se hur en användare använder slutprodukten oavsett roll i teamet blir viktigt för att göra ett bättre jobb. Ett resultat av att alla kompetenser jobbar i alla delar.

  1. 100 % förståelse i teamet för problemet/uppgiften. 
    Alla har fokus på målet och uppgiften, och kan ta beslut som tar oss dit. Inga exakta kravspecar behövs längre. Kunskapen finns i mobben.
  2. Engagemang längst hela processen och förståelse för varför vi väljer ett visst spår eller lösning. 
    Bra produkter är gjorda av människor som bryr sig.
  3. Lättare att hålla fokus på en, ”rätt”, sak i taget. 
    Det hjälper oss att hålla riktning. Färre irrelevanta sidospår. Vi blir bättre på att prioritera bort onödigt fluff, eller sådant som inte har högsta prioritet. Inget onödigt pillande...
  4. Mindre förklarande och färre missförstånd när teamet är med hela vägen och själva träffar användare. 
    Alla får förståelse för problemet vi ska lösa. Utifrån ett UX-perspektiv är det här en stor lättnad och innebär mycket mindre frustration. Jag kan lita på teamet.
  5. Större möjligheter att påverka slutresultatet.
    När du ingår i mobben kan du skapa förtroende genom att intressera dig och förstå andra kompetensområden. Det gör det enklare att påverka och ifrågasätta (t.ex. ”hur löser det här problemet”, ”hur tar detta oss närmare målet” etc).
  6. Ingen i teamet blir helt “oumbärlig” när vi lär oss av varandra. 
    Mobben kan fortsätta även när alla inte är på plats. Åtminstone ett tag.
  7. Färre överraskningar längs med vägen när alla kompetenser varit med i beslut som vi tar längs vägen. 
    Det är lättare att undvika orealistiska specar från designers till utvecklare eller krav från organisationen på funktioner som användare inte visar sig vilja ha. Eller utvecklare som bygger lösningar som är svåra att förvalta eller vidareutveckla.
  8. Inget blockerar vägen framåt inom det egna teamet när vi alla jobbar på en och samma uppgift i taget. 
    Vi behöver inte vänta. Givetvis kan vi fortfarande blockeras av beslut som behöver tas i organisationen, andra krav eller andra team.
  9. Kompetensutvecklande. 
    Vi delar med oss och lär av varandra.
  10. Onboarding av nya eller externa kompetenser.
    Att rotera in nya i teamet, tillfälliga gäster eller experter, i mobben är omedelbar. Genom att sitta med några rotationer så lär du dig och långa förklaringar behövs sällan.

Några saker som hjälpt oss på vägen

Nytt rekryterat team, med stöd från närmaste intressenter. Vi var ett helt nytt team när vi började mobbutveckla. Vi hade inget att jämföra med eller något bekvämt invant mönster att falla tillbaka på. Att testa mobbutveckling kom från våra närmaste intressenter och vi behövde aldrig försvara vårt arbetssätt. Det låg i allas intresse att våga utvärdera detta till 100 %.

Prestigelöshet i teamet. Utan detta blir det svårt. Vi utvecklar tillsammans och bygger på varandras idéer. Därför finns det ingen tydlig gräns mellan mitt och ditt. Alla äger idéen, lösningen och resultatet.

Gemensamma drivkrafter och motivation. Under diverse teamövningar (bl.a. moving motivations) vi gjort tillsammans med vår coach har det visat sig att vi motiveras och drivs av lika saker. Det här är teamet som värderar nyfikenhet högst och ära lägst. Teamrekrytering och teamsammansättning blir viktig och förmodligen ännu viktigare i en mobb.

Teamöverenskommelse. Ett måste för varje team för att veta vad som gäller och är viktigt. Något som är konkret och kan ifrågasättas. Inte minst av nya teammedlemmar.

Vår egen team-coach. Coach, Martin Christensen, hjälpte oss förverkliga oss som team 💙

Alla i teamet är “UX:are”. Som UX experten i teamet faciliterar jag mer än ägnar mig åt designdetaljer.

Metoder och processer. Vi använder en mix av metoder för att ta reda på Vad vi ska bygga, för vem och varför. De som färgar oss mest är att vi jobbar utifrån Balanced Team för att ta beslut i teamet och Lean UX för att hålla riktning i det vi jobbar med.

Heldag med Woody Zuill. Att få lära sig av mästaren själv, mobbprogrameringens grundare, gjorde det betydligt mer konkret och spännande.


Viktigaste prylarna i mobben

1.Gemensam mobb-dator, 2. stor skärm (65″), 3.Mobb-klocka (för att hålla tiden), 4.Whiteboards, 5.Klassisk pekpinne (laserpekare fungerar inte på vår tv-skärm), 6.högtalartelefon (för distansarbete).

Utmaningar i mobben — en guide i hur vi hanterar dem

Nära samarbete ställer andra typer av krav på teammedlemmar i mobben. Det går inte gömma sig för konflikter…

Utmaning: olika viljor och idéer

Att hantera olika viljor, lyssna och kompromissa.
Teamprocesser och kommunikation blir viktiga för att mobbutveckling ska fungera. Mobb innebär fler interaktioner med varandra i teamet. För att hantera alla interaktioner och nära samarbete använder vi Core Protocols, ett kommunikationsverktyg för att bl. a. hålla fokus, öka självmedvetenheten, ta beslut och för att bli bättre på att ta in vad andra i teamet säger (positive bias).

Teamöverenskommelser att luta sig mot. Konkret och kan ifrågasättas. Inte minst av nya teammedlemmar.

Utmaning: Hålla fokus

Det är lätt hänt att hamna i evighetsdiskussioner, försöka hitta den perfekta lösningen eller zone out när vi är många. Ju fler kockar desto sämre soppa…

Mobb-rotationer i 10-minuters intervall. Vi är strikta med att rotera i mobben. När vi glömmer att rotera och en och samma person sitter kvar vid tangentbordet (och ofta då fastnat i rollen som både driver och navigator) dyker fokus och engagemanget snabbt i mobben. Vi håller koll på tiden med hjälp av vår mobb-klocka. Och för snabba byten vid rotationen har vi en gemensam mobb-dator.

De ”regler” som vi framförallt klänger oss fast vid är just mobb-rotation och att alla ska delta i mobben även om alla inte gör det på heltid. Jag kan t.ex. förbereda vissa user research-delar utanför mobben.

Mobb-regler. Vi har kommit överens om några mobb-regler. Dessa fungerar lite som teamöverenskommelser men för mobben.

Teamets mobbregler.

Dagsretro. Vi har ingen standup (utom en kort check-in för att veta om någon kommer vara på möten eller gå tidigt) eftersom hela teamet jobbar med samma problem och gemensamma mål. Istället har vi en kort dagligt retro där vi ställer oss tre frågor:
1) Tar vi oss närmare målet? 2.) Oavsett, gör vi rätt saker? 3.) Hur går vi vidare i loopen?

Good enough for now, safe enough to try. Testa istället för att försöka diskutera fram “bästa” lösningen.

Time-boxa diskussioner. Särskilt som nytt team i början hade vi en tendens att hamna i långa (utmattande) diskussioner kring vilken väg vi skulle ta. Vi hade inte anammat Good enough, safe to try utan försökte diskutera oss till bästa vägen istället för att testa. Teamet är nu mer självmedvetet. Vi vet att vi måste tidsbegränsa våra diskussioner, alternativt parkera dem om de inte är direkt relevanta just nu.

Utmaning: Gemensam förståelse

Vad håller vi på med? Vart är vi påväg?

Att lära sig av varandras expertkunskaper. Att vara utanför sin ”comfort zone” och känna engagemang även för det som ligger utanför ens expertis.

Visualisera. Visualisering av koncept, idéer och lösningsförslag blir viktig för att kunna förklara för alla i mobben, så att alla hänger med på vart vi är och på väg. Ofta på en whiteboard.

Hög abstraktionsnivå. När vi kodar håller vi oss på en hög abstraktionsnivå. Navigatorn behöver formulera vad hen vill åstadkomma till hela mobben, mer än bara exakta kommandon till drivern. Det gör att andra i mobben kan vidareutveckla en idé, tidigt komma på eventuella risker eller problem med ett förslag. Dessutom kan jag som designer med bristande kodsyntaxkunskaper förstå och bidra.

Lean UX som arbetsmetod: Hjälper oss navigera mot målet.

Utmaning: Delat ansvar blir ingens ansvar

Fortfarande en utmaning i skrivande stund.

Guardians. Vi är bra på att dela ansvar när det kommer till teamprocesser och arbetsprocesser. Andra saker som ska göras som ligger utanför mobben är svårare. Åtgärder som kommer från retrospektive tilldelas en Guardian (väktare) som ansvarar för att följa upp. Funkar oftast…

Utmaning: Ego och kontrollbehov

Våga släppa kontroll över design och få kontroll på helheten.

Facilitera framför detaljstyre. Och vad kan jag göra nu när jag inte behöver detaljkolla implementering, när teamet är självgående och fokuserat på mål och användbarhet? Semester? Jag har behövt omvärdera min roll. Nu är min roll mer faciliterande. Det blir mer utrymme för user research, bättre UX-strategi och innovation som ger värde och känns meningsfull. Men till och från får jag fortfarande kämpa med osäkerhet kring vad min roll i teamet är. (Ja, det är enklare att leverera konkreta design-skisser till ett team, där få ifrågasätter, än att behöva argumentera och ta in input från utvecklare i en mobb…)

Utmaning: Vidareutveckling inom sitt expertområde

Att känna att jag tillför något i mobben när vi gör delar som är långt ifrån mitt område. Hinner jag lära mig dessa områden också och samtidigt hålla expertnivå på egna området?

Tid för fördjupning utanför mobben. För att upprätthålla ett UX-perspektiv behöver jag fortfarande kunna fördjupa mig inom mitt expertområde. Att det inte blir urvattnat. Det blir inte mindre viktigt att hålla sig uppdaterad inom sitt expertisområde för att kunna bidra i mobben. (Och mobben möjliggör denna tid men det är mitt ansvar att ta den.)

Utmaning: Motivation.

Att känna motivation även under perioder då vi inte jobbar inom “mitt” område.

Agil UXatt jobba i små vattenfall mellan discovery och delivery. Att försöka jobba i korta iterationer så att du aldrig är för länge utanför det som motiverar dig mest.

Egen tid. Det svåraste med mobb. Mobb som arbetssätt passar inte alla och viktigt att vara medveten om. För att veta om det fungerar behöver teamet ge det en är ärlig chans, en period att utvärdera, precis som med alla arbetssätt. Du vet inte förrän du testat! Och fungerar inte mobbande på heltid för alla i teamet så skapa ett mer flexibelt mobbande. Gör det som fungerar bra ännu mer. “Turn up the good” som Woody Zuill skulle sagt.


Och det viktigaste…

Mobben skapar mod att våga innovera och utveckla tillsammans… och ser till att du alltid är fokuserad på vad som är viktigt. Mobb är delat ansvar, misslyckanden och framgångar 💙