Ladok + agilt = labilt

Agile, Lean, Scrum, Kanban, Scrumban. Det är mycket nu. Känner du att du inte har hängt med riktigt, att ert projekt arbetar efter gamla mossiga metoder? Att ni inte arbetar agilt?

Don't Panic
www.flickr.com/photos/norrix/

Ni kan också arbeta agilt. Alla kan arbeta agilt. Så här gör du:

Skriv “vi arbetar agilt” i något “dokument”. Spara.

Projektet ska arbeta enligt en agil utvecklingsmetod i genomförandefasen. Den agila utvecklingsmetoden ställer krav på löpande och snabb kommunikation mellan verksamhetsrepresentanter och utvecklingsteamen.
Projektplan Ladok3

Det var väl inte så svårt? Kan ett projekt i halvmiljardklassen så kan du.
Om man måste arbeta efter några särskilda principer?
En gång trodde jag det, men jag har insett hur fel jag har haft.

Agila metoder på KTH

Här i Infosysgruppen på KTH har man sedan ganska många år arbetat med agila metoder och lean. Vi har som många andra vandrat Scrum->Kanban->Scrumban och har lite olika anpassad metodik i olika projekt. I vissa arbetar vi efter mer strikta sprintar som Scrum, i andra mer flödesorienterat som i Kanban. Systemdriften på IT-avdelningen på KTH har nyligen börjat experimentera med Kanban i sin verksamhet.

Vi är inte renläriga, vi är inga evangelister, vi har stött på problem och behövt arbeta oss runt dem, men det har fungerat bra för oss och verksamheten runt om kring oss som också har stort förtroende för arbetssättet. Därför föll det sig naturligt för KTH att önska ett agilt tillvägagångssätt i Ladok3.

För oss betyder agilt någonting

När KTH uttryckte önskemålet betydde det någonting. Agila metoder kommer i många smaker. Tyvärr verkar många idag tro att agilt är ekvivalent med Scrum, och att det som definierar en agil metod är att man har de olika rollerna, produktägare, scrum-master, team och andra artefakter som scrum-tavla, back-log, burn-down osv.

De sakerna är Scrum. De har lite eller inget med agilitet att göra. Mycket av det är inte ens särskilt unikt för Scrum utan återfinns i andra metoder av vilka en del inte är agila alls. Agila metoder handlar om ett antal kärnvärden beskrivna i det agila manifestet som lämnar en del utrymme för tolkning. Bakom dessa ligger i sin tur tolv principer för hur kärnvärdena ska realiseras. Dessa värden och principer ligger till grund för bland annat Scrum.
Den första principen lyder:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Principles behind the Agile Manifesto

Uttryckligen är alltså den högsta prioriteten i ett agilt projekt att tidigt och kontinuerligt leverera värdefull programvara. Vad är då tidigt, kontinuerligt och värdefullt i sammanhanget? Nyckeln är värdefullt. Hur vet man att det teamet producerar är värdefullt? Svaret är att man inte gör det. Beställaren förstår kanske inte ens själv problemet fullt ut eller är kapabel att uttrycka det på ett tillräckligt tydligt sätt. Därför prövar man genom att levera något till den faktiska verksamheten för att utvärdera, på riktigt, om det verkligen var värdefullt, lär sig av det, går tillbaka och börjar nästa iteration berikad av erfarenheten.

Working software in the hands of the user.
8 Principles of Continouos Delivery

För att denna feedback-loop ska fungera måste man börja tidigt. Itererar man “tidigt” blir det kontinuerligt. I allmänhet brukar man tala om att man bör komma ner i iterationer om ett par veckor. I undantagsfall kan man behöva lite längre perioder, ibland kan det vara effektivt med kortare.

You might think that puts us in an impossible position when it comes to deciding how to run teams. But consider why software development is not a regular environment, and why it is so hard to run experiments, to acquire skills, and to measure which practices and decisions lead to success, and which to failure. The root cause in all these cases – the reason the environment is not regular – is that the feedback loop between making a change and understanding the result of that change is too long.
Why software methodologies suck

Poängen med att arbeta på detta sätt är att man reducerar risk. Man minskar risken för att teamet springer iväg och spenderar en massa tid och pengar på något som sedan inte visar sig vara det som verksamheten behövde. Med kontinuerliga leveranser minskar man också risken för att projektet inte har lyckats åstadkomma något av värde alls om pengarna skulle råka ta slut på vägen eller avbryts av andra skäl. Ju längre tid man inte levererar något som kan prövas i verksamheten, desto större risk.

Så när KTH sa att man ville att Ladok3-projektet arbetade efter en agil metod var det inte precis dagliga stand-ups och parprogrammering vi tänkte på, utan det fanns ett antagande om att detta innebar att man utgick ifrån nuläget och successivt arbetade sig därifrån till Ladok3 i kontinuerliga leveranser så att vi kunde följa och dra nytta av progressen.

Principle 1: Low Risk Releases Are Incremental
Any organization of reasonable maturity will have production systems composed of several interlinked components or services, with dependencies between those components. … Upgrading all of those components in one big-bang release is the highest-risk way to roll out new functionality.
Four Principles of Low-Risk Software Releases

Gissa om vi blev förvånade.

Agilt enligt Ladok3

Den första iterationen i Ladok3 är inte ett par veckor. Inte tre. Inte fyra. Inte heller ett par månader. Den är två och ett halvt år. Så första gången vi faktiskt prövar något i verksamheten och kan ge riktig återkoppling, prövad i strid, är efter 180 miljoner kronor av utveckling. Ändå kan man ifrågasätta om det man levererar överhuvud taget alls representerar något värde eftersom den funktion man levererar redan finns i produktion idag. Som test betraktat är det blekt då det bara är en del av systemet som rör användare.


PM Migrering till Ladok3 - hörde jag vattenfall?

Jo förresten. Man tänker sig att göra leveranser. Ja, inte varannan vecka eller så, men kanske halvårsvis, till en parallell testmiljö som inte har med verksamheten att göra. Man tänker sig alltså kunna bygga en fungerande, om extremt långsam, feedback-loop i en parallell testvärld, bredvid det ordinarie arbetet. För att verifiera den och kunna återkoppla ska alla universitet torrsimma genom att utföra arbete dubbelt. Dels i verksamheten, dels i en testmiljö där man inte har en aning om vad som eventuellt fungerar och som inte tillför något värde. Hur skulle det upplägget möjligtvis kunna fallera? Det kan inte vara så att vi har något annat att göra?

I själva verket är det här kombinationen av det sämsta av alla världar. Eftersom man arbetar agilt finns det ingen planering för vad man ska göra att tala om. En av anledningarna till att man använder sig av agila metoder är att det är svårt eller omöjligt att förutsäga vad man kommer att behöva så lång tid framåt och därför bara planerar lite i taget, återigen för att minska risken för bortslösat arbete pga ändringar i planen. Täta leveranser med små förändringar skulle uppväga för det, men samtidigt tänker Ladok3 inte leverera något universiteten kan använda och ge återkoppling på förrän efter mycket lång tid.

Bristen på planering i Ladok3 gör i det här läget att universiteten saknar möjlighet att planera sin verksamhet för de omfattande förändringar som varje leverans innebär och våra möjligheter att följa upp, påverka och kontrollera progressen i projektet på något som helst meningsfullt sätt blir i realiteten obefintliga.

I botten finns förstås problemet att man valt vägen att skriva om systemet ifrån scratch. Per definition innebär det att det kommer att dröja mycket, mycket lång tid innan projektet levererar något värde till verksamheten. Alls. Det kanske aldrig gör det.

Det är obegripligt hur någon kan påstå att detta är agilt.

Scrum 2

Jag dryftade dessa bekymrade tankar en gång med en person inblandad i projektet och fick lite oväntat mothugg. Det var inte alls centralt med täta leveranser till verksamheten i agila metoder och man hade tonat ner värderingarna och principerna i det agila manifestet i Scrum 2.

Där fick jag. Jag blev, för en gångs skull, stum. Inte för att jag är en kung inom agila metoder men jag har arbetat både med sådana och mer traditionella metoder i ganska många år och trodde att jag hade lite koll, men här har det flutit upp nya icke-agila agila metoder som jag helt har missat.

Jag smög mig ut med svansen mellan benen och googlade: “Scrum 2″Scrum2“Scrum II”“Scrum 2.0″, “Scrum Two” … jag är värdelös. Någonstans därute under radarn finns en helt ny paradigm inom Scrum med helt andra värderingar. En så fundamental ändring borde rimligtvis ha lämnat lite spår, men jag kan inte hitta dem. Var hittar jag denna icke-agila agila metod trovärdig nog att sätta en halv miljard på?

Först senare insåg jag att han kanske bara drev med mig. I så fall var det briljant.

Eller så inleder Ladok3 en ny era med en, kanske ändå inte helt, ny paradigm - Labila metoder.

 

Liksom det tidigare inlägget, “Hur en halv miljard, av dina pengar, går upp i rök”,
är detta i sak i linje med det KTH sedan länge har uttryckt både formellt och informellt.
De mer frivola och tillspetsade formuleringarna får jag däremot stå för själv.

/Fredrik

PS. Sedan inlägget först publicerades har jag uppdaterat inlägget med några referenser eftersom några uttryckte tvivel om detta var möjligt.  Och den första iterationen är inte längre två och ett halvt år. Den är tre år. Genomförandefasen har knappt börjat och är redan försenad…

2 reaktion på “Ladok + agilt = labilt

  1. Rasmus Kaj

    Jag tror du har gåtans lösning redan i första meningen på det du citerar från projektplanen:

    Projektet ska arbeta enligt en agil utvecklingsmetod i genomförandefasen

    Jag misstänker att det i klartext betyder att utvecklarna ska arbeta agilt jäntemot något av de lager av proxybeställare som utgör större delen av de personer som hittils verkar ha varit inblandade i ladok 3.

    Från utvecklare till styrgrupp ska det vara täta leveranser, eftersom man inte litar på att utvecklarna begriper vad systemet ska vara bra för. Från styrgruppen ut till administratörerna på universitet och högskolor och därigenom så småningom ut till lärare och studenter behövs det dock bara en leverans, eftersom administratörerna ju vet vad de håller på med och styrgruppen betraktar sig själv som ofelbar.

  2. Fredrik Jönsson Inläggsförfattare

    Nja, jag tror att det agila i ganska hög grad kom in av lärosätenas önskningar, men att man tänker att det räcker med att man levererar till test-miljön. Jag kommer återkomma lite mer till det.

    Och i realiteten kan man nog inte göra så mycket annat, eftersom det hela skar snett redan då man bestämde sig för att skriva ett nytt system ifrån scratch. Det beslutet är så fundamentalt anti-agilt att det inte går att förena med en agil metodik, men det försöker man dölja, eftersom det ju är det som man i projektets sida vill över precis allt annat.

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *

Följande HTML-taggar och attribut är tillåtna: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Current day month ye@r *