Nokia lär oss hur vi INTE ska göra – organisation och teknik
Det här är ett referat av Nokia-caset från Mik Kerstens bok ”From project to product (2020)”.
Inledning
Ett företags överlevnad handlar till stor del om hur de klarade av det senaste paradigmskiftet. Nokia hade framgångsrikt förflyttat sig med tiden och var störst på mobiltelefonmarknaden på 90- och 00-talet. De hade både paradigmförfinat och paradigmförflyttat sig. Men de klarade inte av den sista paradigmförflyttningen – den från hårdvara till mjukvara.
Bakgrund
Nokia var tidiga med att använda agila metoder (Scrum) för utveckling och de var tidiga att göra det i större skala. År 2005 definierad de ett test, ”the Nokia test”[1], med ett antal frågor för att stämma av den agila mognaden tex om utvecklingen skedde iterativ och om teamen använde principerna i Scrum. År 2008 köpte Nokia det mobila operativsystemet Symbian som skulle ta dem in i nästa paradigm. Satsningen var mycket ambitiös. Det fanns en tydlig vilja och ambition från ledningen att använda agila metoder.
Både affären och marknadsavdelningen var väl medvetna om att de var tvungna att förflytta och anpassa sig i det allt snabbare förändrade mobila landskapet. Det var anledningen till att de rullade ut det agila från början. Man ville kunna anpassa sig snabbare och man såg också den allt viktigare rollen som mjukvara fick.
Nokia hade på plats en effektiv förmåga och infrastruktur för att utveckla hårdvara men det nya paradigmet krävde att du var lika duktig på att få ut mjukvara. Nokia hade dock inte drivkraften i affären för att inse och prioritera det förens det var försent. Med Stephen Elop, som klev på som VD 2010, kommunicerades ett krisbudskap ”burning platform memo”[2] där Elop målade upp en bild av kris. Men det var för sent. Nokia gick för bra för att ändra sig i det gamla paradigmet (hårdvara) och missade därmed det nya paradigmet (mjukvara). Det hans föregångare hade behövt göra var att kommunicera Elops ”burning platform’ memo” när det gick som bäst.
Ser vi Nokias digitala transformation som en värdeström var den agila transformationen en lokal optimering i en del av värdeströmmen frikopplad från affären och affärsmätetal.
Flaskhalsen att leverera ett operativsystem kapabelt att stödja ett mobilt ekosystem var inte hos de agila utvecklingsteamen.
Utmaningarna hos Nokia
Med tiden blev det tydligt att förhållningssättet till scrum och de agila aktiviteterna blev det primära att mäta på Nokia, fokus på värdet som passerade genom teamen blev sekundärt. Utvecklarna upplevde stora problem med flödet nedströms på grund av de långa ledtiderna kopplat till bygg, test och deploy som bland annat var ett resultat av Nokias rigida säkerhetsprocess. Än mer utmaningar hade utvecklarna med Symbians arkitektur vilket var ett hinder för att få till de snabba förändringar som affären ville få igenom. Symbian var till exempel inte riggat för att supportera applikationer från tredje part, vilket omöjliggjorde en egen ”app store”.
Utvecklarna var positiva till Scrum men de kände sig bortkopplade från den stora bilden och de såg inte helheten. De verktygen som användes på enterprise-nivå skilde sig från de som användes av utvecklarna i teamen. Hela flödet kunde alltså inte visualiseras i sin helhet. Istället för att använda processen och ett verktygsstöd som hjälp i att visualisera flödet och förbättra det blev istället verktygen ett sätt att dokumentera saker när de väl hade utvecklats.
På ytan var transformationen på rätt spår. Många av de önskade agila aktiviteterna skedde och de utvalda agila verktygen var anammade. Men utvecklarna kämpade i vardagen med långsamma processer kring att bygga och deploya kod. Att addera nya features till Symbian blev svårare och svårare på grund av arkitekturen och storleken på operativsystemet.
Om transformationen hade mätts baserat på outcome (effekthemtagning) och resultat snarare än på aktiviteter hade bilden sett helt annorlunda ut. Den fundamentala flaskhalsen i mjukvaran hade då blivit än tydligare för fler. Kanske hade investeringarna som behövdes i Nokias core IT, Symbian OS, blivit uppenbara och genomförda och Nokia hade kunnat bli en relevant konkurrent till den mjukvarubaserade aktören Apple.
Men den nödvändiga feedback-loppen tillbaka till affären fungerade inte på grund av att utvecklarna var frikopplade från affären. Och samma destruktiva frikoppling fanns mellan uppströms och nedströms i utvecklingsprocessen där förbättringarna i bygg- och deployprocessen gick alldeles för långsamt.
Sammanfattning
- Var det nedströms de agila teamen problemen uppstod med avsaknaden av CI/CD och möjlighet att leverera ”on demand”?
- Var det arkitekturen i sig själv som inte kunde stödja de funktioner som var nödvändiga?
- Eller var det uppströms närmare affären där man var frikopplad från att se de faktiska behoven i att investera i förmågan (arkitektur och infrastruktur) och att reducera teknisk skuld?
Mik Kersten From project to product (2020) kommer fram till att det var en kombinationen av ovan. Affären hade ingen förståelse var de riktiga flaskhalsarna var i flödet och avståndet mellan IT och affär var alldeles för stort.
Kersten kommer fram till att en begränsad och aktivitetsbaserad inställning kring agilt var rotorsaker till Nokias misslyckande i sin digitala transformation.
Den misslyckade transformationen omöjliggjorde snabba iterationer och snabb feedback från marknaden genom att ledtiden att leverera nya funktioner var alldeles för långsam. Detta hindrade affärens förmåga att lära och anpassa sig och den oförmågan att lära var en nyckelfaktor till Nokias fall.
Den tekniska- och arkitekturella skulden drev Nokia på fall. Uppkomsten till den går att spåra till den historiska projektorienterade utvecklingen där det inte fanns några incitament att reducera teknisk skuld och att optimera systemet som en helhet.
Mik Kersten (2020) sammanfattar i tre insikter och lärdomar:
- Lesson one: To avoid the pitfalls of local optimization, focus on the end-to-end value stream.
- Lessons two: If you manage a transformation according to cost alone, you will reduce productivity.
- Lessons Three: Engineering/IT and the business must be connected.
Referenser
[1] http://jeffsutherland.com/nokiatest.pdf
[2] https://www-engadget-com.cdn.ampproject.org/c/s/www.engadget.com/amp/2011-02-08-nokia-ceo-stephen-elop-rallies-troops-in-brutally-honest-burnin.html