Myten om moroten

Det har ju skrivits och debatterats en hel del på sistone om höga löner, bonusar och dyra konsulter. Hur mycket engagemang och ansvar får man för pengarna egentligen? Äh, jag ska inte krångla in mig i den deprimerande debatten. Det här är ju en blogg om agila grejer och ständiga förbättringar.

Men hur kommer det sig att personer som driver öppen källkod-projekt ofta har så stort engagemang? De levererar ny spännande funktionalitet, buggfixar och anpassningar varje månad (ibland oftare). Och arbetar gratis!

Är det andra drivkrafter än pengar som inspirerar till att hela tiden leverera bättre och bättre produkter och är kopplingen mellan höga löner och ansvar bara en myt?

Vi byter fokus en liten stund. Jag har en fråga:

Skulle du kunna tänka dig att jobba någon dag i veckan på ditt företags kundtjänst?

Typ svara i telefon och prata med användare, lyssna på kritik och hjälpa dem att förstå hur era produkter fungerar.

Hur påverkas man av att höra hur det som man varit med om att leverera fungerar i verkligheten? Jag skulle förmodligen bli helt knäckt de första gångerna. Jag tror också att jag skulle känna stort ansvar för att göra produkten bättre och vara drivande i att förnya vårat sätt att arbeta.

Jag tror att den där direktkontakten mellan utvecklarna och användarna är den stora grejen i Open Source-världen. Man lyssnar på människor och använder själv sina produkter. Det är därifrån viljan och kreativiteten kommer. Vi andra kan lära oss mycket av det.

Chefen, finns det en ledig plats hos kundtjänst på fredag?

...innan det är försent

”Hur gick det? Vad gjorde vi fel? Så här borde vi kanske ha gjort.”

Mötesprotokollet sparas och sorteras in i en pärm, projektet är (äntligen) avslutat. Fyrtioåtta timmar senare har nästan allt glömts bort och vi går vidare till andra uppdrag.

Är det inte bättre att försöka förbättra oss nu (innan det är försent) och ha roligare på jobbet redan idag?

Hur?

Det finns bra idéer från Lean-världen (ständiga förbättringar) och konkreta förslag från Scrum-världen (återkopplings-möten) som man kan ta hjälp av.

Jag vill gärna berätta om hur vi gör idag:
vi planerar in korta team-möten (en timme) varannan vecka. Varje person skriver ner sina idéer och förslag på gula lappar, som sätts upp på en whiteboard-tavla. Vi pratar om idéerna, prioriterar och diskuterar lösningsförslag. Dagen efter - när vi drar igång nästa period (kalla det sprint om du vill) - har vi uppmärksammat saker som varit hinder i vår produktivitet. Vi har troligtvis redan löst en del av dem!

Två veckor senare gör vi samma sak igen och för varje gång blir vi ett bättre och gladare team. Det syns också tydligt i våra leveranser. Det här är en bra grej som jag tror att många ”Scrum-team” hoppar över och kanske en orsak till att så många IT-projekt fortfarande misslyckas.

Boka ett återkopplingsmöte med dina arbetskompisar i laget redan nu, ta med pennor och ”post-it”-block. Det kan bli en väl investerad timme.

Boktips: Agile Retrospectives

Bra idéer är gratis

Häromkvällen satt jag på bussen och läste en bok, som handlar om ett litet företag och deras arbetssätt. Jag ville inte sluta läsa, trots att jag strax skulle gå av och börja kvällens lektion i kinesiska. Nästan varje sida hade ju något spännande att säga och det var bara tur att jag lyckades gå av på rätt hållplats.

Några rader från boken, fritt översatt:

Om du egentligen inte är intresserad av det du jobbar med är det något som är fel. Arbetar du för att få ut din månadslön kommer det att synas i det du levererar.

På samma sätt kommer det att lysa igenom produkten om du verkligen brinner för det du gör. Folk kan läsa mellan raderna.

Boken heter Getting Real och finns att läsa gratis på nätet.

Och hur gick det på kvällens lektion?



(mycket bra!)

Måste man veta allt innan?

Det finns ett uttryck i stil med "tänk först, gör sedan", som jag funderar lite på. Betyder det att man slutat tänka då man gör?

Det är fortfarande vanligt att man i IT-världen ägnar mycket tid åt att skapa komplexa modeller och instruktioner för hur en produkt ska utvecklas, långt före själva arbetet börjar. Jag tror att man vill få bort risk och osäkerhet innan produktutvecklingen drar igång. Kan man i förväg veta vad som är rätt väg eller är det egentligen bara (en människas) gissningar?

Jag tror att det kan vara den där husbyggar-metaforen som ligger bakom: "...utveckling av mjukvara är som att bygga ett hus, först lägger man grunden och man måste ha en plan och ritning...".

Det är något som inte riktigt stämmer med det där, mjukvara är ju inte betong eller cement som stelnar efter ett tag. Mjukvara är bara enkla textfiler, som snabbt går att förändra och förbättra. Till och med när huset...förlåt, webbplatsen är färdig, kan man uppdatera hur många gånger som helst. Koda, testa, publicera, klart!

Jag tror inte att en produkt någonsin blir bra, om de som utvecklar den inte får utrymme att tänka och hitta bra lösningar under projektets gång. Våga lita på ditt utvecklarteam och hjälp till att göra det enkelt att samarbeta: möblera om kontoret, sätt upp whiteboard-tavlor på alla de tomma väggarna, flytta om borden så att det blir lättare att parprogrammera, leverera produkten ofta och lyssna på användarna.

"Gör nu, tänk tillsammans!"