Moede Kbh Aarhus Januar

Temaet i januar var - både i København og Århus - "Udfordringer ved indførelse af Agile metoder". Herunder findes problemstilinger og løsninger fra både Århus og København.

Bemærk, at nedstående er resultatet af en række erfarne menneskers oplevelser fra det virkelige liv. Problemer og løsninger er således noget, der er oplevet - og har virket i rigtige projekter - og ikke bare tankespind...

Start internt

Start med det, der ”vender indad” – det man selv kan kontrollere – det der ikke stiller krav til andre Hvis man starter med at køre ”det tunge skyts” i stilling – og prøver at ”missionere” og omvende kunde, styregruppe, deltagere og alle andre involverede risikerer man, at det kommer til at lyde så overvældende, at de bakker ud…

En ting ad gangen

En ting ad gangen – f.eks test first. Eller prøv det hele – hvis det kan lade sig gøre i projektet. Test er et eksempel på noget, der ”vender indad” – som man dermed kan implementere uden at ”genere” omgivelserne Det handler om mennesker og om teamet

Mennesker som team

Den største udfordring er, at få menneskene i projektet til at arbejde som et team – og til at forstå den iterative og ”minemalistiske” måde at arbejde på. Det er en så stor forandring for mange, at det ind i mellem kræver at man som projektleder går ret tæt på projektdeltagerne.

Viljen skal være der. ”Skal indgydes i folk”.

Det er ikke nok at projektlederen vil. Deltagerne skal også ville. Derfor skal de ”smittes” så de selv bærer ideen – og dermed automatisk trækker i den rigtige retning.

Mål på frustrationsniveauet – om det går godt

Som agil projektleder kan det være svært at følge med i om funktionaliteten udvikler sig som den skal - fordi der er så mange andre ting (den enkeltes – og teamets kommunikation, løbende prioritering sammen med kunden, løbende planlægning) man skal. En udmærket indikator på om det går godt er frustrationsniveauet hos teamet og hos den enkelte

Folk skal være forandringsvillige og risikovillige

I en ”plejer” kultur kan dette ikke lade sig gøre. Man må ledelsesmæssigt motivere og forlange af folk, at de er med på at forandre den måde de arbejder på.

”Mental manipulation” / ”fake it” / ”børneopdragelse” – giv dem smag for det… Det skal modnes

”Mental manipulation” og ”fake it” lyder måske negativt, men måske er det det, der skal til for at motivere folk. For at få folk med på ideen skal der virkelig motiveres, lokkes, sælges etc… Alligevel skal man ikke forvente ændringen fra den ene dag til den anden. Det skal have tid til at modnes… Men dette skal ikke være en sovepude. Det kræver konstant ledelsesmæssig attention, at teamet ikke bare falder tilbage på gamle vaner…

Frivillig deltagelse er nok en fordel, men vær parat på modstand alligevel

Hvis medarbejderne selv kan vælge, at deltage på et Agile projekt, så giver det nok en fordel i forhold til motivationen. Men det er absolut ingen garanti for, at det bliver let. For hver enkelt lille ting der sker i projektet kan give anledning til en ny fornemmelse af kaos – og hvad skal vi

Det er vigtigt med ambassadører i projektet

Find minimum én projektdeltager, som brænder for ideen. Skaf opbakning – eller som minimum forståelse/accept – hos de øvrige lag i projektorganisationen Projektlederen skal brænde for ideen – og facilitere og ”holde den gående” Det er (for?) svært, hvis arbejdsmetoderne i Agile/XP ligger uden for deltagernes ”Comfort zone” Bemand projektet med folk, som har det OK med at blive klogere undervejs; som ikke synes det er ”flovt” at have lavet noget, som så senere skal laves om. Forstå, at det er en stor forandring, og at ”det er sværere at aflære end at lære”

Iterationer – refactoring – automatisk test

Lav kørende software helt(!!!) færdigt i hver iteration – som løser de opgaver, der ligger i iterationer – og IKKE hverken halve eller hele løsninger på andre opgaver/fremtidige iterationer Benyt refaktorering til ændring af design/arkitektur, når nye iterationer stiller nye krav til design og arkitektur. Indfør automatiske tests. Refactorering (og dermed iterationer) er næsten ikke praktisk muligt uden automatisk test.

Pragmatisk indførsel - ”Skjult” - Evolution frem for revolution

Undlad evt. at kalde det for ”Agile” eller ”XP”. Det kan give for store diskussioner up front. Undlad at indføre ”det hele” på én gang - men udvælg enkelte værdier og teknikker – og indfør dem gradvist i projekterne Levér iterativt – og bevis på denne måde, at arbejdsmetoden fungerer

Kræver udviklere, der er kommunikerende

Bemand projekterne med deltagere, der kan lide at kommunikere – og som er team-orienterede (frem for individualister) Kræver en god kemi/ånd Skab et fællesskab i projektgruppen (sæt dem sammen – husk at fejre successer – giv dem et klart fælles mål) Løs kommunikationsproblemer / uenigheder blandt deltagerne prompte