Ledare: Karusellen snurrare allt fortare

Som många känner till använder agila projekt kortare iterationer än vi, historiskt sett, använt tidigare, normalt 2 - 4 veckor. Inom denna tidsrymd ska vi hinna analysera behov, planera arbetet, utforma och implementera en lösning, verifiera att det fungerar, verifiera att behovet är uppfyllt och se till att både den inre och den yttre kvaliteten är minst lika hög som i förra iterationen. Puh! Detta är tufft.

Och det blir bara tuffare. Riktigt mogna och duktiga agila team börjar nu skruva åt detta ytterligare. Det är inte vanligt ännu, men en del team börjar nu använda iterationer på en vecka. Detta ställer naturligtvis höga krav på alla inblandade och deras samarbete, men även på projektets infrastruktur för leveranser. Men ju högre krav vi ställer på oss själva, desto bättre blir vi också.

Det finns många saker som talar för att kortare iterationer är bättre. Här är några: Planering och redovisning går fortare, inte bara proportionerligt utan mer än så. En del estimeringsarbete försvinner och risken vid estimering minskar. Projektstatusen är överblickbar utan att ständigt behöva estimera återstående arbete. Möjligheten till omprioritering och nya tag nästa vecka skapar ett lugn och en flexibilitet hos produktägaren. Bäst är att kundansvarig kan välja att driftsätta en ny version varje vecka, om hon så vill. Snabbare ledtider kan översättas till mer nytta, lägre kostnader eller högre intäkter.

Finns det inga nackdelar? Inte vad jag har kunnat upptäcka, men däremot förutsättningar och om inte förutsättningarna är uppfyllda så kommer du att få problem. Här är några förutsättningar: Ni är ett komplett, tvärfunktionellt team med både personer som arbetar med behov och personer som arbetar med lösning. Ni är samlokaliserade. Ni har ett moget, driven team med goda kunskaper i agil metodik, stor disciplin och vana med tidsbegränsade möten. Ni har automatiserade byggen och leveranser av system som är minimalt kopplade till varandra.

Så... om tremånadersiterationer är bättre än ett år långa, treveckorsiterationer är bättre än tre månader och en veckas iterationslängd är bättre ändå, varför sluta där? Det är en relevant fråga. Om vi kan leverera på en vecka, varför inte varje dag? Eller, i förlängningen, kontinuerligt. Leveranser som en ständig ström av kontinuerligt värdeskapande. Ja, varför inte?

Ledare: Generalister och specialister

En av många aspekter vi måste tänka på när vi sätter ihop högpresterande utvecklingsteam är om vi vill ha generalister eller specialister i dem.

Spontant tror jag att många säger: specialister! Fördelar med dem är förstås att de har specialistkunskaper inom exempelvis en teknik. Teamet kan alltså snabbare komma till en vackrare lösning. Problemet är att systemutveckling idag är så komplext att du skulle behöva 20 specialister för en vanlig webbapplikation, vilket man normalt inte har råd med. Följden blir att vissa kompetensområden gapar tomma, vilket kan få allvarliga konsekvenser.

Utpräglade specialister har en tendens att inte vilja gå utanför sitt område - och inte heller släppa in någon annan på sitt område. Enbart en specialist kan säga: "Ok, teamet hann inte med alla sina uppgifter, men jag blev i alla fall klar i förrgår". Specialister är sällan lagspelare och kan vara svåra att leda och arbeta med.

Fördelar med generalister är förstås att de är breda. Generalister har ofta en härligt attityd av "hur svårt kan det vara" som gör dem enkla att leda och samarbete med. Den stora nackdelen är att de inte är utsökt bra på något. Utan specialister blir team långsamma och designen ofta inte vacker.

Men nästan ingen är total generalist eller specialist. De flesta är en blandning av båda, med läggning åt endera håll. Men det finns också två specialformer som jag vill ta upp: Specialiserade generalister och generaliserade specialister. Och båda dessa typer passar utmärkt i utvecklingsteam!

En specialiserad generalist är en generalist som har specialstuderat ett ämne att bli specialist inom. De är ovanliga men förekommer. Det kan till exempel röra sig om en projektledare som tvingats bli duktig på kravanalys i ett projekt och som sedan hittat en ovanlig niche. De måste fortsätta att ständigt arbeta med sitt ämne för att behålla spetsen, vilket egentligen inte ligger i deras natur. Dock kompenseras detta av att de ofta mycket ambitiösa.

En generaliserad specialist är en specialist som även lärt sig att tänka som en lagmedlem och är öppen för att lära sig nya saker. Kan en testexpert lära sig grunderna i programmering? Kan en interaktions­designer bidra vid testningen? Självklart! Möjligheterna att bygga högpresterande team är stora med denna typ då de även kan se helheten och stötta varandra, vilket bygger bra team. Sträva efter att ha merparten av dina team befolkade med dessa guldkorn. Och du som individuell specialist gör gott i att även kunna grunderna i områden utanför ditt eget.

Ledare: Varför inte utkontraktera hela verksamheten?

Det har talats mycket om utkontraktering de senaste åren. En allt större del av organisationers verksamhet, till exempel mycket som rör IT, utkontrakteras och det verkar väldigt klokt. Eller?

Ett orosmoln är att vi till varje pris vill undvika att utkontraktera just det som definierar oss, våra kärnkompetenser. Enligt allmän praxis på området är det istället stödtjänster till verksamhet som på ett tydligt sätt kan avskiljas från densamma lämpliga kandidater för utkontraktering, till exempel revision. Men vad händer om vi i vår iver att effektivisera faktiskt råkar utkontraktera kärnverksamhet?

Idag känns det ofta svårt att skilja datorn från verksamheten. I dagens välutvecklade företag har datoriseringen gått så långt att i stort sett alla processer görs med datorstöd. Som en följdsats av detta måste systemen utvecklas och förvaltas i ett nära, dagligt samarbete mellan de som behöver tjänsterna och som vet hur verksamheten fungerar och de som kan utveckla och leverera desamma. Att utkontraktera systemutveckling är en riskfylld väg som bland annat omöjliggör detta kritiska samarbete.

För att utnyttja det värde som lagts ned på utvecklingen av systemen måste användarna förstå och använda systemen. För att kunna fungera tillfredsställande måste IT-supporten finnas nära användarna. De måste känna användarna och vara experter på situationen på just ditt företag för att fungera bra. Att utkontraktera IT-supporten omöjliggör detta.

Idag är IT-systemen verksamheten. Att utkontraktera utvecklingen, förvaltningen och supporten av dessa är i stort sett identiskt med att utkontraktera själva verksamheten. Många möjligheter att skapa inkomstbringande och arbetsbesparande smarta verktyg går helt enkelt förlorade. Man kan i så fall faktiskt fråga sig varför organisationen överhuvudtaget existerar.

Ledare: Massanvändningsfaror

Agile är på väg att ta över som det dominerande tankesättet ute i projekten. Massanvändning. För oss som hållt på med det här ett tag låter ordet både underbart och skräckinjagande. Det är naturligtvis härligt att folk och företag (äntligen) börjar ta till sig idéerna och gilla det. Det är ju det vi har arbetat för i många år. Men det är otäckt när man vet att folk kommer att misslyckas med sina projekt ändå och leta efter syndabockar.

Fler projekt innebär också fler misslyckanden, det är ju ren statistik. Och det är lätt att skylla ifrån sig på metodiken. Jag gissar att vi snart kommer att höra om projektet som visserligen samlar 35 personer en timme varje morgon men som menar att de fick sluta med Scrum för att det var för mycket mötestid (hm, det låter inte som Scrum). Snart kommer vi att höra från programmeraren som visserligen tvingats sitta och programmera med sin dryga kollega dag ut och dag in, men som nu klagar över hur dåligt det är med parprogrammering (nej, i parprogrammering byter man partner ofta). Snart dyker den där missnöjda kunden upp som visserligen inte varit närvarande vid projektet, men som gett tydliga instruktioner för "...vad vi ville ha och som leverantören inte verkar ha förstått trots att de håller på och är aijaila, eller vad det nu heter" (nej, vi behöver en engagerad kundrepresentant).

Det här är intressant. De lättrörliga metoderna är faktiskt de första utvecklingsmetoderna som inte försöker sätta sig själva i centrum av världsbilden och faktiskt hävdar att människorna i projektet faktiskt är den ojämförligt viktigaste faktorn för ett lyckat result. Metodiken ska vara ett lätt stöd och sedan hålla sig ur vägen. Det borde vara svårt att skylla på något som mest försöker hålla sig undan, men det kommer inte att spela den minsta roll för de här människorna. Att Agile handlar om att ta ansvar för sig själv och sitt projekt verkar ha gått dem förbi.

Ledare: Ful-Agile

Ganska många organisationer säger sig idag ha anammat lättrörliga arbetssätt. I en internationell undersökning från 2006 av 722 organisationer, stora som små, svarade 84% att de "arbetade lättrörligt". Men kan man tro på den siffran? Knappast.

Inte för att de skulle ljuga, de har säkert gjort minst ett officiellt lättrörligt projekt, utan för att detta knappast innebär att deras personal har agila värderingar och attityder. Och det är det som Agile till syvende och sist handlar om. Det är dessa redskap som hjälper oss i alla dagliga beslut när arbetssätt och praxis inte räcker till. Annars blir det mest "Ful-Agile".

Låt mig ge några exempel: Du vet att någon inte förstått Agile när utvecklaren utbrister: "Jag kan inte jobba med det här, det är för dåligt specat". För det första, vi "specar" inte i lättrörliga metoder, vi föredrar kommunikation ansikte mot ansikte. För det andra, med denna mening frånsäger sig utvecklaren allt eget ansvar och initiativ. Det här luktar lite babyprogrammerare som förväntar sig bli skedmatade med specar för att sedan rapa upp en illaluktande kodsörja (om liknelsen ursäktas).

Du vet att någon inte i grunden förstått lättrörligt när de gör något som alla ingenjörsmässigt inser är dumt och säger "Men kunden har ju sagt det". Detta är också en abdikering från allt ansvar. Var är yrkesstoltheten? Ditt ansvar som expert är att berätta för kunden om risker och konsekvenser med olika beslut, bistå kunden tekniskt, kanske till och med vägra om det är alldeles på tok.

Du vet att folk inte har snappat vad det handlar om när man ser sig som ägare för olika delar av ett system (systemet är allas ansvar), när man inte avlastar varann och hjälper varann (vi är ett team med samma mål) eller när man ser iterationens krav som godispåsar som man bara kan plocka det gottaste av (vi åtar oss att leverera inkrement med korta, regelbundna intervaller).

Ovanstående exempel är inte Agile - det är Ful-Agile och måste som sådan bekämpas. Hur är det på ditt företag, kör ni Agile eller Ful-Agile?

Ledare: Är vi rädda för användare?

Ibland börjar jag tro att systemutvecklingsteam är rädda för användare. Jag har sett allt för många utvecklingsprojekt som inte tar in återkoppling från verkliga användare i tillräckligt hög utsträckning och i rätt tid. Att produkten/systemet ska användas av någon verkar vara något vi utvecklare bara är vagt medvetna om och helst duckar för ända till slutet av projektet. Och vi kan skämta hur mycket som helst om dåliga gränssnitt till våra dvd-apparater hemma - ändå gör vi ständigt samma fel själva. Varför har vi så svårt att släppa in användare till våra system? Vad är vi rädda för?

Redan innan utvecklingen av ett system drar igång måste givetvis systemets roll i organisationen klaras ut. Det finns inget "oagilt" i detta. Vi måste ha en gemensam vision att arbeta mot. En interaktionsdesigner som studerar hur folk arbetar och som med workshoppar och andra tekniker hjälper oss att extrahera och formulera en vision, roller och mål för systemet är guld värt senare.

Precis som all annan design under projektet måste även interaktionsdesignen förfinas iterativt. Den får inte vara allt för framtung. Mitt råd är att låta en interaktionsdesigner ingå i teamet från start. De fungerar inte bara som experter på design för användning utan också som en slags medlare mellan användare och system. Det gör det lite enklare att använda användare som testgrupp för tidiga releaser av systemet.

Till sist, riktigt bra feedback får vi först när någon börjar använda systemet på riktigt, dvs i sitt jobb. Då blir garanterat alla skavanker plågsamt tydliga. Agil metodik föreslår därför att inte vänta till projektslutet med att driftsätta, då utvecklare är på väg att bli "avvecklare". Driftsätt tidigt en liten kärna av god kvalitet som kan börja skapa värde i organisationen. Leverera därefter nya versioner i den takt som organisationen orkar med.

Användare är en underutnyttjad resurs på vägen mot att skapa bättre IT-system.

Ledare: Projektledaren är död - leve projektledaren

Det här med Agile kan låta skrämmande för somliga projektledare (PL). Om jag inte får planera projektet, vad finns då kvar av mitt jobb? Om jag inte ska styra vad folk gör, vem skulle då att göra det?

Svaret på dessa frågor hittar vi om vi går tillbaka till den ursprungliga tanken med en projektledare, dvs en ledargestalt för projektet. PL bär projektet på sina axlar, men inte genom att peka med hela handen utan genom att gå före, uppmuntra och föregå med gott exempel. En del PL idag verkar tyvärr ha glömt bort detta och fungerar mest som projektadministratörer.

För att lugna alla PL direkt, mycket ansvar ändras inte alls. Precis som det alltid har varit är PL den som rapporterar till kund och andra intressenter. Som alltid är PL den som berättar vitt och brett om det fantastiska projektet. Och det åligger givetvis PL att se till att all administration och möten i projektet flyter smidigt.

I några viktiga fall övergår en del ansvar till teamet, till exempel att ansvara för planeringen. Men glöm inte bort att det är PL som ser till att planeringen blir gjord som den ska och att den följs upp av teamet.

Så vad gör då en agil PL? Ja, en riktig, agil PL är först och främst den som bär projektvisionen, den som kan projektet och dess mål på hög nivå på sina fem fingrar. Och då och då påminner teamet om dessa.

En annan oerhört viktig sak är att vara den som ser till att teamet mår bra och att medlemmarna i teamet lär av varandra och växer som människor. Ett team som mår bra och är engagerade är de som gör bäst jobb, så enkelt är det ju.

En tredje sak att nämna är att se till att samarbetet mellan teamet och kundrepresentanten flyter smidigt. Allt för många bygger medvetna hinder mellan de som vet vad och de som vet hur.

Visst är det en omställning för många PL att leda ett agilt team kontra ett traditionellt. Och alla klarar inte av omställningen till att bli en bra ledare. Men för de som klarar det väntar ett mycket mer givande arbete. Att sporra ett team att skapa en succéprodukt, istället för att vara slavdrivare. Att vara en ledare är att ansvara för liv, inte mycket kan väl kännas viktigare?

Jag ser fram emot att arbeta med er projektledare därute - i ordets rätta bemärkelse.

Ledare: Jympa för projektplaner
eller Hur man håller sina planer i trim

I min förra ledare tog jag upp en del problem som ibland uppstår i spänningsfältet mellan projektledaren (PL) och dennes utvecklingsteam: Att planera utveckling är svårt och planen blir snabbt felaktig, risken för förskönande kommunikation är överhängande och teamet känner inte det rätta engagemanget för helheten. Det finns motmedel för alla dessa problem.

Till att börja med, planera på lång sikt (3-6 mån) enbart på hög nivå. Detaljplanera bara för nästa, korta projektetapp (iteration) precis när den ska till att börja. En iteration bör vara 1-4 veckor. Det här minimerar slöseri i form av omplanering och maximerar er flexibilitet. Varje iterationsplan är en stegvis förfining av en initialt skissartad plan.

Som nästa steg, låt PL ägna sig åt den övergripande planeringen, mål och vision. Ansvar för detaljplanering i varje iteration övergår istället till teamet. Teamet är de enda som har en rimlig chans att få fram vad som kommer att behövas för att realisera kommande funktioner. Ni kommer också att märka att teamets engagemang stiger påtagligt av detta.

Till sist (och svårast), ändra din attityd till planer. Börja betrakta ändringar i projektplaner som förväntade - och ibland till och med önskvärda. Hur kan en önskvärd förändring se ut? Till exempel att prioritera ned en funktion som ni nu insett var helt onödig och bara skulle kosta pengar.

Leverera sedan regelbundet uppdaterade, aktuella planer på hög nivå till projektbeställarna. Lär dem att förändring visserligen är att vänta, men att de från och med nu alltid kommer att få aktuell information. Kloka beställare gillar detta. Det finns nämligen bara en sak som är värre än att få dåliga nyheter - att få dåliga nyheter när det är för sent att göra något åt dem.

Den något paradoxala effekten av att släppa något på den uppfattade kontrollen blir att PL faktiskt får verklig kontroll eftersom planen nu är uppdaterad och verklighetsbaserad.

I många fall är ditt inte ens fel att två träter. I det här fallet ofta inte ens någons fel. Problemet ligger mer i en felaktig ansvarsfördelning kopplat till en dålig beredskap för förändring.

Nästa ledare kommer att behandla frågan: Vad gör jag som projektledare om jag inte får planera längre?

Ledare: Utvecklingens sanna natur

I denna ledare vill jag fokusera mer på projektplanen och de perspektivklyftor som alltför lätt kan uppstå mellan en projektledare och hennes utvecklingsteam.

Idag är det vanligt att projektledaren tar på sitt ansvar att planera, följa upp och styra teamet. Det är det våra gröna projektledare får lära sig på så gott som samtliga PL-kurser idag. Men är det verkligen projektledarens jobb att göra detta i ett utvecklingsprojekt?

Projektledaren har för det första inte detaljkunskapen som krävs för att förstå vilka aktiviteter som bör göras. Detta beror främst på att hon inte är aktiv i projektet. Hon måste istället fråga någon som vet, dvs teammedlemmarna. Dessa kan dock vara motvilliga till att hjälpa till - ofta på goda grunder. De har kanske blivit brända tidigare. De vet att det de säger kommer att hållas emot dem vid nästa uppföljning. Varför sticka ut hakan? Det här gör dock att utvecklarna tyvärr inte känner något större engagemang för planen. Den upplevs som något som "PL har kokat ihop och som blir fel imorgon". De undrar varför de ska bjuda på sin tid och kraft åt "hennes plan"? Är det det bästa de kan göra av sin arbetstid?

Även om projektledaren är väldigt skicklig och lyckas lirka några svar ur utvecklarna - om hon frågar ett par veckor in i arbetet får hon troligen tämligen annorlunda svar. Med mer information justeras teamets tänkta väg. De har hittat snabbare, grundligare, bättre sätt. Det här leder ofta till gruvliga konflikter.

Det förekommer i det läget tyvärr att projektledare vidhåller den ursprungliga planen. Planen och verkligheten avviker sakta från varandra, men mot styrgrupp och ledning är det bara planen som kommuniceras. Eftersom ändringar i planen återfaller negativt på projektledaren kan det vara svårt att stå emot detta. Det är dock receptet på katastrof. Någon gång i framtiden krossas naturligtvis illusionen, gärna sådär härligt sent i projektet när det är för sent att rätta till.

För att sammanfatta: Ansvaret för att detaljplanera ligger hos fel roll, att planera rätt är väldigt svårt och planen blir snabbt felaktig, risken för förskönande kommunikation är överhängande och teamet känner inte det rätta engagemanget för helheten. Pust!

Roten till allt detta ligger i själva naturen för utvecklingsarbete. Sådant är i grunden utforskande och experimentellt samt uppvisar hög grad av förändring. Går man ner på en rimlig detaljnivå är aktiviteterna i ett komplext utvecklingsprojekt omöjliga att korrekt förutse innan utvecklingsarbetet börjar. Det är inte det att vi nödvändigtvis är dåliga på att planera, det går helt enkelt inte.

All denna förändring gör att vi måste göra upp med våra gamla attityder till projektplaner. Istället för att se en förändring som ett fel i en färdig plan kan vi välja att se en förändring som en gradvis förbättring till en initialt skissartad plan. Det här är en mental omställning som kan ta åratal att göra, men vi måste.

Det finns sätt för att komma runt alla de problem jag beskrivit ovan, vilket blir temat för min nästa ledare. Och de förändringar som behövs grundar sig på verkligheten, på systemutvecklingens sanna natur.

Ledare: Tekniskt mumbo-jumbo

Jag har varit i ett antal systemutvecklingsprojekt där projektledaren inte kan teknik. För någon utanför vår underbara IT-värld må det låta konstigt, men det är faktiskt inte ovanligt. Och det går tyvärr lika fel varje gång. Projektledaren förstår kanske inte vad som utförs i projektet eller ens varför det utförs. Och när teamet slänger den ursprungliga idén för att gå en bättre väg blir projektledaren mycket upprörd: "Jag vill veta varför ni inte gör som vi har kommit överens om. Ni håller ju inte Planen!". Utvecklare kan å andra sidan visa stor oförståelse för varför någon måste lägga sig i deras projekt. Pengar, kontroll, styrning, vad är det?

Men låt oss slå fast en gång för alla: Ska man deltaga i, eller till och med leda, ett tekniskt projekt är det mycket svårt utan en viss teknisk kompetens. Punkt slut. Det går helt enkelt inte att "bluffa" till sig ett språk om man saknar den underliggande förståelsen. Att tillsätta en projektledare utan rätt tekniska förståelse och bakgrund i ett supertekniskt projekt är ju rent dilbertskt (dvs ett asgarv för alla som befinner sig utanför projektet). Det är inte rättvist mot vare sig teamet eller projektledaren.

I mycket stora projekt, som består av flera delprojekt, minskar givetvis behovet av teknisk sakkunnighet ju längre man befinner sig från skyttegravarna. Men om du arbetar i en teknisk branch, är det då orimligt att tänka att det kanske är din skyldighet att kunna så mycket teknik som tjänsten kräver? Jag vill gärna slippa höra ännu ett "ja, jag är ju inte någon teknisk person...", tack. Kan det vara så att den rent administrative projektledaren gjort sitt som projektledare över mindre utvecklingsprojekt?

Ledare: Mentala låsningar

I vår kultur, speciellt den mer USA-inspirerade, dyrkas besluts­mässigheten som det yttersta beviset på ett starkt ledarskap. Och visst ligger det en del i det. Kanske har vi svenskar ibland en viss oförmåga att våga gå vidare. Men detta bör enligt min mening inte betyda att snabba beslut alltid är något bra.

Grundproblemet med snabba beslut är att när vi väl har fattat beslutet så har vi inte bara låst in oss politiskt, utan framför allt mentalt. Vi slutar helt enkelt att leta efter alternativa lösningar och vi har ett mycket starkt motstånd till att ta upp problemet igen. "Det här har vi ju redan talat om och då beslutat..."

Inom området system- och produktutveckling, som karaktäriseras av en hög grad av upptäckande, lärande och förändring, kan en tidig inlåsning snarare ställa till mycket problem. Om vi fattat beslut (låst in oss) hittar vi förstås inte de bättre lösningarna när sådana dyker upp.

Inom Lättrörlig (agil) systemutveckling talar vi om principen att "fatta beslut så sent som ansvarsfullt möjligt". Med det menar vi att vi försöker se till att fördröja alla beslut som inskränker vår flexibilitet så länge vi bara kan. Varför? För att vi då har de absolut bästa underlagen för besluten. Då brukar vän av ordning invända att det där "inte fungerar hos oss". Man känner att man måste fatta beslut om det ena eller det andra. Då glömmer vän av ordning ofta den andra delen av principen. Om man av någon anledning verkligen måste fatta beslutet under den andra veckan av utveckling så är det ansvarsfulla just att fatta beslutet då.

Börjar vi rannsaka våra beslut upptäcker vi dock att vi faktiskt kan vänta med mer än vi tror. Av gammal vana tror vi kanske att databasens design måste vara klar tidigt i projektet. Men idag finns det faktiskt metoder för att låta databasdesignen utvecklas i takt med det övriga systemet utan större omvägar.

Slutsats: Se gärna helheten (visionen) från början, men vänta med detaljerna tills dess att du ansvarsfullt måste.