My Job went to India...

Språk är en cool grej, tycker jag. Just nu ägnar jag mycket tid och energi åt att bland annat försöka förstå det här:



Ja, det är jättesvårt! Men också inspirerande och en ordentlig utmaning. Mindre inspirerande är att det i mjukvarubranschen inte precis uppmuntras till språklig mångfald. Inte när det handlar om programmeringsspråk. Häromdagen kunde man läsa en artikel om IT-folk som tycker att det är tufft att begränsa sig (se länk längre ned). En utvecklare, ett programmeringsspråk, en plattform?

Varför? Konkurrensmässigt blir man ju väldigt sårbar, både som person och som konsultföretag. Varför välja svenskar som levererar IT-lösningar när man kan välja väldigt många lika duktiga (men billigare) proffs utomlands? Expert betyder väl inte att man bara kan en sak?

Svenska IT-företag behöver folk som är flerspråkiga, det är en bra grej!



(artikel)

Scrum på fem

- Scrum-metodiken skapades av Ken Schwa... Stopp!
- I det Agila Manifestet står det skriv... Stopp!
- I Scrum har man Sprintar, Backlogs och Burndown cha... Stopp!

Visst har man hört det där några gånger för mycket. Det är väl lagarbete och människor det handlar om? Scrum är ju inte särskilt mycket att hålla reda på, egentligen. Det är enkelt, konkret och borde gå att beskriva på fem.


Så:


1. Planeringsmöte med produktägaren.




2. Laget har ett eget planeringsmöte.




3. Perioden är igång (kallas för Sprint).
Laget arbetar med uppgifterna och har korta dagliga möten.




4. Perioden är slut och laget har en demo för alla som är intresserade.
En demo ger en ganska trevlig känsla av ett avslut och att det är dags att gå vidare till nästa del.




5. Till sist: laget har ett kort återkopplingsmöte.
Missa inte den här punkten! Det är här det händer grejer i laget.




Det var allt, det är det här som Scrum handlar om. Ganska enkelt, eller hur?

Människor är mjukvara, kontor är...

Jag läste nyligen ut Peopleware, som handlar om hur man kan lyckas och misslyckas med att skapa och driva framgångsrika företag. Författarna skriver om arbetsplatser och projekt som behöver anpassas till människor - inte tvärtom. Visst borde det vara självklart? Ett exempel: varför drar man fortfarande igång de där storskaliga IT-projekten som ingen människa kan överblicka?

I boken beskrivs också hur strikt kontorsdesign (kapitlet The Furniture Police) ofta sker på bekostnad av människors produktivitet. Väl dolda kostnader i företagsvärlden. På svenska tror jag vi kallar dem för HR! ;)

En del grejer har ju blivit bättre sedan bokens beskrivningar av det sena åttio- och nittiotalets COBOL-programmerande kunskapsföretag, men mycket känns igen från både större och mindre organisationer även idag. Kommer sådana företag att överleva krisen?

Med en team-förespråkande utvecklares ögon läser jag, i kapitel efter kapitel, förslag på hur man kan ta bort hinder för personalen för att bli ett framgångsrikare företag. Idéerna påminner mycket om det som finns i Scrum och jag tror att det var någonstans här som lättrörliga arbetssätt (agile) för mjukvaruindustrin började ta form.

Peopleware är nästan lika bra som Tom DeMarcos senare skrivna bok Spelrum på jobbet (Slack!). Läs båda!

Scrum - ett försvarstal

I metod-debatten hör vi ju ofta talas om det Komplicerade Projektet X: med jättemånga människor utspridda världen över, i flera tidzoner dessutom. Som inte kan samlas "för en massa Scrum-möten hela tiden". Det brukar också sägas att "agila" metoder inte skalar upp.

Vi behöver skala ner projekten istället för att skala upp metoderna.

För visst är det ganska enkelt att finna fem fel i den här typen av storskaliga projekt? Varför inte prova att anpassa projekten till människan istället! Jag tror att cirka sex-sju heltidsarbetande personer är betydligt hälsosammare för ett mjukvaruprojekt och ett bra recept för framgång.

Ett möte på femton minuter om dagen, där team-medlemmarna berättar om dagliga framsteg kan inte vara ett problem då. De flesta människor sitter väl en vanlig arbetsdag på toaletten längre än det?

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!"

Javisst, men...

Jaha, vad är det nu då? Visst är det en ganska negativt osande rubrik. Vad är det som gör den negativ?

Jag provar att stryka ordet men och byter ut det till ett och.

Javisst, men...det där är ju inget nytt blir till Javisst, och...tillsammans med Lean är paradigmskiften en möjlighet!

Ett enkelt grepp (som att byta ut ett litet ord) har ändrat min inställning helt och hållet. Hur är det möjligt?

Jag tror att sådana här enkla saker gör att man som ledare i ett företag eller team-medlem i ett projekt, på ett lättare sätt kan bryta tankemönster som stoppar kreativa idéer. Istället plockar man upp förslag och tar dem vidare.

Den här veckan ska jag försöka komma ihåg att byta ut mina ja, men till ja, och. Vem vet, kanske dyker det upp en innovation?

Ta med Människan i laget

Så där ja, där satt den! Alla uppgifter är avklarade, koden är städad och snygg, unit-testerna lyser grönt och sajten finns ute i molnet. Det känns fint, så när som på en sak. Det är en grej som inte fick plats i det här projektet. Eller jag menar, det var egentligen en människa som fattades i laget. Vi som systemutvecklare har sedan tidigt i projektet nämligen slutat att vara människor. Vi är robotar, som inte förstår mänskligt beteende. Vi tror att fraser som "felaktigt lösen" och "editera" är något som människan använder i sin vardagliga kommunikation.

Vårt mål i projektet har varit att bli klara med våra uppgifter och leverera något som fungerar. En människa vill ha något som är enkelt att använda. Vad kan vi göra? Vi behöver ett blandat lag, vi behöver testare och folk som skriver användarmanualer. Som ifrågasätter och påminner oss om att vi faktiskt bygger saker för människor, inte robotar.

Utan testare kommer vi att stå där och hoppa bakom personen, som stirrar på sin skärm och slumpmässigt tycks skicka muspekaren fram och tillbaka på helt fel ställen. Våra armar måste hållas tillbaka för att inte vifta och visa: "Där, där, där! MEN KLICKA DÅ. Snälla, klicka på länken 'verifiera dina användarinställningar'".

Åh nej, vi har misslyckats. Människan förstår inte vårt GUI (webbsida på människospråk). I ett svep blir den så tvärsäkre Terminatorn nu förbytt till den deppige roboten Marvin från böckerna om Liftarens guide till galaxen. Nu är det försent, produkten är i drift och kundservice tar emot samtal efter samtal från människor som behöver hjälp med produkten.

Jag tror att vi behöver team som består av olika typer (robotar och människor), som pratar med varandra varje dag och tillsammans kommer fram till bra lösningar. Tvärfunktionella team är en riktigt bra grej.

I'll be back!

Rör inte min design, kompis!

Om dagarna sysslar jag med att utveckla mjukvara och ofta är det ett kul jobb! Ibland känns det som att jag befinner mig i ett flow och tangentbordet smattrar av programmerarfingrar, hjärnan kokar av idéer och lösningar på, ja nästan alla, problem. Det är en skön känsla att vara kreativ och en problemlösare, delaktig i en uppgift som känns betydelsefull.

Det personliga engagemang som finns i arbetet har massvis med bra och en del mindre bra konsekvenser. Jag erkänner att det är en nästan daglig inre kamp jag för med mig själv att sluta tycka att det är min design, min idé, min kod, som finns där lagrad på en surrande server hos företaget. Det är inte alls konstruktivt utan bara egoistiskt.

Jag tycker mig se det här hos många och tror att en hel del känner igen sig i beskrivningen, kanske hos sig själva eller hos kompisar på jobbet. När man arbetar i team som inte jobbat tillsammans tidigare blir det speciellt tydligt. Alltför mycket tid av dagarna går åt att argumentera för sin sak och för sina idéer och man litar bara på sin egen kompetens. Man kanske kan säga att medlemmarna i teamet befinner sig i en fas som brukar kallas för "Storming"*. Visst låter det som att det riskerar att bli några övertidstimmar veckan innan leverans med ett sådant här gäng?

Hur gör man då för att komma vidare?

Jag tror att varje team behöver komma överens om vad som förväntas redan från början i ett projekt. Det behövs team-regler som man kommer överens om och kanske till och med skriver upp på en tavla. Ska man klara av att leverera något på några veckor, som i projekt drivna med Scrum, behövs ett team som klarar av att samarbeta varje dag. Varje person i laget utför dagligen arbete som tar hela laget små steg närmare en färdig produkt och det är ju faktiskt vi som levererar.


* Läs mer om: Forming Storming Norming Performing