Ett lackmustest för agilitet

Jag hör många som säger att deras projekt är agila. Vad jag har lärt mig av det är när man säger att man jobbar agilt så jobbar man oftast inte agilt. Jag brukar ställa tre frågor för att avgöra hur förändringsbenägen och effektiv man egentligen är i sitt projekt.

  1. Vet ni vad alla andra i teamet och utanför gör?Kommunikation är a och o. Visualisering på olika typer av boards är det minsta man kan göra. Se till att muntligen kommunicera med varandra tämligen konstant är vad man borde göra.
  2. Jobbar ni tillsammans för att lösa problem?Samarbete, inte bara samverkan eller koordination, är vad som krävs för att bli effektiv. När hela teamet arbetar på en och samma user story och hjälper varandra att slutföra den, då samarbetar man. Mob programming är ett bra exempel.
  3. Försöker ni att hela tiden navelskåda er process och förbättra den?Kontinuerlig förbättring krävs för att man som team ska kunna bli bättre på det man gör. Det är faktiskt så att det till och med krävs för att bibehålla sin mognadsnivå. De team som saknar en förbättringsprocess, där man analyserar, experimenterar och följer upp (allra minst en timme i veckan), blir mer och mer omogna med tiden.

Vad svarar ni på de här frågorna?

p.s. min kollega Per Lundholm lade till frågan ”Itererar ni över det ni levererat till produktion så att ni lär er från riktig användning av produkten och förbättrar den, eller, bygger ni i varje sprint ett inkrement av en sedan tidigare bestämd produkt?”. Högst rimligt att ställa den frågan då alternativ ett är en stor faktor till förändringsbenägenhet och till att man överhuvudtaget bygger rätt sak.

Brist på medmänsklighet

Mina kollegor publicerade ett blogginlägg för en tid sedan om att det är omöjligt att kombinera agilt arbetssätt med PM3, vilket är en populär förvaltningsmodell. Mina kollegors poäng är att PM3 och Agile har två olika värdegrunder, därför går de inte att kombinera. Detta har lett till långa diskussioner i diverse forum, såklart. Det finns naturligtvis två tydliga läger i debatten.

För mig symboliserar PM3 det gamla tänket i att man vet precis vad man vill ha och tror att världen och människorna inte förändras under projektets gång. De personer jag känner som har denna inställning (och de som förespråkar PM3 i alla ovan nämnda diskussioner) kallar sina medarbetare för resurser och inte människor. Det tycker jag visar på pricken att man är fast i ett tayloristiskt tänk där en grupp ”smarta” planerar och de ”korkade” producerar. Där och endast där kan man likställa människor med andra råvaror och inte se att det är individerna i produktionen som är basen för att ett projekt ska lyckas.

Jag är ingen jävla skrivare. 🙂

No-Printer-300x300

The biggest lie in software development is phase 2 

Jag tror att första gången jag hörde citatet i titeln var det antingen Jeff Patton eller Jeff Gothelf som yppade det, men det är säkerligen äldre än så.

Jag har egentligen endast jobbat i ett regelrätt vattenfallsprojekt (dvs. hårt strukturerad produktframtagning uppdelad i diskreta enheter) så jag har svårt att uttala mig om hur produktledningsspelet såg ut före den agila rörelsen klev in på banan. Baserat på min lilla erfarenhet, en massa läroböcker samt vetskapen att de flesta tog Winston Royce beskrivning av en trasig modell som en rekommendation, så tänker jag mig att förbättringsarbete pågick inom varje versionsarbete och man lade till funktionalitet för varje funktion. Det som förbättrades var att man eliminerade buggar. Jag tror att fas 2 verkligen fanns, om än bristfälligt.

När bl.a. Agile äntrar banan, en massa år efter Royce essä, ligger fokus på att få till en kontinuerlig feedbackcykel med så kort tid mellan varje steg som möjligt. Detta ger upphov till att det faktiskt kan och får ske förbättring även mellan versioner. Man får en möjlighet att ha en mer kreativ och utforskande process där det är helt okej (nåja) att sikta fel i första versionen för att det går att sikta mer rätt i efterföljande versioner. Man brukar säga att man inte tänkte på UX när det agila manifestet togs fram, men man möjliggjorde ett tätare samarbete mellan designavdelningen och utvecklingsavdelningen som var få förunnat innan dess.

Jag hittade ett par bilder på Internet, som jag inte vet var de kommer ifrån. Den första illustrerar varför man bör iterera.

iteration

Men ett antal år senare försvinner fas 2. När de gamla projektledarna inser att de med agil metodik (inte nödvändigtvis med agilt tänk) kan snabbare leverera funktionalitet, blir utvecklingen rent inkrementell. Man bygger på det man tidigare gjort och kallar det förbättring, fastän man egentligen inte rör redan färdigbyggda funktioner om de inte är uppenbart funktionellt trasiga. Om de inte matchar målgruppen eller marknaden, well, då lägger man till fler funktioner för att råda bot på det problemet. Ju snabbare man jobbar i kortare och kortare sprintar, desto mindre hinns det med någon typ av iterativt arbete varken under tiden eller mellan versioner. Man tappar fullkomligt den egentliga styrningen och kreativiteten.

Den andra bilden visar var bristen ligger i det som vanligtvis går under namnet agile, men definitivt inte är det.

AndersRamsays

Här råder en stor frustration och ilska mellan designers och utvecklare.

Här är vi idag.

Eller rättare sagt igår, för med Lean Startup-metodik i allmänhet och LeanUX i synnerhet, har vi fått ett verktyg som mer matchar agilisternas gamla slagdänga om iterativ och inkrementell utveckling.

Nu gäller det bara att vi lär de gamla projektledarna detta också.