Vad kan vi sluta med när vi blir mer agila?

1. Statusmöten/synkmöten

Utöver de vanliga scrumaktiviteterna så brukar bolag ofta ha ett antal andra möten. Några exempel som jag stött på är:

  • Morgonstatusmöten för alla som jobbar med operations (från olika team)
  • En extrademo för kunder – eftersom de inte är intresserade av alla detaljer som tas upp på Review
  • Projektmöten som handlar om att en projektledare känner att de behöver få status från flera team i ett projekt
  • Postmortemmöten i slutet av ett projekt för att förbättra sig inför nästa projekt

Tanken är såklart god i de flesta fall. En chef eller projektledare kanske vill veta hur det går för teamen och det är väl bra att reflektera över tiden som gått? Absolut och smidigt nog täcks flera av dessa syften uppfylls av aktiviteterna i Scrum, vilket gör att vi kan spara in litet tid!

En Review är till för att alla intressenter ska få samma information, likvärdig möjlighet att lämna feedback samt se det nuvarande systemet i så realistisk form som möjligt. Om detta görs på rätt sätt så kommer det att skapa en samsyn om var systemet är på väg och dialogerna kan vara väldigt givande för teamet såväl som intressenter, externa kunder och faktiska användare. Det är också det främsta tillfället för teamet att få värdefull feedback och riktning inför framtiden.

Daily scrum är en aktivitet som är till för att ett scrumteam ska kunna arbeta tillsammans, att maximalt synka de närmsta 24 timmar och att kunna förändra sina planer minst en gång per dag.

Retrospective är till för att ett team ska kunna utvärdera sättet de arbetar på och tillsammans hitta förbättringsförslag som de själva genomför under nästkommande sprint.

Det bästa med dessa aktiviteter är att de är regelbundet återkommande, involverar precis de personerna som är nödvändiga för att genomföra förändringar och ger en stadig nivå av synkronisering i organisationen.

Om det uppfattas att vi behöver stanna upp och fundera oftare eller det efterfrågas fler tillfällen att ge feedback, försök då i första hand korta ned sprintarnas längd. Varje nytt möte drar fokus och hindrar flow från teamet, vilket i längden skadar produkten. Utöver detta så talar vi ofta om korsfunktionella team, vilket innebär att all kompetens som krävs för skapa produkten – från idé till validerad produkt – finns i teamet (d.v.s. en fungerande programvara som används av riktiga användare som bekräftar att systemet uppfyller sina syften). Det här tar bort de flesta behoven av överlämningsmöten och möjliggör fantastiska innovationsmöjligheter!

2. Förstudier

Trots ett välfungerande flöde där scrumteamet gör ett bra utforskande arbete, har direktkontakt med kunder, gör användartester och dagligen analyserar hur användarna använder systemet, så förekommer det ibland en grupp som genomför projektförstudier eller förplanering. De brukar ha i uppdrag att bereda user stories eller i värsta fall hela projekt till ”linjeorganisationen”. Den här gruppen består ofta av seniora business analysts som påstås kunna systemet efter att ha arbetat med detta i ett antal år. Det perspektivet som dock ofta saknas i de sammanhangen är den nuvarande användningen av systemet och hur det är konstruerat (som i en teambaserad organisation finns hos teamen om de har end-to-end-ansvar).

I agila kretsar talas det ofta om att skjuta besluten dit kunskapen finns. I Scrum finns exempelvis förfining eller Refinement, vilket innebär att teamet försöker reda ut vad som bör göras, hur det ska genomföras i produkten och hur det ska valideras. Det beskrivs som att ett team ska lägga maximalt 10% av sin tid på detta och de bör självklart ta hjälp från de personer i organisationen vet mest om varje given del. Ett sätt att fortfarande få med kunskapen hos de seniora är att bjuda in dessa personer till Refinementsessioner, eller ännu bättre låt dem arbeta tillsammans med teamet med produkten och dela med sig av sina kunskaper till resten av teamet.

3. Detaljerad dokumentation

Ett scrumteam genomför sprint på sprint och producerar högkvalitativ mjukvara som är mycket omtyckt av användarna. På varje sprint review så kommer en stakeholder och kommenterar att hen verkligen gillar produktinkrementet men måste ändå fråga om kravet på dokumentation är uppfyllt. En utförlig dokumentation var väldigt viktigt i en klassisk organisation eftersom en av de stora riskerna var att bara en person förstod hur en given del av ett system fungerade, om denne av någon anledning var sjuk eller slutade, så gick det inte att lösa något problem i systemet. Det var också vanligt att teamet lämnade över systemet till exempelvis en operationsavdelning när produkten var färdig.

I ett välfungerande scrumteam sitter däremot kunskapen i själva teamet. Alla behöver inte kunna allt, men de har arbetat tillsammans för att ta fram arkitektur på systemet och sättet att utveckla det på. De parprogrammerar, eller till och med mobprogrammerar, ofta för att skapa en högkvalitativ och lättrörlig användarupplevelse. De skriver dessutom koden på ett sätt som i sig är självdokumenterande, med automatiska tester som är baserade på riktiga användarfall. På det sättet går det lätt att koppla ett givet användarscenario som inte fungerar som det ska, till en del i koden som går att modifiera och bygga ut. Om en av dem försvinner så kommer det fortfarande att skada teamets förmåga att leverera ny funktionalitet och det skadar framförallt deras gruppdynamik, men kunskapen går att återskapa snabbt. Dessutom har de sparat in väldigt mycket tid på att inte skriva dokument till sig själva, som dessutom ofta är svårare att förstå än själva koden och, enligt min erfarenhet, aldrig används. Risken med att hela teamet försvinner är ju dock fortfarande ett problem, men om vi tänker ur ett riskperspektiv, om ett helt team försvinner samtidigt så har organisationen betydligt större problem än att ett av systemen är dåligt dokumenterade.

4. Skriva ned och rita upp processer

Med klassisk utvecklingsmetodik så är det ofta väldigt viktigt att teckna ned i olika modeller och visualiseringar hur det är tänkt att alla ska arbeta så att alla gör på samma sätt och alla vet sin exakta plats inom organisationen. Ofta fanns det till och med specifika personer som hade i ansvar att måla upp dessa modeller och visa upp dem för alla inom organisationen på processmöten. Det är inte helt ovanligt med organisationer som inför en ”litet modifierad” version av Scrum som en standardprocess i sin organisation.

Till att börja med är det viktigt att förklara att Scrum i sig inte är en process utan ett ramverk utifrån vilken teamen själva kan utveckla och kontinuerligt förbättra sitt sätt att arbeta. Från den synvinkeln blir det väldigt underligt att ha en standardprocess, då hela idén med ramverket är att anpassa sättet att arbeta utifrån förutsättningarna. Att dessutom ständigt nedteckna och uppdatera modeller på processen kan aktivt hämma de kontinuerliga förbättringarna, eftersom det kan ses som för mycket jobb och byråkrati att ändra på någonting och därmed finns en risk att innovation och utvecklingsarbetet stannar av. Team som ständigt funderar och utvecklar sina arbetsmetoder har inte speciellt mycket nytta av att ha en modell i en Powerpoint eller på ett papper eftersom de ändå ständigt kommunicerar inom och kring den. Men kan modellerna inte ha någon nytta vid kunskapsspridning mellan team eller när vi ska starta upp ett nytt team då? Jo visst, låt då det ansvariga teamet tillsammans stå och måla på en whiteboard och diskutera för och nackdelar med olika metoder, det kommer att föra över mycket mer kunskap än en fint ihopsatt Powerpoint skickad över mail.

5. Tidsrapportering

I en organisation som ser människor som en resurs som är utbytbar mot pengar så är det ju viktigt att följa upp så att maximalt arbete är utkrävt för de pengarna som är spenderade. I en projektorganisation är det också nödvändigt att veta vilka timmar en arbetare lagt på vilket projekt eftersom deras löner finansieras av projektens budgetar. Problemet med de här tankegångarna är att det inte betraktar komplexiteten i arbetet med att utveckla mjukvara, en timme framför datorn skrivande kod kan vara helt meningslös (eller till och med skadlig) eftersom den inte löser rätt problem eller löser det på ett sätt som är rätt för just den användaren som behöver den, samtidigt som all kod gör kodbasen större och mer komplex. Däremot kan en tvåminuters diskussion mellan en utvecklare och en användare ge insikter som leder till en helt ny inriktning på produkten som drar in miljoner till bolaget. Dessutom kan en kontrollerande ledarstil med starka regler, som inte upplevs som motiverade, medföra en kultur av att reglerna egentligen inte spelar någon roll eftersom de ändå inte följs.

Den agila principen som skapar arbetsvilja, lojalitet mot bolaget och ”kontrollerar” så att alla medarbetare arbetar som de ska kallas transparens. Eftersom arbetet sker inom ett team och teamets resultat tillsammans är det som är viktigt i en organisation så kommer ett självorganiserande team att hjälpa varandra och ställa krav på varandra att samarbeta och leverera det bästa möjliga resultatet. Det är betydligt svårare att i en agil organisation gömma sig och inte genomföra något värdefullt, än det är i ett projektteam på hundra personer där inte alla känner varandra, men tidsrapporteringsverktyget är väldigt detaljerat. I en litet agilare organisation så finns inte heller någon matrisorganisation med projekt som finansierar en linje som utför arbetet, utan samtliga pengar kommer från samma håll, det möjliggör tydligare direktiv och entydiga mål för organisationen. Istället är grupperingarna uppdelade efter värdeströmmar och produkter.

6. Releaseplanering

När vi talar om klassisk utrullning av ny funktionalitet i ett befintligt system så brukar det ofta innefatta ett antal koordinerande roller för att samordna samtliga projekt med tillhörande möten. I större organisationer brukar det också involvera att lägga in alla förändringar på produkten i en gemensam miljö och testa förändringarna tillsammans för första gången. Det kan också innebära att utbilda användargrupper eftersom systemet i stort sett är ett nytt system efter alla förbättringar som skett det senaste kvartalet, halvåret eller året sedan den senaste versionen släpptes. Det är också ofta ett stort arbete med att samordna systemansvariga och servicefönster för att ingen verksamhet ska störas.

I den agila världen talar vi ofta om DevOps, d.v.s. att de som ser till att användaren får tillgång till funktionen, testar den och utvecklar den, samtliga är med i samma team. Det minskar behovet av synkmöten (se punkt 1). Sedan innebär ju agilitet i praktiken också att vi kan släppa små förändringar snabbare (enligt Scrum ska det finnas ett potentiellt releasebart inkrement helt färdigt efter varje sprint), system som utvecklas i små inkrement kräver inte heller utbildning eller stora manualer utan användare känner oftast fortfarande igen sig och vänjer sig fort vid varje småförändring. Det är så de flesta mobilappar utvecklas idag. Till sist så bör flera team som arbetar på samma produkt så tidigt som möjligt integrera sina inkrement med varandra och validera (gärna automatiserat) att de funkar tillsammans. På så sätt undviks buggar och ibland att hela arkitekturen måste ses över på grund av nyupptäckta förutsättningar. Ju tidigare i ett utvecklingsskede sådant upptäcks desto bättre för kvalitén. Ett sätt att organisera sig runt integration av en produkt mellan flera team är Nexus.

7. Regressionstestning

En klassisk regressionstestning innebar att ha en testare eller testavdelning som använder samtliga av systemets funktioner utifrån specifikationsdokumenten. Detta görs oftast inför en release och har som syfte att se till att alla kraven på systemet är uppfyllda. Vid de tillfällen som ett system redan finns i produktion så är det naturligtvis viktigt att se till att all den nuvarande funktionaliteten fortfarande fungerar, även när det nya inkrementet läggs till.

I en mer agil organisation så har vi dock automatiserat tester som åtminstone testar de viktigaste användningsområdena för systemet, ändå är det många organisationer som aldrig riktigt kommer till punkten att de slutar att manuellt testa igenom systemet. Ofta beror det på att vi inte riktigt litar eller förstår hur vältäckande testerna är eller att vi helt enkelt har personer eller avdelningar som idag gör detta som sin huvudsakliga uppgift. Om dessa människor istället kunde lägga tid på att skriva automatiska tester med hjälp av sin testexpertis, arbeta utforskande, prata med användare och analysera användardata, så hade hela teamet kunnat använda de resultaten för att kunna skapa ännu bättre kvalitet i systemet och dessutom stabilt kunna repetera alla testen utan att vara beroende av en persons expertis och tid.

Till sist

Självklart är jag själv inte färdig med min agila resa utan letar ständigt efter mer administration som vi borde sluta upp med. Om du har kommit på några fler exempel, hör gärna av dig till mig så kan vi prata vidare!

Gilla och dela gärna det här inlägget:

augusti 20, 2018



LinkedIn
Facebook
Facebook
Instagram
Follow by Email