Ikke mere lagkage, tak!

Ikke mere lagkage, tak!

Hvis du bruger lagkagemetoden til at lave software i dag, så stop. Jeg kender til mange projekter hvor man både organisatorisk og systemmæssigt arbejder efter et lagkage princip.

Idéen er at man bygger systemet som en lagkage. Først bunden, så lag på lag indtil man er færdig. Det er som sådan ikke forkert at gøre, men det har en række alvorlige uhensigtsmæssigheder.

For at kunne lave bunden først, skal man kende de fleste krav. Det føre ofte til en klassisk vandfaldsmodel, og det ved vi næsten aldrig fungere. Desuden afspejler organisationen ofte denne måde at arbejde på. Det vil sige at der finde en database afdeling, en arkitektur afdeling, en middleware afdeling, en klient afdeling, en UX afdeling (hvis man er heldig) osv. Det giver masser af problemer i forhold til ansvarlighed, overblik, koordination, og prioritering mellem projekter og grupper. Der findes ikke naturlige feedback løkker i dette system. Dem der har bestilt systemet ser det ofte først når det hele er færdig, og så er det rigtigt dyrt at ændre på noget. Faktisk ser man nogle gange at den nederste del af systemet er bygget forkert, og det ikke kan betale sig at reparere på det. Alt er med andre ord tabt. Det er netop alle disse ting som de agile metoder og værktøjer forsøger at adressere.

Jeg vil anbefale at man bruger en metode som jeg har arbejdet med i snart 20 år, nemlig “vertical slicing” Man tager en lille del af systemet og bygger det fra top til bund. Så tager man næste del på samme måde, osv. Hvad er så fordelene ved denne fremgangsmåde? For det første er man tvunget til tværfagligt samarbejde, ja endnu bedre er at man bliver rigtigt agil og ændre sin organisation til bestå af grupper, der er sammensat tværfaglig. Men når man bygger en lille del af systemet fra top til bund, afdækker man også en masse usikkerheder og antagelser.

I rigtigt mange af de projekter jeg har arbejdet med i tidens løb, kom de store udfordringer i forbindelse med integration og antagelser om data indhold eller sammensætning. Når man laver en spike gennem hele systemet, bliver der rejst en masse spørgsmål, og det er vigtigt at man forholder sig dem. Det giver en afklaring, som i nogle tilfælde helt ændre forudsætningerne for projektet. Ja, jeg har sågar været med til at lukke projekter fordi det viste sig, at det ville bliver alt for dyrt eller teknisk umuligt.

En anden og måske den vigtigste egenskab er dialogen med forretningen / opgavestilleren. Når du laver en lille del af systemet færdig, så kan du vise den til opgavestilleren, og få feedback med det sammen. Dette kan afdække mange problemer, der ofte opstår af kommunikationsproblemer (Nok til et helt blogindlæg i sig selv). I den forbindelse giver dialogen også mulighed for innovation, der jo ofte udspringer af en samtale mellem opgavestiller og opgaveløser.

Så skulle man tro at der var mange udvilklere og projektleder, der synes denne metode lå lige for, men min erfaring siger mig, at der kan være rigtigt meget modstand mod processen. Der er ofte undskyldninger i retningen af, “det kommer til at tage meget længere tid”, “vi mangler, det eller det”, “vi er nødt til at vente på den, eller det”, men allerværst er “sådan plejer vi ikke at arbejde” Ofte handler det om indstilling og evnen til at tænke abstrakt og løsningsorienteret. Det er rigtigt at hvis man er fastlåst i nogle bestemte metoder, miljøer og værktøjer, ja så kan det være en stor udfordring. Det kræver at man er åben og evner at tænke abstrakt og løsningsorienteret. Når jeg har skulle flytte folk har det ofte været lavpraktiske metoder, der hjælper folk med at se hvordan de faktisk kan arbejde fornuftigt på denne måde. Jeg har aldrig oplevet, at folk ikke har været glade for måde at arbejde på, når projektet er over.

Hvis du finde metode interessant, men er i tvivle om hvordan du griber det an i praksis, eller møde modstand i organisationen, så skal du være velkommen til at kontakt mig, jeg hjælper gerne til.

For nogle gode beskrivelser på vertical slicing vil jeg gerne henvise til min gamle kollega fra Adobe, Peter Green det har stået for et meget succesfuld agile push i Adobe. Han har skrevet om vertical slicing på sin Adobe blog http://blogs.adobe.com/agile/2013/09/27/splitting-stories-into-small-vertical-slices/ , og som gæste indlæg hos Mike Cohen http://www.mountaingoatsoftware.com/blog/using-vertical-slicing-and-estimation-to-make-business-decisions-at-adobe

Så afskaf lagkagemodellen, købe nogle rigtige kager til at fejre succesfulde projekter i stedet. Held og lykke derude!