Skip to content

Henrik Kniberg's blog
Syndicate content
from the Crisp Consultants
Updated: 29 min 2 sec ago

Spotify Engineering Culture (part 1)

Thu, 03/27/2014 - 10:12

Here’s a short animated video describing Spotify’s engineering culture (also posted on Spotify’s blog).

This is a journey in progress, not a journey completed, and there’s a lot of variation from squad to squad. So the stuff in the video isn’t all true for all squads all the time, but it appears to be mostly true for most squads most of the time :o)

Part 2 hasn’t been recorded yet. Stay tuned.

Categories: Blogs

Keynote slides from my Passion for Projects keynote

Tue, 03/11/2014 - 19:46

Here are the slides for my Passion for Projects keynote Spotify – the unproject culture (+ failure story “How to burn €1 billion”).

So, now I’ve spent 2 days with 600 projects managers at a PMI conference. Totally different from the usual crowds I hang out with. Fascinating to hear stories about project management successes and failures in all kinds of industries – from warzone reconstruction projects to eurovision song contest.

I was a bit nervous (OK more than a bit) getting up at the biggest-ever scandinavian gathering of project managers – and illustrating to them how the standard project model really doesn’t fit well for IT product development, and how companies like Spotify actually don’t have PMs and don’t do projects (at least not the type defined by PMI)

I was happily surprised though. Instead of getting attacked for it, scores of PMs came up to me, agreeing with me, sharing similar experiences, and inspired to try agile principles in their own projects and industries.

And biggest positive surprise of all – the final keynote by Dr. Harold Kerzner, major thought leader in PM space who has written over 50 college textbooks on project management! He listed like 30 things that are wrong with traditional project management as tought in PMI textbooks, and where it all is heading in the future. He described it as a fundamental paradigm shift from PM 1.0 to PM 2.0.

According to Dr Kerzner, agile values and methods like Scrum are examples of the future of project management, and I was positively surprised at how well his description of PM 2.0 rhymed with agile values.

So what I saw was convergence – experts and practitioners arriving at the same conclusions, coming from lots of different directions. A magical feeling.

I’ve suspected it before, but talking to all these experts has made it clear to me – agile is a universal thing, way beyond just software.

I’m so glad I took the courage to get out of my comfort zone and meet these people. I wish more agile trainers and coaches would get out of the echo-chamber of agile conferences and see what’s going on in the wider world :)

(some sample slides from my talk below)

what-is-success

lessons-learned-pust

Project model

release must be easy

ask-the-right-question

Categories: Blogs

Dyr lärdom från PUST: hur undvika nya IT-fiaskon?

Fri, 02/21/2014 - 12:12

2010-2011 gjorde RPS en bra grej. De byggde ett system (Pust Java) som gjorde polisen mer effektiv. Poliserna fick datorer i sina bilar och kunde direkt registrera brott. Därmed behövde de inte åka in till stationen för att avrapportera lika ofta som med gamla systemet. Systemet var skräddarsytt för att ge hög användarnytta, och projektet blev en framgång. Pust Java blev finalist i CIO awards “project of the year 2011″ och DN skrev en helsida “Polisen rapporterar betydligt snabbare med ny metod“. Systemet var inte perfekt, men en bra start. Poliserna sa att det var bättre än vad de hade innan, och folk var optimistiska inför systemets framtid.

Sedan hände något tragiskt. Istället för att vidareutveckla och kontinuerligt förbättra systemet, så valde ledningen att skapa ett nytt system från grunden (Pust Siebel) med undermålig teknik. Det blev ett fiasko. Ursinniga poliser klagade på att en avrapportering kunde ta flera timmar – “Pust Siebel gör en helt frustrerad och på gränsen till vansinnig!” – och saknade det gamla systemet. RPS hamnade i ett mediadrev. En poliskälla uppskattade samhällskostnaden till 10 miljarder kr!

Efter massiv kritik från både media, poliser, skyddsombudsmän och oberoende aktörer med insyn i projektet, beslutade RPS att lägga ner Pust Siebel.  Nu är det allt fler som förespråkar att Pust Java återinförs

Varför spenderar en myndighet hundratals miljoner på att bygga något bra, för att sedan spendera ytterligare hundratals miljoner på att byta ut det mot något dåligt? Ännu värre: varför gör man detta trots att hela IT-avdelningen visste, och högljutt påpekade från början, att det nya systemet skulle bli sämre?

Syftet med denna artikel är att belysa och sprida lärdomarna, så andra företag och myndigheter slipper göra om liknande dyra misstag.

Vi är insiders. Håkan Rydman var anställd som testledare på RPS i 7 år, deltog i Pust Java och hade direkt insyn i Pust Siebel. Henrik Kniberg är lean/agile konsult och deltog i Pust Java som coach. Arbetssättet (baserat på Lean + Agile) anses var en av framgångsfaktorerna för det projektet, och har beskrivits i en bok.

Utöver vår egen erfarenhet som deltagare så har vi läst interna rapporter från Pust Siebel (häpnadsväckande läsning!) och pratat med många andra projektdeltagare. Vi är arga och ledsna över att RPS bränner våra skattepengar och försämrar polisverksamheten, och med det riskerar ett otryggare samhälle.

Det har skrivits mycket om Pust, både i pressen och i påkostade analyser internt på RPS. Men de viktigaste lärdomarna går ofta förlorade i bruset.

Så vad hände egentligen?

Efter den lyckade lanseringen av Pust Java togs ett strategiskt beslut att övergå till s.k. standardsystem. Avsikterna var goda, att minska förvaltningskostnaderna.

Tyvärr gjordes ett dåligt teknikval – Siebel. CIO på RPS och konsulter från Oracle (leverantören av Siebel) övertygade RPS ledning om att det skulle vara billigt och enkelt att bygga om systemet i Siebel. Deras förstudierapport[1] var en orgie i önsketänkande. IT avdelningen protesterade högt, både muntligt och skriftligt[2][3]. De ansåg att Siebel var en mycket olämplig teknikplatform för Pust, och att användarnyttan offras till förmån för en hypotetisk kostnadsminskning. Till deras stora chock togs beslutet ändå.

Dessutom gjordes ett dåligt processval – att bygga och releasa hela systemet på en gång istället för börja med en mindre pilotrelease till en begränsad användgrupp. Tidiga pilotreleaser var en viktig framgångsfaktor för Pust Java. En pilot hade bevisat (tidigt och billigt) att Siebel var fel teknik, och man hade kunnat avbryta projektet eller utforska ett nytt spår. Men nu byggde man istället klart och släppte Pust Siebel till hela Sverige på en gång, och först då blev det bevisat att systemet var på gränsen till oanvändbart.

Vid det laget var det mycket svårt och dyrt att fixa felen, eftersom systemet var byggt på en olämplig teknikplattform i grunden. Målet var att minska förvaltningskostanden, men resultat blev värre än motsatsen – en sämre produkt, ursinniga poliser, försämrad rättssäkerhet, och ökade förvaltningskostnader![4][5]

Här finns en mer detaljerad redovisning av händelseförloppet från två av deltagarna.

Lärdomarna som behöver spridas är:

1) Ta aldrig viktiga tekniska beslut utan att blanda in de som ska bygga systemet. I RPS-fallet fick teamet ge input, men beslutet var redan taget innan så det gjorde ingen skillnad.

Risken för felaktiga och därmed kostsamma tekniska beslut minskar radikalt om man följer denna lärdom. Men risken finns alltid, därför måste man också:

2) Jobba iterativt i samråd med riktiga användare. Släpp tidiga och begränsade pilotversioner till riktiga användare. Förbättra produkten kontinuerligt utifrån deras feedback.

Punkt 1 minskar risken för dåliga beslut.
Punkt 2 minskar konskevensen av dåliga beslut, eftersom man upptäcker problemen tidigt.

I kort: IT projekt som inte gör detta bör aldrig finansieras!

Om alla IT beslutsfattare tillämpar denna beslutsregel, så minskar risken för nya stora haverier. Projekt kommer fortsätta att misslyckas ibland, men det blir små misslyckanden istället för stora katastrofer.

Pust Siebel är bara ett av många exempel på varför detta är så viktigt.

Iterativ systemutveckling är inget nytt. Det är grunden i både Lean och Agile och bygger på över 50 års branscherfarenhet. Men iterativ utveckling är varken enkelt eller smärtfritt – det krävs ett aktivt engagemang från verksamheten under hela projektet, och att man vågar släppa tidiga, ofärdiga versioner till pilotanvändare som vågar testa i fält. Man upptäcker sina felaktiga antaganden och tekniska problem tidigt, och förbättrar produkten kontinuerligt utifrån riktig användfeedback.

Detta var en av de största framgångsfaktorerna för Pust Java. Så varför fick inte teamet fortsätta jobba iterativt och kontinuerligt förbättra Pust Java?

Det är en komplex fråga som handlar om mjuka faktorer som politik, ego, organisationskultur och ledarkompetens. Inga enkla problem ett fixa, troligtvis behövs ett helt nytt ledarskap.

Men denna artikel handlar inte om vad RPS ska göra, utan om vad alla andra företag och myndigheter kan lära sig.

Systemutveckling är alltid riskabelt och komplext. Iterativ utveckling minskar projektrisken radikalt. Pust Siebel-fiaskot är ett dyrt exempel på hur man inte ska bedriva projekt, men om lärdomarna sprids så har de förlorade skattemiljarderna åtminstone kommit till någon nytta.

–Henrik Kniberg & Håkan Rydman
Feb 2014

Referenser

  • [1] Förstudierapport för implementation av Pust i Siebel.
    • Johan Söng (Oracle) m.fl. diarenr ITS-179-5044/11
  • [2] Kommentarer till förstudierapport
    • Tomas Alsterlund, Projektledare PUST Java. Diarnenr PVS-171-3001/09
  • [3] Granskning av förstudie – implementation av Pust i Siebel
    • Jan Sahlander (IT arkitekt, UFE, RPS). 2011-10-14
  • [4] Siebel Project Review – Slutrapport för Rikspolisstyrelsen
    • Simon Mills (IBM) m.fl. 2013-04-29
  • [5] Utvärdering av ärendehanteringssystemet SiebelPUST
    • Ernst & Young, 2013-10-01
Categories: Blogs