Bulle

Henrik Kniberg skriver på sin blogg om bull-protokollet. Det kanske kan kännas lite överspänt, men om det funkar så löser det det vanliga problemet att saker ramlar mellan olika typer av sittmöbler och blir liggande på golvet tills bullbagaren tröttnar på att bullen ligger på golvet och samlar damm och torkar.

Kusinen från landet

Är jag taskig om jag kallar Agile för Leans kusin från landet? Eller Scrum för Kanbans? Det är väl inget fel på landet? Sure, folk luktar dynga, lyssnar på Basshunter och kör traktor, men vi behöver fortfarande jordbrukare för att påminna oss om vårt förflutna och för att slänga EU's budget på.

Scrum var säkert bra för 15 år sedan om man var van vid att ha 2 års releaser-cykler där allt var planerat på förhand. Eller fortfarande idag, i samma situation. Och ofta kan det säkert funka utmärkt att bestämma sig i förväg för vad man ska göra under de nästa tre veckorna, men det är svårt att se poängen. Varför ska man egentligen göra skillnad mellan produkt-backloggen och sprint-backloggen? Eliminera sprint-backloggen och du närmar dig Kanban. Eller strunta i det och kör dina små vattenfall.

Och behöver man kunna hantera saker som dyker upp under en iteration så får man använda workarounds, som att planera in slack för just sådana situationer. Men hela förplaneringsidén är stendöd för mig. Att sätta story points och mäta hastighet känns bara som ett dummare sätt att mäta flöde.

Jag ville bara ventilera lite.

Summering

Det var mycket som var bra på Atlassian Summit. Jag lärde mig en del nya makron som kan ha avgörande betydelse för att få till dokumentationen som vi vill ha den. Nya Green Hopper har ett par killer features (men kanske inte killer combinations). Jag var på några riktigt bra presentationer om Agile och en väl genomtänkt presentation om distribuerad versionshantering (git och Mercurial).

Hela evenemanget var riktigt bra, jag skulle säga att det var bättre än WWDC, som jag var på förra året. Det är mindre, så man lära känna folk på ett annat sätt. Maten var riktigt bra, festen var mycket trevligare, och jag och Gustav festade loss ganska bra både där och på efterfesten. Jag spelade biljard för första gången på typ 15 år.

Idag lyckades vi dessutom hitta det thailändska stället vi åt på förra året. Det ligger precis på gränsen till Tenderloin (knarkhandlare och sinnessjuka tiggare utanför). Vi har tagit en öl på fjolårets favorit The Hydeout. Vädret har varit jättebra, speciellt idag.

I övrigt vet jag inte riktigt, men jag är sjukt trött och måste sova nu. Guten nacht!

Da Scrumci-koden

Sedan urminnes tider har taskigt skrivna arkeologer spelade av Tom Hanks sökt den heliga graalen inom agile development-arkeologin: svaret på gåtan varför Scrum har trängt undan Extreme Programming. Givetvis handlar det om trender hitan och ditan, att IDG inte kan skriva om mer än tre saker i taget, men jag har under mystiska seanser fört samtal med andar, besökt idévärlden och ritat sanningstabeller och nått ett svar på gåtan.

Scrum är helt enkelt enklare att bända in i ett företag, eftersom det ser så harmlöst ut för de som bestämmer, d.v.s. de som har slips på sig och tänker med plånboken. "Visst, sure, ni utvecklare kan ju köra era iterationer och ha lite möten, det påverkar ju inte mig." Extreme Programming har inte bara ett lite läskigt namn (som dock kan låta lite hippt och edgy, vilket också har sina fördelar), utan ser ut budget-perspektiv livsfarligt ut. Par-programmeringen drar enligt enkel matematik ner produktiviteten till hälften, och kör man test-driven utveckling så lägger man lika mycket tid på att skriva testfall som att utveckla kod, vilket halverar produktiviteten en gång till.

Inget sådant i Scrum! Scrum ställer inga sådana krav på vad utvecklarna ska göra (parprogrammering och test-driven utveckling är dessutom bara en liten del av Extreme Programming, där finns en del som kan få slipsen att hicka till). Dessutom är det lätt att fuska med Scrum: finns det ingen på plats som förstår vad det handlar om så kan man lätt hoppa över retrospectives, reviews och till och med scrum, fippla med sprint-backloggen under pågående sprint, strunta i att ha produktägare eller scrum master, ha chefer som projektleder så att gruppen inte kan organisera sig själv etc.

Risken är dessutom stor att motståndet ökar om man inte kan få igenom förståelse för fördelarna med lättrörliga processer, vilket tvingar fram kompromisser. Grunden i Agile och Lean är att man förändrar saker som inte funkar som de borde. Förändring möter alltid motstånd. Motståndet kan leda till att Scrum-processen kvävs. Men man kan i alla fall skriva på företagets webbsida att man kör Scrum och att man har certifierat folk, så låter det som att man fattar vad som pågår.

De gamla rävarna som var med under den grå forntiden, för sådär 10 år sedan, får något nästan religiöst i blicken när de berättar om hur bra allt var när man körde Extreme Programming. Och jag tror att det finns goda anledningar till det: Scrum verkar enklare och möter mindre motstånd, men är svårare att lyckas med.

Följer man reglerna för Extreme Programming så får man mycket mer hjälp med det dagliga arbetet. Det går naturligtvis att kombinera Scrum och Extreme Programming, men det är inte så vanligt som det borde vara.

Sen kan man inte skylla allt på cheferna heller. Väldigt många utvecklare känner antingen inte till eller är skeptiska till refactoring, testdriven utveckling och parprogrammering. Men även om UML-nördarna kan dra sitt strå till stacken för att skjuta ner Extreme Programming så är jag övertygad om att det är Scrums falska smidighet som gör det så populärt.

Vilse i vattenfallet

När jag läste data runt 2000 så fattade jag ingenting av vad vi fick lära oss om processerna runt själva kodandet. På OS-kursen fick vi skriva en kravspecifikation och ett design-dokument, vilket vi skulle lägga lika mycket tid på som kodandet och testningen. Eftersom specifikationen naturligtvis visade sig vara omöjlig att implementera utan ändring så fick vi uppdatera den allt eftersom vi upptäckte problem. På kursen som hette Software Engineering så fick vi lära oss en väldig massa detaljer om metoder för att ta fram specifikationer av olika slag.

Jag vet inte riktigt var de här avancerade metoderna används, men jag föreställer mig att det rör sig om hemliga försvarsanläggningar, kärnkraftverk, banker och myndigheter. Jag kände absolut inte igen mig från de open source-projekt jag var bekant med. Däremot visste jag att akademiker var av uppfattningen att en utvecklingsmetod som den som användes för Linux-kärnan helt enkelt inte kunde fungera. Det gjorde att de inte kändes helt trovärdiga.

Agile fanns redan på 90-talet, och en gästföreläsare från Nya Zeeland la i alla fall någon föreläsning på att lära oss om Extreme Programming. Under 00-talet har Agile slagit igenom, men kursbeskrivningen för Software Engineering i Uppsala ser fortfarande ut som den gjorde för 10 år sedan. Samma kursbok används dessutom, Software Engineering av Ian Sommerville.

Jag tog fram mitt exemplar, 3 upplagor gammalt, och bläddrade lite i det. De avsnitt som innehåller något som jag skulle kunna tillämpa är minimala, om de finns över huvud taget. Jag kollade upp vad som har förändrats under de senaste upplagorna, och det verkade inte vara mycket, även om det har tillkommit ett kapitel som under rubriken "Rapid Software Development" bland annat tar upp Agile, exemplifierat av Extreme Programming.

Jag tittade igenom de slides som finns tillgängliga för nedladdning. Författaren är inte positiv till Agile. Agile används för att utveckla mjukvara fort, men leder till sämre kvalitet. Och det är svårt att testa, för det finns ingen specifikation. Det är svårt att avgöra vad som har gjorts, för det finns ingen dokumentation. Koden blir svår att underhålla, för om man gör ändringar hela tiden så går strukturen sönder. Principen att hålla designen så enkel som möjligt är också problematisk: "Maintaining simplicity requires extra work". Och så går det givetvis inte att skala upp Agile till större projekt: "Agile methods are probably best suited to small/medium-sized business systems or PC products." Damn, den gamla klassikern, riktig utveckling sker på mainframes. Hemliga försvarsanläggningar och banker var det.

En av anledningarna till att Agile har tagit över under de senaste 15 åren är att all utveckling inte längre sker på storföretag eller myndigheter. Utvecklarna har makt över sin situation, snarare än att det är en kille i slips sju nivåer upp från närmsta ingenjör i hierarkin som bestämmer hur det ska gå till. Men bland de gamla akademikerna så skrivs fortfarande all riktig kod i Cobol och Ada, och handlar om pengatransaktioner. Designspecifikationen specificerar arkitekturen hela vägen ner till algoritmer och datastrukturer. Programmeraren översätter specifikationen till program. Moduler utvecklas parallellt och integreras först framåt slutet av projektet, precis innan den livströtte testaren kallas in, hittar fel och får skäll för att han är ansvarig för att projektet blir försenat (han gästföreläste på Software Engineering-kursen, och beskrev sitt arbete just så). För projektet blir försenat, det blir det alltid. Och lösningen heter ännu mer detaljerade specifikationer, som gärna ska verifieras formellt, så att den kan implementeras rätt av utan att en enda bugg uppstår, att ett enda krav ändras under projektets gång eller att ett enda tankefel upptäcks.

Ett problem jag hade både med Software Engineering och på andra kurser var att det aldrig berättades hur, var och när saker tillämpas. Idéerna är alltid abstrakta. Av den anledningen vet man inte vad som är viktigt, vad man faktiskt ska lära sig, och vad man kan glömma bort, eftersom det bara är av akademiskt intresse.