Henrik Kniberg's Blog, page 6

Spotify Engineering Culture (part 2)

Here’s part 2 of the short animated video describing Spotify’s engineering culture (also posted on Spotify’s blog). Check out part 1 first if you haven’t already seen it!

This is a journey in progress, not a journey completed, so the video is somewhere between “How Things Are Today” and “How We Want Things To Be”.

Here’s the whole drawing:

(Tools used: Art Rage, Wacom Intuos 5 drawing tablet, and ScreenFlow)

Squad Health Check model – visualizing what to improve

Squad Health Check model

(Download the cards & instructions as PDF or PPTX)

At Spotify we’ve been experimenting a lot with various ways of visualizing the “health” of a squad, in order to help them improve and find systemic patterns across a tribe. Since a lot of people have been asking me about this, I wrote up an article about it together with coach-colleague Kristian Lindwall.

Read it on the Spotify labs blog: Squad Health Check model – visualizing what to improve.

Agile @ Scale (slides from Sony Mobile tech talk)

Here are the slides from my tech talk Agile @ Scale at Sony Mobile. Full house & very high level of engagement, I was impressed by this crowd! And thanks for the awesome recommendation on LinkedIn

 

Some sample pics below:

 

Hello managers, coaches, and other change agents

Here’s the thing. Suppose you introduce a change X to your workplace, and then business improves noticably. That doesn’t mean X caused the business to improve. Well, MAYBE it did. Or perhaps business improved for other reasons, and X was actually detrimental, and business would have improved even more without it. So did things work out well because of the great X, or despite the lousy X? You’ll never know, unless you could rewind the clock and play out the same scenario without X. Correlation doesn’t imply causation.

So people like me who work with organizational change, we are in the business of pseudo-science. We get customer feedback and anecdotal evidence, but we can’t actually prove that we are doing any good, it’s just opinions and observations and guesswork. I think that’s fine, but let’s be honest about it

What is an Agile Tester? Slides from my Sri Lanka talk.

Here are the slides for my talk What is an agile tester from the Colombo Agile Conference in Sri Lanka.

 

How do you know that your product works? Slides from my Sri Lanka keynote.

Here are the slides for my keynote How do you know that your product works, from the Colombo Agile Conference in Sri Lanka.

Focus – slides from my talk at Projektnäring

Here are the slides for my talk “Focus” at Projektnäring. Great group, lots of energy in the room. Had lots of great conversations with people. Thanks for attending!

Sample pics:

 

 

Spotify Engineering Culture (part 1)

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.

Keynote slides from my Passion for Projects keynote

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)

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

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”

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!”. 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 flera 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 enkla beslutsregel, så slipper vi  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 risken radikalt. Pust Siebel-fiaskot är ett dyrt exempel på hur man inte ska bedriva projekt, men om lärdomarna sprids så har det förlorade skattemiljarderna åtminstone kommit till någon nytta.

–Henrik Kniberg & Håkan Rydman

Feb 2013

Referenser

[1] Förstudierapport för implementation av Pust i Siebe.

Johan Söng (Oracle) m.fl. diarenr ITS-179-5044/11


[2] Kommentarer till förstudierapport

Tomas Alsterlund, Projektledera 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