”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
Saturday, March 14, 2009
Sunday, March 8, 2009
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!)
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!)
Saturday, March 7, 2009
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!"
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!"
Monday, February 2, 2009
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?
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?
Wednesday, January 14, 2009
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!
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!
Subscribe to:
Posts (Atom)