För ett år sedan gjorde Carl Hörberg och jag ett exjobb ihop. Titeln var ”Att göra en Lean Startup – utvärdering av lean startupmodellen vid start av nya mjukvaruföretag”. Som en del i det arbetet intervjuade vi ett gäng entreprenörer inom mjukvarubranschen. Två av de intervjuerna tänkte jag klistra in här på bloggen. Först ut är Martin Källström, vd för Twingly.

Att språket är lite stolpigt beror på att det är kopierat direkt ur en akademisk rapport (dvs vår examensrapport).

Intervjun, kopierad ur examensrapporten:

Vi träffade Martin Källström på Twinglys kontor i Linköping. Innan han och några andra startade Twingly hade han drivit egen firma och ett litet konsultbolag, polyester HB.

Twingly är ett företag som indexerar och gör sökbart olika aspekter av social media. Deras fokus är realtidswebben, dvs bloggar och twitter (mikrobloggar). Rent konkret tjänar de pengar på att filtrera ut olika dataflöden och göra dem tillgängliga för att inkluderas på olika företagshemsidor. Framförallt stora mediasajter. De säljer tjänsten i abonemangsform.

Vi ber Martin berätta om deras utvecklingsprocess. Vi frågar om den har några agila inslag.

Martin berättar att de har läst Michael Conns bok ”Agile estimating and planing” och plockat delar de tycker om. ”Inte någon specifik metodik utan Michaels best practices som vi använder oss av. Fungerar bra med våra grundläggande värderingar. Att man inte ska mäta prestation på indvidnivå utan på gruppnivå. Det är en grundläggande filosofi hos oss. Även med bonus och optioner. Alla har fast lön, säljarna har inte provision. En affär är inte bara hans förtjänst utan även teknikernas. Vi är ett litet företag så allt är allas förtjänst.

Vi jobbar i treveckorsiterationer. Efter varje iteration följer en veckas  ”lagg” då vi gör en omgruppering. Vi hinner med kundsupport och planerar nästa iteration. Planeringen sker med hjälp av user stories skrivna på A4-papper. T.ex: ”Som användare av channels vill jag kunna xxx” varje planering består av ca 20-30 st sådana stories. Sen har vi ett planeringsmöten där utvecklarna poängsätter varje story. Varje story kan få 1-2-3-5-8-13 eller 21 poäng (fibonacci-skalan). Det är bra med den skalan för då undviker man att det blir en diskussion mellan ”13 och 14”. Skapar inte en illusion av att man i detalj kan avgöra hur svårt det är för stora grejer.

I början var det svårt att uppskatta poäng men efter ett tag blev det lättare. Sen när man sett hur många poäng teamet klarat av under en period får man lite koll på hur bra teamet jobbar. Vi klarar av ungefär 67 poäng per iteration. Om man vet att någon är ledig en vecka tar man bort några poäng den veckan. Vi har på så sett ett verktyg att planera utan att utvecklarna känner att ”om jag säger att det tar 28 timmar måste jag klara av det på 28 timmar”. Ingen kan säga ”men varför har du ägnat 8 timmar på uppgiften som bara var planerad till 4.” efterhand kollar man bara ”har teamet klarat av 67 eller inte”. 67 är vad vi klarar ungeär vid full bemanning.

Martin berättar att de inte har någon fast roll vem som skriver user stories, alla kan göra det. Det är dock utvecklarnas roll att poängsätta dem. Efter att de har poängsatts prioriteras de utifrån en femgradig skala. Back-end-jobben prioriteras för sig och front-end-jobben (det kunden ser) för sig. Sedan buntas de ihop i en och samma hög. Man börjar alltid med att göra de högst prioriterade jobben. En iteration är aldrig längre än 3 veckor, om man inte hinner allt struntar man i att göra de lägst prioriterade jobben. Efterprioriteringen är gjord godlänner Martin prioriteringen. Planering och prioritering sker med hjälp av A4-lapparna som deras user stories är skrivna på. Martin säger att det är en visualiseringsform som fungerat väldigt bra.

Martin visar oss utvecklarnas utvecklingstavla där arbetet går att följa. Längst till höger är en s.k. Burn-down-chart som visar hur mycket jobb som är kvar på denna iteration.

Vi frågar Martin hur de jobbar med kundutveckling och han berättar att dom försöker att jobba långsiktigt. De säljer abonemanger och att det därför är viktigt att skapa en relation till kunden. De försöker sälja sina standardprodukter till kunden men ibland måste specialvarianter skapas. Han berättar att de aldrig producerar något innan de vet att de har en kund till det. Om de har en idé prövar de den på en kund. Om kunden tycker att det är bra och är villig att betala för den går de vidare med idén. Martin säger att ” Vi vill slösa så lite tid som möjligt på utveckling som inte har ett behov.” En kunds betalningsvilja anser Martin vara den bästa indikationen på behov. Det räcker inte med att en kund säger att något är bra, han måste vilja betala för det också.

Vi frågar om de använder sig av färdig teknologi och han svarar att de gör dom så mycket det går. De försöker bygga så lite som möjligt själva. Det de gör själva gör de i .NET-miljö men de 2/3 av servrarna är ubuntu, mysql och open source. Ibland köper de komponenter, t.ex. en bilduppladdningskomponent för 2500 kronor. Martin berättar att det fina med open source är att om de färdiga proprietära lösningarna har för hög prislapp så finns det alltid en gratisvariant gjord i open source.

Vi frågar om de tittat något på Lean utveckling och Martin berättade att de läst Poppendiecks bok. De hade också varit på något av deras seminarier. De tyckte att det verkade bra men hade inte medvetet implementerat det. Twinglys processutveckling sker lite efter behov. När de märker att något inte fungerar förbättrar de processen så att det ska fungera.

Nästa punkt i samtalet var att Martin skulle ta ställning till några motsatser.

Kunskap om trender eller kunskap om kunden?
Martins svar: ”Kunden, men kunskap om trender är mycket mer tillgängligt, lättare att hålla koll på det. Att jag svarar ’kunden’ kan också ha att göra med att jag redan har koll på trenderna”

Beslut baserat på erfarenhet eller beslut baserat på data?
Martins svar: ”Data, men det är svårare att uppnå. Viktigaste datan är kundens betalningsvilja.”

Många iterationer eller vältestade releaser?
Martins svar: ”Många iterationer, enkelt svar”

Få funktioner eller komplett tjänst?
Martins svar: ”Få funktioner”

Rätt från början eller Vi kan fixa det sen?
Martins svar:  ”Vi kan fixa det sen”

Tydlig kravspecifikation eller täta kontakter med kund?
Martins svar: ”Täta kontakter med kund. När vi drev Polyester gjorde vi misstaget att skriva långa kravspecifikationer med kund. Det blev bara en börda för oss och för kunden.”

Många bollar i luften eller en sak i taget?
Martins svar: ”Både och, balans är viktigast. Man måste pulsera mellan att ha hårt fokus på en grej och att vara helt öppen för många olika saker. Svaret är olika vid olika tillfällen”.

Senaste tekniken eller beprövad teknik?
Martins svar: ”För oss är det helt klart senaste tekniken. Vi ser företaget som ett formula 1-team. Vi ska ligga på edgen med vårt varumärke. Finns risker med det det. Vi tar stora tekniska risker men tar det säkra när det gäller det affärsmässiga istället.”

Identifiera kund tidigt eller bygga och pröva?
Martins svar: ”Vi försöker få in kunden så tidigt som möjligt”

Brainstorma affärsidéer eller genomföra marknadsundersökning?
Martins svar: ”Marknadsundersökning låter så strukturerat, det gör vi inte. Man kan säga att vi involverar kunden i vår brainstormningsprocess”

Fortsätt mot uppsatt mål eller anpassa målet?
Martins svar: ”Svår fråga, i det lilla perspektivet tror jag mycket på att anpassa målet men i det stora hela måste det ligga fast. Visionen ska vara fast men vägen dit går att justera. ”

Skapa produkt eller ta reda på kundens problem?
Martins svar: ”Ta reda på problemen”

Slutord

Martin har godkänt publicering av intervjun men bad oss att inte ta med bilderna vi tog på deras planeringsvägg över hemliga projekt. Den bilden var väldigt intressant och kommer inte hamna på internet.

Nästa intervju är med Ted Valentin. Stay tuned.