Agile Manifesto Adoption for Whom? December 08, 2010 16:00 about 1 year ago
Er du i tvivl om at det Agile Manifesto er noget for dig og mærker du modstand i din organisation hver gang du forsøger at indføre adrætte metodikker? Måske er hverken du eller dine medarbejder parate til at adopteret nogen form for adræt tankegang?
I en tidligere blog post om Agile Manifesto Adoption var jeg inden på at tilpasse det adrætte manifest fra en metodik der hovedsagligt var skrevet for små teams til en mere virksomhedsvenlig stil hvor ikke alle løsninger realiseres som applikationer.
Et andet og ikke mindre interessant emne er at fokusere på en definition af de mennesker og projekter der har succes med den adrætte proces.
Jeg har været med i lidt over 10 projekter hvor “Agile” eller “agil” som mange dansker fejlagtigt udtrykker det, er blevet taget alvorligt. ET af disse projekter har, efter min mening, haft succes med processen.
De andre projekter har fejlet og blot eksekveret en vandfaldsmodel der passer ind i en sprint. Min favorit forfatter på emnet, Larman udtrykker dette som den “superimposed model”. Når dit team udføre en superimposed model vil de ikke opnå resultater eller dele positivt feedback og resultat er ofte demotiverede medarbejder samt dårlig produtivtet.
Så hvorfor ikke? Hvad går galt? Det kontroversielle svar er enkelt. Manglende personlige og faglige kompetencer.
Efter min overbevisning kræver det adrætte manifesto en mental transformation og her findes to slags mennesker? Der er dem som succes med den adrætte metodik og så alle de andre. Hvis man kommer fra et traditionelt miljø med vandfaldsplan og vil taget en adræt metode til sig, handler i vid udstrækning om sociale kompetencer.
X-faktor effekten findes også blandt mennesker der vil være adrætte. Du er ikke verdensmester på første dag selv om dit mor siger du er god. En hurtig løber på skøjter fokuser heller ikke topfart før det er muligt at dreje rundt i svinget. Ha altid de basale leveregle på plads før du omdefinere de formelle værdier i metoden.
En typisk fejl er at tro alle projekter udenvidere kan konverteres til adrætte projekter. Et velegnet projekt for et adræt team kunne være karaktiseret ved:
- at være en ikke kritisk løsning
- at deltagerne mindst er developer/senior resurser
- at have ustabile kravslister
- at have en begrænset størrelse
- at have en kultur der trives med kaos
Et velegnet projekt for et ikke adræt team kunne være karaktiseret ved:
- at være en kritisk løsning
- at deltagerne er junior/trainee ressourcer
- at have stabile kravslister
- at have højt antal deltagere
- at have en kultur der trives med orden
- at have krav der kan modeleres
- at have ekstreme krav
At gøre et projekt målbart på denne måde er selvfølgelig helt forrykt. Men ikke mere forkert end måle hverenkelt deltager efter dreyfus skala’en for kompentenceudvikling for derefter at forvente at de spiller sammen som et team?
Hvad med de programmører som ledelsen typisk ser som ligeværdige deltagere i deres forstelling om hyperproduktive teams. Måske hører du til dem der tror at en kodekarl er sådan en salgs tryllekunstner der kan 1000 ting samtidigt men det hænge ikke helt sådan sammen. Viste du at:
- En programmør bruger ca. 10-20% af sin tid på at skrive kode, og de fleste programmører skrive ca. 10-12 linjer kode per dag, uanset evner. Forskellige består i hvor lang tid de kodelinjer lever uden problemer i produktion miljø.
- Gode programmører bruger 90% af tiden til at tænke, forsker og eksperimenterer for at finde det bedste design der præcis har en abstrations grad der gør det muligt at vedligeholde og udbygge.
- Dårlige programmører bruger 90% af tiden til at debugge kode, foretage tilfældige ændringer og checke at det virker.
- En god programmør er mindst ti gange mere produktiv end en gennemsnits programmør.
- En senior programmør er 20-100 gange mere produktiv end gennemsnittet. Undersøgelser gennemført siden 1960 har konsekvent vist det at en dårlig programmør ikke bare er uproduktiv men kan skaber en masse ekstra arbejde og inerti og negativ fremdrift for andre.
- Programmører der bruger det meste af deres tid på at skrive kode er for dovne, for uvidende, eller for arrogante til at finde eksisterende løsninger på gamle problemer.
- Senior programmører er mestre til at genkende og genbruge fælles mønstre. Derfor har de sjældent travlt.
- Gode programmører er ikke bange for at omskrive deres kode konstant for at nå det ideelle design. De gør det sideløbende med at de implementere nye features.
- Dårlige programmører skriver kode der mangler konceptuel integritet, der er redundant, med ringe hierarki og mønstre der gør omskrivning umuligt. Ofte vil det være nemmere at smide koden ud og starte forfra.
- Programmering er hårdt arbejde. Det er en intens mental aktivitet. Gode programmører tænke over deres arbejde altid. De skriver deres mest vigtige koder i deres drømme.
- Software adlyder reglen om entropi(*). Det betyder at løbende ændringer og omskrivninger for at nedskrive teknisk gæld ødelægger den konceptuelle integritet. Det er uundgåelig at et system få teknisk gæld men når programmører undlader at tage hensyn til begrebsmæssige integritet opbygges gæld i systemet hurtigere end gælden nedskrives. Teknisk gæld bremser fremskridt i software eksponentielt og resultatet er stagnation og eksploderende milepæle og budgetter.
De fleste af disse punkter stammer fra den “Den mytiske mandemåned” og er pebret lidt op fra en post jeg ikke kan huske.. Men det begynder at blive tydelig for mig at der findes en tredie komponent i vores game.
Lad os sige at vi har fundet et godt projekt med den rette kompleksitet til adræt udvikling og vi har også fundet en gruppe af programmøre med en bred vifte af kompetencer.
Vi mangler betydningen af den ledelsesmæssig adoption, et nøgle element i enhver forretning. Kun ganske få virksomheder ser alvoren i dette område skønt alle ved at firma kulturen direkte kan afspejle sig i hver enkelt medarbejder. Sjovt tror mange mellemledere at de kan tillade sig at tage let på regler eller metoder som de samtidigt forventer deres ansatte følger.
- At fremstille software er ikke en demokratisk aktivitet. Normalt skal kun én person være ansvarlig for design mens andre team medlemmer løser trivielle opgaver. Alle skal kende deres indbyrdes rolle.
- Kulturen mellem afdelinger er vigtig. En enkelt adræt afdeling kan ikke leve mellem mange traditionelle afdelinger. Hvis den fælles kultur er bundet tæt sammen med taylorisme kan det være en bedre løsning med outsourcing og ydelses køb hos tredieparts leverandører.
- En undersøgelse har vist at 1 ud af 3 agile software-projekter har valgt agile metoden fordi der ikke er tid til planlægning.
- En undersøgelse fra 2004 fandt at 51 procent af software-projekter vil mislykkes i et kritisk aspekt og andre 15 procent vil mislykkes totalt. Dette er en faktisk en forbedring siden 1994 hvor hele 31 procent mislykkedes.
- Den vigtigste proces i softwareudvikling handler om ideer og design. Derfor kan software projekter ikke kan fremskyndes ved at bruge mere tid på kontoret eller tilføje flere personer for at nå en deadline.
Konklusion
Der vil findes få gange hvor der er en ideel løsning, et velmotiveret team i en velorganiseret og velledet virksomhed uden for meget burokati, helt ærligt er det nok flere gange hvor det modsatte er tilfældet. Men jeg synes godt at jeg kan trække en linje gennem de projekter hvor jeg har deltaget.
- teams med flere senior resource har størst chance for succes
- teams med få eller ingen senior resource fejler
Fra mine ynger dage som reklamefotograf har jeg lært at betragte, og det gør jeg i vid udstraktning. Det er som adræt metode stiller større krav til den enkelte for at kunne være et positivt aktiv til et team.
- Kan du levere værdi til forretningen?
- Kan du bidrage med et solidt håndværk?
- Kan du levere kode af høj kvalitet?
- Kan du tage initiativ og udvikle dig?
- Kan du forstå hele softwareudviklings cyklus?
- Kan du forstå og bruge version styringssystemer?
- Kan du forstå vigtigheden af en metode?
- Kan du komme med forslag til forbedringer?
- Kan du begå sig i sociale sammenhænge?
- Kan du forstå andres ideoplæg?
- Kan du skabe fornuftige design beslutninger?
- Kan du indordne dig i en bestemt rolle?
Hvis du svarede ja til disse punkter er der en god chance for at et team kan drage fordel af din arbejdsindsats.
But what the hell, det er jo bare min opfattelse!
*entropi: Et direkte mål for tilfældigheden i et system.
By Frank Vilhelmsen - 1 tag: agile - Add comment