Åbenhed for forandring er en forudsætning for ”Agile Transition” (billede fra Julia Lingertat)

Sådan bliver du smidig - En agenturets vejledning

Oprettelse af ideelle betingelser for agile klientprojekter

Denne artikel er også tilgængelig på tysk.

I løbet af de sidste par år er "agile" blevet et stadig mere populært buzzword i agenturets scene. Der er næppe et enkelt firma, der ikke siger at arbejde smidigt. Men hvad betyder det egentlig? Hvordan kan man fortælle, hvor agile en virksomhed virkelig er? Hvis man arbejder i sprints, betyder det, at man allerede er smidig? (Svar: nej.)

Hos Aperto Move har vi konstant analyseret og forfinet vores arbejdsmetoder i de sidste to og et halvt år og skubbet vores vision om agile på arbejdspladsen fremad. En af de mest ubestridelige erkendelser har været, at overgangen til smidig kræver både tid og erfaring. Man kan ikke bare skifte til agile. Selvom vi endnu ikke er der, hvor vi gerne vil være, ses forbedringerne tydeligt.

At anvende agile metoder i et agentur er alt sammen vanskeligere end for eksempel inden for produktudvikling; da man opretter produkter til forskellige klienter, hvor forholdene kan variere drastisk mellem projekter. Derfor er det svært at tro, at ethvert agentur pludselig ser ud til at være smidigt. Heldigvis er der faktorer, der let kan hjælpe med at afgøre, hvor langt en virksomhed er kommet på vej til at blive smidig.

Rådgivningen præsenteret i denne artikel er baseret på scenarier, der er fælles for de fleste agenturer, som er opstået i vores daglige arbejde og blev løst, når vi først identificerede dem som problemer. De er ingen løsninger, der helbreder alt, men snarere en samling af erfaringer, der fungerer bedst for os.

1. Afklar terminologien

Når man introducerer smidig, er det vigtigt, at alle i virksomheden har den samme forståelse af udtrykket, ellers risikerer man farlig miskommunikation. Jeg har stødt på mennesker, der fejler den smidige tilgang, da de forlader alle konceptfaser, planlægning og regelmæssige møder til fordel for at kaste sig direkte ind i et projekt og se, hvad der sker. Det er ikke svært at forestille sig, at et sådant projekt var andet end let at gå.

Andre har simpelthen hørt om “Scrum” og har en vis modvilje mod det og afviser det som “noget for udviklere”, der kvæler den kreative proces. For det meste kommer disse udsagn fra mennesker, der ikke selv har udforsket Scrum eller agile metoder. Derudover kan de, der ikke er bekendt med det, ofte ikke fortælle forskellen mellem agile og Scrum og klassificere dem som en og samme.

Skrum og agile er ikke det samme

Scrum er en ramme, der definerer specifikke regler, roller og arbejdsprocesser til udvikling af software. Et eksempel er definitionen af ​​tidsintervaller, hvor et arbejdsprodukt leveres (såkaldte sprints). Implementeringen af ​​Scrum bidrager til smidig softwareudvikling, og derfor ses betingelserne ofte som synonyme, men det er de ikke.

”Agile” er på den anden side en måde at tænke eller kultur på, som indkapsler meget mere end rent hvad Scrum gør. Principperne, der definerer den agile kultur, er angivet i Agile Manifesto og er afbildet i følgende video:

Scrum er kun en mulig tilgang til at følge de smidige principper. Man kan også være smidig uden at bruge Scrum. På den anden side betyder det ikke bare, at man overholder reglerne i Scrum, at man faktisk arbejder smidig.

2. Farvel med projektlederrollen (hilsen til agile roller)

I Scrum defineres følgende roller:

  • Produkt ejer
  • Scrum Master
  • Udviklingshold
  • Yderligere interessenter, såsom slutbrugeren eller de involverede på klientsiden

Der er ingen andre roller, og de er heller ikke nødvendige. Den klassiske projektleder er ikke længere påkrævet i denne opsætning. Han ville kun hindre processen, da alle opgaver, der tidligere var udført af projektlederen, nu er dækket af positionerne ovenfor. Ansvaret for projektets succes hviler ikke længere på én person, men snarere på hele teamet.

Hver ekstra rolle, der findes i projektet - og står mellem Scrum-teamet og klienten - er en hindring for den direkte og effektive kommunikation mellem teamet og klienten.

Tag roller og ansvar alvorligt

Hvis man ikke har brug for en projektleder, ville det da ikke være fornuftigt at ansætte tidligere projektledere i en kombineret rolle som Scrum Master og produktejer?

Nej. På den ene side indebærer både Scrum Master- og produktejerrollerne nok opgaver til at udføre begge vil resultere i forsømmelse af en af ​​rollerne. I sidste ende har de to roller modstridende interesser. Produktejer forbliver i konstant kontakt med alle interessenter og sikrer, at det rigtige produkt leveres i den bedste kvalitet. Scrum Master skal blandt andet sørge for, at holdet ikke bliver overanstrengt eller afbrudt. Derfor har Scrum Master intet at gøre med selve produktet.

En endnu værre idé ville være at udelade Scrum Master helt. Uden en fungerende Scrum Master er der ingen rolle at sikre, at holdet arbejder produktivt, overholder tidsfrister eller lærer gennem retrospektiver og bliver mere effektive. Kort sagt, det er dem, der garanterer, at projektet gennemføres på en smidig måde. Efter vores erfaring er det en særlig vigtig rolle i et agenturmiljø med skiftende klienter, interessenter og betingelser, fordi Scrum Master også påtager sig en coachingrolle for klienten.

Denne artikel forklarer de forskellige funktioner i Scrum Master og den klassiske projektleder med hensyn til en letforståelig trafikanalogi:

3. Ikke mere ressourceplanlægning (etabler i stedet princippet)

I agenturer arbejdes der ofte med flere projekter for forskellige klienter samtidigt, hvilket gør den effektive fordeling af arbejdet blandt alle ansatte til en udfordring.

Den klassiske agenturtilgang er ressourceplanlægning: en projektleder opretter planer i flere dage eller uger fremover og tildeler medarbejdere henholdsvis projekter eller opgaver. Dette kræver meget tid til planlægning og koordinering og resulterer i fleksibilitet, da det fungerer under antagelse af, at alle fremskrivninger og planer for den tildelte tid er opfyldt.

Erfaringen lærer os, at sådanne planer i virkeligheden aldrig kommer til udførelse: en vigtig levering er forsinket, medarbejderne bliver syge eller andre uforudsete omstændigheder opstår, hvilket fører til, at individuelle opgaver tager længere tid end forventet. Konsekvenserne er en ujævn arbejdsfordeling blandt kolleger, mere stress og overarbejde.

Dette såkaldte “push-princip” (fordi medarbejdere har enkeltopgaver “skubbet” på sig) er derfor ikke optimalt. Så hvordan distribueres arbejde uden en projektleder i den agile konstellation? Dette spørgsmål kræver en anden tilgang:

Trækprincippet

Agilt arbejde er baseret på en ”pull” mentalitet. Det betyder, at medarbejderne proaktivt beslutter, hvilke opgaver de vil påtage sig. For at dette kan fungere, skal kommende opgaver og deres fremskridt kommunikeres.

I en ideel situation forekommer dette ikke kun på projektniveau, men for alle kommende opgaver i virksomheden. Dette inkluderer omfangsvurdering, oprettelse af præsentationer, forberedelse af workshops, deltagelse i interviews eller endda skrivning af denne artikel. Dette kan udføres med et Kanban-bord, for eksempel:

Trækprincippet hjælper med til at sikre en jævn fordeling af arbejdet blandt medarbejdere, hvor alle har friheden til at beslutte uafhængigt, når de har kapacitet til at arbejde med deres opgaver. Dette hjælper med at eliminere muligheden for overarbejde visse medarbejdere.

For at pull-princippet skal fungere, skal følgende betingelser være opfyldt:

  • Konstant kommunikation er afgørende. Hos Aperto Move diskuteres projektstatus tre gange om ugen i bestyrelsen
  • Det kræver, at folk med evnen til at tage initiativ i stedet for at vente på, at andre fortæller dem, hvad de skal gøre
  • Det favoriserer flade hierarkier og kræver en vilje til at implementere dem
  • Virksomhedsledelsen skal have tillid til deres ansatte for at gøre det muligt for dem at påtage sig mere ansvar
  • Der skal være en klar differentiering mellem individuelle opgaver og projekter. Projekter trækkes ikke af en enkelt person, men af ​​et team. Dette vil blive undersøgt yderligere i det følgende afsnit.

4. Opret stabile hold

Det er typisk hos agenturer at arbejde for forskellige klienter samtidigt, og der opstår ofte presserende opgaver (såsom omfangsvurderinger, pladser eller fejlrettelser) med kort varsel. Derfor oprettes ofte projekthold afhængigt af den aktuelle tilgængelighed. Denne type ressourceplanlægning forhindrer effektivt agile projekter.

Agile hold skal være stabile og ideelt finde sig selv. Kun nære teams kan udvikle sig optimalt og opretholde eller endda fremskynde deres tempo ved at lære af hinanden, koordinere deres processer og kommunikation og identificere og løse problemer gennem retrospektiv analyse.

Hold kan identificere og løse problemer gennem regelmæssige retrospektiver (Billede fra Andreas Plath)

For at undgå at forstyrre effektive team af kolleger, der arbejder godt sammen og derved eliminere al indlæring og rutineeffekter, bør kommende projekter ikke planlægges med enkeltpersoner i tankerne, men snarere med stabile teams.

Det er imidlertid urealistisk at tro, at omdannelsen af ​​et helt bureau med alle discipliner til stabile og afbalancerede hold kan ske natten over. Det kan tænkes, at ikke alle ønsker at arbejde permanent i det samme team. Derfor er det vigtigt at finde en balance, der fungerer godt for alle.

5. Opret smidige forslag

En klassisk, forenklet forslagsfase mellem klienter og et agentur har normalt følgende form: En klient har en bestemt idé til et produkt og en tidslinje for, hvornår det skal afsluttes.

Klienten orienterer derefter agenturet om kravene (måske med en tonehøjde) og beder om et forslag, der angiver en fast pris for udviklingen af ​​dette produkt. For at beskytte sig selv bruger begge parter en betydelig mængde arbejde på at udarbejde forslaget for at undgå potentiel miskommunikation.

Fra kundens perspektiv virker dette som en bæredygtig løsning: de ved, hvad de får, hvornår og til hvilken pris.

Krav ændres

Hvad de fleste kunder ikke ved på dette tidspunkt er, at de ofte vil have noget meget anderledes i slutningen af ​​projektet, som de gjorde i begyndelsen.

Da alt er konkret defineret i forslaget, er det så tæt på umuligt at ændre noget inden for projektet senere uden genforhandling, såsom:

  • andre funktioner blev mere vigtige i mellemtiden
  • det ønskede projekt er ikke længere teknisk muligt
  • brugertests afslørede, at produktet er misforstået, eller at det ikke giver mening
  • en konkurrent har skabt et lignende produkt, som kræver en strategisk drejning

I dette tilfælde er en omprioritering ikke let, hvis det gamle, revideret omfang specificeres i forslaget.

Andre vigtige aspekter ved at være smidige undermineres af denne type forslag. En kontinuerlig, samarbejdsmæssig forbedring af produktet er meget vanskeligere, da produktet skal defineres klart i begyndelsen for at færdiggøre forslaget. Dette fører til en typisk vandfaldsarbejdsgang. Sprintplanlægning, herunder planlægning af poker, bliver lige så meningsløs, fordi der allerede er defineret en endelig frist og levering.

Hvis omfanget, fristen og prisen allerede er indstillet i begyndelsen, giver det ikke længere mening at forsøge at implementere en smidig ramme som Scrum.

I dette tilfælde kan man ikke længere bruge de største fordele ved smidig levering, men har stadig en ekstra udgift af Scrum-møder, som ikke giver nogen reel værdi. Denne proces omtales også som "pseudo Scrum".

Der er behov for en anden type forslag

Det er mere fornuftigt at opkræve for mængden af ​​udført arbejde (såkaldte tids- og materielle kontrakter) snarere end at definere de nøjagtige leverancer i forslaget. Først da er det muligt at udføre et projekt på en smidig måde.

Hvor meget og hvad klienten får for sine penge bestemmes af ham selv i løbet af projektet ved at holde listen over krav ajour og prioriteres sammen med teamet.

Udarbejdelse af smidige forslag kræver praksis (Kilde: https://unsplash.com/?photo=OQMZwNd3ThU)

For at klienten får en idé om, hvad han kan forvente, kan man give et groft skøn over, hvor meget der er opnåeligt i en given tidsramme, eller hvor lang tid det vil tage, før et bestemt krav bliver implementeret. Jo længere et hold har arbejdet sammen, desto mere præcist bliver dette skøn, da det er lettere at måle det generelle tempo eller "hastighed" for holdet. Dette er en anden grund til, at det foretrækkes at arbejde med stabile teams.

Når det er sagt, er udarbejdelse af et forslag stadig et af de vanskeligste elementer i den smidige overgang. Næppe en enkelt klient, der ikke allerede har samlet erfaring i et smidigt miljø, ønsker at underskrive en åben kontrakt. For at overbevise dem om dens fortjeneste er det vigtigt at demonstrere dygtighed og først opbygge tillid hos klienten.

Efter vores erfaring kan denne udfordring let overvindes, så snart man sammen har afsluttet et smidigt projekt. Det er så, at projektprocessen taler for sig selv; der giver hurtige og håndgribelige resultater gennem iterativt arbejde, tæt samarbejde og kortere feedbackcykler, der er meget tættere på, hvad klienten forestillede sig, end de ville være i typiske vandfaldsprojekter.

Der er meget nyttig litteratur til rådighed om emnet smidige forslag som denne bog:

6. Inddrag projektteamet i overtagelsesfasen så tidligt som muligt

I agenturer er anskaffelses- og forslagsfasen ofte isoleret fra projektgennemførelsen. Et nyt forretningsteam er ansvarligt for nye projekter, og projektteamet konfronteres ikke med detaljerne før implementeringsfasen, hvilket øger sandsynligheden for konflikter.

Forslagsfasen kan allerede være afgørende for, om et projekt vil blive vellykket eller ej. Det er derfor vigtigt, at det agile team indgår i kommunikationen så tidligt som muligt.

Som et resultat kan man relativt tidligt vurdere, om en smidig implementering er levedygtig, og hvor meget tid der kan forventes til den. Tidsudgifterne, f.eks. antallet af nødvendige sprints i et scrum-projekt kan kun vurderes af teamet selv, hvis det ved så meget som muligt om projektet.

Lejlighedsvis vil der være flere projektanmodninger end der er kapacitet til at arbejde på dem. For at implementere pull-princippet og vælge det mest passende projekt, skal teamet vide så meget som muligt om alle verserende projekter. Først da kan de tage en informeret beslutning og meningsfuldt indarbejde nye projekter i sprints af nuværende.

Når det nye projekt begynder, skal teamet kende alle interessenter og deres krav så tidligt som muligt for at levere det rigtige produkt med den bedst mulige kvalitet. En effektiv foranstaltning for at opnå dette er at afholde en workshop med teamet og klientens interessenter.

Derudover er det vigtigt at kommunikere de agile værdier til klienten, at identificere den primære kontaktperson og at forklare samarbejdsproceduren i detaljer.

7. Glem tjenesteudbyderrollen (og arbejd som et team med din klient)

Et klient / tjenesteudbyderforhold er kontraproduktivt, da det altid er baseret på antagelsen om, at klienten har tildelt en kontrakt og forventer et specifikt resultat. Et vellykket projektresultat, der tilfredsstiller alle involverede parter, kræver normalt arbejde fra alle sider, især regelmæssig kommunikation med hinanden.

En væsentlig forudsætning for et vellykket smidigt projekt er kommunikation på samme niveau. Det betyder, at klienten og agenturet betragter hinanden som et enkelt team, der arbejder sammen om et projekt og identificerer og værdsætter hinandens styrker. Agenturet er normalt eksperten inden for strategi, brugeroplevelse, design og teknisk implementering; klienten er derimod bekendt med deres egne interne processer og krav samt deres målgruppe. Kun når disse oplysninger deles, kan man skabe et virkelig brugerorienteret produkt, der tilfredsstiller alle interessenter.

Dette kræver, at der er en udpeget kontaktperson på klientsiden, der er tilgængelig til at besvare spørgsmål vedrørende projektet eller kan give agenturet alt manglende materiale. Ikke hver klient kan eller ønsker at investere så meget tid i et enkelt projekt, fordi deres egne interne arbejdsprocesser ikke tillader det.

Efter vores erfaring bemærker klienter normalt på et tidligt tidspunkt, hvor meget hurtigere de får resultater af høj kvalitet gennem smidigt samarbejde. Dette svarer til deres forventninger, og de er villige til at investere tiden.

8. Giv plads til teamarbejde

At være smidig betyder at arbejde tværfagligt og med kontinuerlig kommunikation. Dette fungerer bedst, hvis det agile team sidder sammen, hvilket hjælper med til let at koordinere deres arbejde. Ideelt set skal hvert hold have sin egen plads, hvor de kan arbejde uforstyrret, mens minimere forstyrrelser for andre, f.eks. når design eller funktioner diskuteres.

Agile teams skal kunne arbejde uden at blive afbrudt (Kilde: https://unsplash.com/photos/5T6lSk2uI1A)

Agenturer maler ofte et andet billede: gruppering af medarbejdere i henhold til deres respektive discipliner. Det betyder, at alle designere sidder i et hjørne på kontoret, udviklere i et andet hjørne, og testere og kontostyrere ofte i forskellige rum. Selvom dette muligvis giver mening med hensyn til disciplinrelateret udveksling, komplicerer det kommunikationen i et projektteam. At skrive hinanden er en mulighed, men det tager meget længere tid end at tale direkte til hinanden.

Det bliver endnu vanskeligere, når alle teammedlemmer ikke er på samme sted. Alle ved, hvor dårlige telefon- eller videokonferencer er, og hvis du ikke behøvede at lide dem før, anbefales denne video:

9. Overvej enhver disciplin og den komplette projektproces

Da Scrum blev født fra softwareudvikling, kan det virke praktisk at kun udføre det tekniske aspekt af projektet på en smidig måde, idet den kreative fase efterlades uberørt. Dette opnår imidlertid relativt lidt, da vandfaldstrukturen derefter kun løses ved afslutningen af ​​et projekt.

En klassisk vandfaldsproces er baseret på godkendelse af specifikke leverancer

Lad os antage, at det smidige team udelukkende består af udviklere; konceptet og designet af klientwebstedet er allerede komplet, men midt i udviklingen bliver det tydeligt, at vigtige stater ikke er defineret eller designet, og det kreative team er allerede involveret i deres næste projekt. Hvad nu? Bør man tage folk af med andre projekter? Vil du fortsætte med at udvikle et ufuldstændigt produkt? Der er intet andet let svar end at involvere alle relevante discipliner i den smidige arbejdsgang fra starten.

Regelmæssig udveksling inden for projektgruppen forbedrer produktets kvalitet (Kilde: https://unsplash.com/photos/gN_nIUnjYJI)

Feedback, Feedback, Feedback

En enorm styrke og en vigtig grund til, at kvaliteten af ​​agile-udviklet software er bedre end vandfaldsprojekter under klassisk projektstyring, er det tværfaglige samarbejde og iterativ forbedring af produkter, der er baseret på tidlig og regelmæssig feedback blandt alle interessenter.

Kort sagt betyder det: alle gennemgår alt i alle faser af projektet.

  • Klienten og hele teamet giver Product Owner (PO) feedback til brugerhistorierne
  • UI-designere giver feedback til wireframes og teknisk udførelse
  • UX-designere giver feedback til brugergrænsefladesign og teknisk udførelse
  • Front-end-udviklere giver feedback til wireframes, design af brugergrænseflader, til backend-grænseflader og, hvor relevant, backend-implementeringen
  • Back-end-udviklere giver feedback til wireframes, brugergrænsefladedesign og front-end-implementering
  • Kvalitetssikring (QA) giver feedback til wireframes, brugergrænsefladesign og teknisk udførelse
  • Brugere giver feedback via brugervenlighedstest gennem projektfaser (wireframes, designprototyper, klik-dummies, front-end-implementering)
  • Klienten giver feedback til produktforhøjelser under sprintgennemførelser
I en agil opsætning arbejder teamet sammen snarere end fortløbende

Regelmæssig feedback er det vigtigste aktiv i smidig udvikling og sikrer, at produktet udvikles på et niveau, der tilfredsstiller alle interessenter. Dette fungerer naturligvis kun, når alle er involveret i hver projektfase.

10. Forvent ikke, at alt fungerer umiddelbart (foretag fejl og lær af dem)

Forhåbentlig formidlede de foregående sektioner, at det på flere niveauer er nødvendigt at tage forskellige tilgange til dem, der sandsynligvis er blevet udviklet og etableret i årevis. Dette gør det endnu vigtigere at forstå, at overgangen til at blive smidig er en proces, og ikke nødvendigvis en nem, heller ikke en med en defineret ende.

Implementeringen af ​​de ovenfor beskrevne foranstaltninger garanterer ikke automatisk overgangen til at være smidig. Tilsvarende er det ikke nok at kun implementere “tekniske” aspekter, såsom vedtagelsen af ​​Scrum. Det er meget mere vigtigt at ændre virksomhedskulturen og etablere et fælles, smidigt værdisystem på alle hierarkiske niveauer.

Det ville være naivt at forvente, at sådanne grundlæggende ændringer kunne gennemføres øjeblikkeligt og uden problemer. Ændringerne i virksomhedens processer kan også behandles som et smidigt projekt og rulles iterativt ud.

I sidste ende betyder det, at man ikke skal prøve at ændre alt på én gang, men snarere implementere en foranstaltning ad gangen. På denne måde lærer man, hvad der fungerer, hvad der ikke gør, og hvad der kan forbedres. Det ville være forkert at holde sig til et mål, der ikke føles rigtigt, bare fordi en bog eller blog har anbefalet det.

Ekstern coaching kan være lige så hjælpsom med at indlede de rigtige tankeprocesser, men man kan ikke håbe at finde en hurtig-fix løsning, der gør en pludselig smidig.

Det er lige så vigtigt at etablere en intern udveksling af viden og erfaring og at blive enige om en fælles tilgang. For at opnå dette er det nyttigt at se regelmæssigt på de tolv principper bag Agile Manifesto og gennemgå i hvilken udstrækning en virksomheds virksomhed allerede har vedtaget dem:

I vores team har den strenge overholdelse af retningslinjerne for Scrum-rammerne vist sig at være den bedste løsning. Hver gang disse processer blev afviget, førte det til komplikationer og mere indsats. Dette behøver dog ikke være tilfældet med alle. Hver virksomhed skal selv opdage, hvad der fungerer bedst.

Konklusion

Selv før et klientprojekt begynder, kan visse standardbureaubetingelser bringe eller endda umuliggøre succes med agile projekter. Det er her, der kræves en ny måde at tænke på alle niveauer og på tværs af alle discipliner, hvilket indebærer ændringer, der ikke kan implementeres natten over.

De punkter, der fremsættes i denne artikel, kan tjene som en retningslinje for at genkende og diskutere situationer og problemer i planlægningen af ​​agile projekter, inden de begynder.

Hvad er dine oplevelser med dette emne? Kender du andre forhold, der vanskeliggør agile processer? Fortæl os det i kommentarafsnittet om denne artikel.

Yderligere læsning

Aperto Move - Et IBM-firma er et Berlin-agentur for digitale og mobile tjenester med omkring 30 ansatte. Hvad med dig?

Følg os: apertomove.com / Facebook / Twitter