Er agilister svære at arbejde sammen med?

Ligesom Anne-Sofie Nielsen var jeg i sidste uge inde og høre Alexander Grosses foredrag "What sucks about Scrum" på GOTO-konferencen. Der kom mange guldkorn på kort tid, og et af dem har været et tema i branchen og dermed på GOTO-konferencen i et stykke tid:

"Hvordan undgår vi som udviklere at isolere os fra andre grupper vi samarbejder med, når vi arbejder agilt, og hvordan påvirker vi de andre grupper til enten at blive en del af den agile tankegang eller i det mindste få en veldefineret, velfungerende snitflade mod den agile gruppe? "

Alexander nævnte konkret "Test" og "Drift", som eksempler, men i andre sammenhænge er jeg stødt på "Designere" og "Ledelsen". Disse emner har jeg ofte hørt gentaget i diskussioner af, hvilke problemer folk har med at indføre Scrum/Kanban/X i deres organisation.

Ledelsen vs. udviklere: I et startup som Alexander Grosses Soundcloud er samarbejde med ledelsen måske nok ikke et problem, fordi Soundcloud for nyligt har været lille nok til at definere en fælles kultur mellem udviklere og resten af organisationen. For andre som ikke har haft samme luksus, ser verden dog anderledes ud; management var det første "pain point", som jeg i sin tid hørte agilisterne nævne. Hvordan overbeviste man ledelsen om at det var smart at have selvkørende udviklere, der ikke ville micromanages? Hvordan fik ledelsen tillid til at et projekt kørte godt nok, selv om de ikke havde været en del af hver eneste beslutning? Hvad leverer vi, som kan hjælpe ledelsen til at indse, at vi er til at stole på og er på vej i den rigtige retning?

Testere vs. udviklere: Den næste gruppe, som agilisterne tog fat på, var testerne. Nogle tests skulle udviklerne selv stå for, og andre skulle man for alt i verden undgå at "smide over væggen" til testgruppen. Derimod skal vi integrere testgruppen i gruppen så vidt muligt. Dialog og co-lokation lød som vejen frem. Alexander Grosse gik så langt som at sige, at man ikke skal have en dedikeret tester, men derimod bare selv bruge sit produkt, og skulle man få deployet nogle fejl, så ville man hurtigt opdage det. Den tankegang har jeg mødt i flere startups, men om det er fornuftigt, kommer meget an på typen af systemet, man arbejdet på.

Drift vs. udviklerne: DevOps er blevet et buzzword - man skal forholde sig til problemerne mellem udviklerne og dem der skal sørge for at systemet kører. Som på andre områder fordrer agilitet, at man skal kommunikere, samarbejde og integrere, men det er ofte meget forskellige tankegange, der råder i henholdsvis udviklingsafdelingen og driftsafdelingen. DevOps bliver mere og mere populært at gå op i hvert år, hvis man skal dømme efter GOTO-konferencen.

Designere vs. udviklere: Den nyeste trend er så at bekymre sig om, hvordan udviklere og designere arbejder sammen i en agil verden. Nu har vi fået en ny blogger her på version2, Anja Thrane, som garanteret er meget bedre til at skrive om den slags end jeg er, men jeg har fulgt trenden, og indtil videre kan man jo starte med at tilpasse rådene, man har fra de andre grupper: Kommuniker, samarbejd og integrer.

  • 1) Få et fælles ordforråd. Design handler ikke (kun) om blå eller røde knapper, men også om brugervenlighed, designworkshops og metrikker. Sørg for at designerne ved lidt om, hvad udviklingsverdenen går ud på og sørg for at finde ud af, hvad de laver og har af prioriteter og behov.
  • 2) Samarbejd. Inddrag hele tiden hinanden. Designere kan f.eks. tage udviklerne med på brugerbesøg, og udviklerne kan indgå et samarbejde med designerne, når et givent design skal ændres eller tilpasses den tekniske virkelighed og dermed give dem indsigt i den del af processen, som udviklerne sidder med.
  • 3) Tag designerne med i gruppen. Sid sammen og udvikl en fælles kultur. Undgå "os og dem"-mentalitet.

I et lille startup som mit får man hurtigt flere hatte på, og når man både skal være udvikler, designer, ledelse og drift, åbner der sig en ny verden. Jeg kan dog ikke helt finde ud af, om de andre faggrupper bekymrer sig lige så meget om, hvordan de samarbejder med udviklere, som vi bekymrer os om, hvordan vi samarbejder med dem...

Therese Hansens billede

Kommentarer (2)

Morten Fordsmand

Lige som det altid har været svært for alle mulige faggrupper at arbejde sammen, når man har forskellige mål.

Jeg tror ikke at nogen af de skismaer du nævner ikke har været udfordringer lige så længe som vi har lavet IT-systemer. (men nu er jeg også et gammelt r..hul)

Nicolai Møller-Andersen

Kunne det tænkes, at agilister er svære at arbejde sammen med, fordi de arbejder på en måde, som ikke er 100% kompatibel med traditionel planlægning? Kunne det tænkes, at det virker stærkt provokerende på resten af virksomheden, når en gruppe udviklere meddeler, at de arbejder agilt, og at resten af butikken må indrette sig herefter? Underforstået - naturligvis - at resten af butikken IKKE arbejder agilt.

Udviklere er altid bekymrede for deres samarbejde med alle de andre; Jo flere specialister der er rundt om udviklerne, - designere, arkitekter, testere, driftere, ledelse, produktchefer, - jo flere er der, som fortæller udviklerne, hvordan de skal gøre deres arbejde.

Det kan godt være frustrerende at være tømreren, som hele tiden får at vide, hvordan sømmene skal slås i.

Ofte er de grupper, jeg nævner, uenige om, hvad udviklerne skal prioritere. Skal sømmene slås hurtigt i, eller er det vigtigere at de slås præcist i, eller skulle det i virkeligheden hellere være skruer? Eller ritch-ratch?

Jeg tror skismaerne vokser i takt med at respekten for udviklernes arbejde flyttes til designere, arkitekter, testere, driftere...

Log ind eller opret en konto for at skrive kommentarer

IT Businesses