Bortom Scrum - Utvecklaranarki på Telavox

Agile har i många företag kommit att förknippas med Scrum. Det finns de (ex. Dave Thomas) som menar att värderingarna i manifestet för agil mjukvaruutveckling är på väg att gå förlorade med de modeller som skall skala upp Scrum (som exempelvis LeSS och SAFE) .

Dessa agila metoder är säkerhetsbälten för att leva upp till värderingarna. Men många följer metoderna utan att fundera över värderingarnas innebörd. Detta leder till underliga arbetssätt och kommentarer som att ”agilt fungerar inte”.  Så hur kommer vi tillbaka till dessa värderingar?

Ett spännande och konceptuellt utmanande arbetssätt är att helt enkelt inte ha så mycket regler och styrning från ovan och att ta ett steg tillbaka och låta de som kan produkten mest fatta de viktiga besluten.

Upplägget går under namnet utvecklaranarki (eller ”självorganiserande utveckling”… men det låter inte lika fräckt)

Hur fungerar detta i praktiken?

Gasell / snabbväxande Telavox i Malmö – har en just tagit det agila bortom specifika metoder. Ledstjärnan är att skapa en kreativ miljö där alla är delaktiga med så få hinder och strukturer som möjligt.

För nya personer som kommer till Telavox kan det upplevas som kaos, då många av de strukturer man är van vid inte finns:

• Ingen uttalad process (Scrum/XP eller annan)
• Inga aktivitetstavlor, varken fysiska eller elektroniska
• Ingen budget, deadlines, estimat eller tidrapportering
• Inga krav, designdokument eller testspecifikationer
• Inga affärsutvecklare, projektledare, produktägare, testare eller uppföljande chefer

Så vad finns då på Telavox utvecklingsavdelning? 
Jo – just utvecklare. Utvecklaren är i centrum! Eftersom det inte finns andra roller så har varje utvecklare ett brett ansvar. På Telavox anser man att roller ofta reducerar ansvar – arkitekter, affärsanalytiker, utvecklare, testare som bara gör ”sitt” är något man inte vill ha.

Vilka mekanismer finns då?

• Vision – företaget jobbar med att diskutera de långsiktiga målen för att inspirera
• Egen drivkraft – vad vill du bidra med? Alla förväntas ha idéer för produktens utveckling. Ingen kommer att berätta vad du skall göra idag.
• Kontinuerlig leverans - vad har du levererat idag? Fokus på att jobba i små steg och kontinuerligt leverera. Man har ca 15 uppdateringar om dagen.
• Eget kvalitetsansvar – om du gör något dåligt, kommer det tillbaka till dig för rättning. Denna konsekvens gör att utvecklare kommer fram till bra avvägning kring kvalitetsnivå.
• Förtroende är väldigt viktigt – gäller att jobba med ifrågasättande, alla förväntas göra sitt bästa men det är okej om det går fel.
• Fokus är att identifiera hinder – och eliminera dessa direkt!

”Visst blir det ibland fel – men det fixar vi snabbt” säger Henrik Thorvinger, utvecklingschef, och en av dem som varit med sedan starten. ”Det gäller att utmana genom att ställa de rätta frågorna utan att ta deras beslut. Det bygger ansvar och drivkraft” fortsätter Henrik.

Att jobba med förtroende är något som Henrik brinner för – och det skapar man inte via strukturer och tunga processer, som bara ger falsk trygghet, menar Henrik. Det finns dock nackdelar. Precis som med alla arbetssätt kan man inte få allt. Men dessa negativa aspekter väger dock lätt mot fördelarna, tillägger Henrik innan han listar:

• Svårt att lova specifika krav, men man lovar kontinuerlig utveckling, visar på att produkten haft omfattande utveckling och de fortsatta investeringarna i att vidare förstärka utvecklingsavdelning.
• Är vi sena? Utan estimat och deadlines är det svårt att veta hur man ligger till. Korta loopar och kontinuerlig produktionssättning gör det lättare att ha kontroll.
• Passar inte de som vill ha vetskap om vad som kommer härnäst – långsiktig planering finns inte utan beslut kring vad som är viktigt sker på dagsbasis
• Tydliga ansvar finns inte. Man vill undvika fingerpekade och revirbyggande, men samtidigt innebär arbetssättet att det sällan sker större problem utan att de snabbt kan åtgärdas.

Fungerar detta för alla? För Telavox finns ett antal aspekter som underlättar:

• Affärsmodell, kunderna betalar månadsavgift, vilket gör att det är lägre risk för dem
• Många kunder, ingen som dominerar helt, vilket gör att man kan se till helheten
• Använder sin egen produkt. Telavox använder sig av sin egen produkt och förstår behoven
• Molntjänst – kan enkelt sätta system i produktion, dessutom i steg och ofta först prova själv
• Ägare med förståelse som vill att utvecklingen skall ta täten för produktens utveckling och inte bara sitta och vänta på kundkrav.

Fungerar då detta arbetssätt utan dessa förutsättningar? ”Det är förstås svårare, men helt klart möjligt”, menar Henrik som pekar på att man måste jobba med kundförtroende, affärsmodell och att skapa kunskap och idéer kring de produkter man jobbar med.

Undantaget som bekräftar regeln. Då utvecklare förväntas ta ett stort eget ansvar har ett team nyligen valt att prova SCRUM då de skulle jobba med ett lite större tydligare paket där kontinuerlig (daglig) leverans inte var tillämplig. ”Jag ser fram emot att höra teamets utvärdering av detta experiment” funderar Henrik.

Vad ser då Telavox för utmaningar framåt?

”Tillväxt är en utmaning, både att hitta och fasa in nya utvecklare. Hur länge klarar modellen att skalera? När vi var 4 trodde vi inte det skulle gå med 8, när vi var 10 trodde vi inte det skulle gå med 20. Men nu är vi nästan 50 med planer att växa mot 75” skrattar Henrik, som fortsätter mer allvarligt: ”Vi har flera gånger varit frestande att ta in samordnare/koordinatörer men när vi påminner varandra om vad vi tror på, så blir det fortsatt ett NEJ”  

Deadlines är ett annat förbättringsområde. Även om man inte har många så finns ändå en del deadlines att hantera. Internt vill exempelvis marknadsavdelningen kunna planera för kampanjer. Det fungerar hyfsat idag men är ett förbättringsområde.

När det finns få andra bolag som jobbar på samma sätt kommer förstås frågan ”är vi effektiva?” fortsätter Henrik vidare. ”Men här måste vi lita på oss själva precis som utvecklarna behöver tro på sig och sina lösningar”.

Utvecklaranarki används inte som koncept på Telavox – men mycket av Telavox vägledande principer stämmer överens med Fred George’s ”Programmer Anarchy” koncept som han lanserade för ca 5 år sedan. I korthet innebär ”programmer anarchy”:

• Det finns inga andra roller än utvecklare (dvs inga projektledare, produktägare, testare)
• Utvecklare jobbar direkt med kunder för att skapa förståelse och förtroende
• Alla ”normala” regler för att styra utvecklingen är borta då man anser att det begränsar kreativitet, ansvarstagande och produktivitet
• Tanken är att utan chefer som skall fördelar arbete tar utvecklare fullt ansvar för projektens framgång i en själv-organiserande ”anarki”.
• Förtroende är en annan nyckel – det gäller att skapa tankesättet att det inte är något problem att begå misstag utan att det snarare förväntas – och att man då skall lära av dessa!
• Utvecklaranarki är i linje med manifestet för Agil systemutveckling:
  • Individer och interaktioner framför processer och verktyg
  • Fungerande programvara framför omfattande dokumentation
  • Kundsamarbete framför kontraktsförhandling
  • Anpassning till förändring framför att följa en plan
• Och även XPs värderingar:
  • Kommunikation
  • Enkelhet
  • Återkoppling
  • Mod
  • Respekt        

Se gärna presentation med Fred George