Kanban bubbles

Recently, a sunny day when my son and I went to the playground, there was a child blowing bubbles. The soap bubbles were flying higher and higher, sometimes they seemed to just hoover high up over the ground, suddenly take a dive and then back up in the air again. Both of us were fascinated.

"-Kanban bubbles."

I liked the sound of it. I guess there was some work issues processing in my head and the brain felt like combining work and play: Kanban bubbles.

At work, I am a part of a small team. We are about four team members working with software development, Kanban style. During the year we have changed stuff, improved things and experimented with tools like test driven development, pair and mob programming. We do, reflect and adjust.

We use a pretty standard way of visualizing our work, a Kanban board with swim lanes. In our agreed definition of done we have feedback (peer review) and exploratory testing as required activities after writing the code. One team member mostly gets to be the tester. The rest of us are mostly coders and peer reviewers. 

Our swim lane board doesn't really show that when all steps are passed, the release to production is done by the same team members that perform the first step. What goes around comes around. I tend to focus too much on the coding swim lane and too often miss what is happening at the right side of the board. Can our work be visualized in a different way?

Here is a suggestion, Kanban bubbles style.
The Whiteboard has two sections, the to-do area and the work in progress area. The to-do area is where we add stuff, prioritize and estimate. Important stuff at the top, not-so-important stuff at the bottom and we pick the most important stuff to work with.

Let's take a look at the work in progress area. In this drawing I have also added an imaginary circle.

Here I (sort of) have added our team definition of done steps and also tried to avoid those robotic terms that we usually see in Kanban and Scrum boards. After all, coders are humans, believe it or not.

In this picture one of the team members, let's call him Dave, has chosen something from the to-do area to work with. He moves the note to somewhere near Coding… word, draws a circle around it and a connector line to the word (make sure to only use those whiteboard pens, folks).

 

After some time the work in progress bubbles might look something like this.

What about limiting the work? By visualizing this way, there isn't very much space to add items, the actual (limited) space at the whiteboard is used for that. I think this way of visualizing probably is better suited for small teams.

The Kanban bubbles board is just an idea materialized from a moment of inspiration. Maybe our team will try this out in the real world, maybe not. The real world at the office is probably the only way to actually know if ideas are good or not. Or is it in the playground?

Gäst-bloggare på Swaine's World - Guest post at Swaine's World

(English version below)
Idag debuterar jag som gäst-bloggare på Swaine's World - en blogg av Michael Swaine, redaktör för PragPub och fd chefredaktör för Dr Dobb's, två populära IT-tidningar.


Här kan du läsa min artikel om The Agile Family | Swaine's World.


(English version)
Guest post at Swaine's World
Check out my guest post at Swaine's World by Michael Swaine, editor of PragPub Magazine and former EIC of Dr Dobb's.


Here's the article The Agile Family | Swaine's World.

Familjen Agile - The Agile Family

(please scroll down for the English version of this blog post)


Vem är egentligen den där “Agile” och hur ser familjesituationen ut? Och har Japan något med det här att göra? Jag har släktforskat och resultatet av mitt arbete kan du läsa om här.

Vi börjar med vår stora kändis i släkten. Idolvinnaren och den alla snackar om: Scrum. Efter framträdandet i Allsång på Skansen är han nu också riktigt folklig och dyker upp i alla möjliga sammanhang. Scrum har en lillasyster, som kanske inte är lika känd (ännu). Hon heter Kanban, är lite modernare än storebrorsan (som ärligt talat börjar komma upp i åren). Säg inte det till Scrum, han är lite känslig för sådant! Många uppskattar lillasyrrans Rock n’Roll-attityd, enkelhet och innovativa idéer.

Scrum och Kanban har faktiskt ett till syskon, som hamnat lite i skymundan. Han kallas för XP av sin familj och vänner. Egentligen heter han eXtreme Programming, men blev mobbad för det i plugget. Han fick skägg tidigt i puberteten också. Efter ett tag tuffade han till sig, bytte namn till XP och sågs gå omkring i t-tröjor med budskap som I Unit Test on the First Date. Han började umgås mer med brorsan Scrum och de har idag en mycket fin relation.

Scrum och Kanban är väldigt utåtriktade, XP är mer eftertänksam. Han är en riktig programmerarsjäl med stor passion för sitt yrke. Lär känna honom och ni blir vänner livet ut, sägs det. Han är mest lik sin pappa och är en förebild för sina syskon (utan att han egentligen vet om det).


Vem är pappa? Han heter Agile och är en sådan där far som vi alla önskar att vi hade. Lugn, klok och lyssnande. Han ger goda råd och arbetar ständigt för en bättre värld, präglad av öppenhet, förtroende och ansvar. Han är mycket stolt över sina barn och följer alltid med på turnéer och tv-framträdanden (håll utkik på första bänkraden efter en aningen gråhårig leende man i sina bästa år).

Men pappa Agile har också varit en liten pojke en gång i tiden. Han är en sk “sladdis” och har en några år äldre storasyster. Hon heter Lean och är respekterad och beundrad i hela världen för sin känsla för kvalitet, respekt för människor och långsiktigt tänkande. Agile fick ofta vara med när storasystern och hennes vänner spelade video-spel och sjöng till populärmusik på radio i det japanskt inredda hemmet. Han minns:
- Hennes tjejkompisar var så smarta och snygga! Jag var kär.


Storasyster Lean har lärt Agile allt han kan och är fortfarande en stor inspirationskälla för honom och speciellt yngsta dottern Kanban (som hälsar på och bor hos henne varje sommar).

Lean har också en dotter – kusinen till syskonen Scrum, XP och Kanban. Kusinen, som heter Lean Software Development, spås en lysande framtid och har inte fått strålkastarljuset riktat mot sig ännu. För den stora massan är hon okänd. Scrum berättar:
- När kusinen hälsade på var det alltid spännande. Vi skröt ofta om henne för våra vänner och hon hade alltid med sig de senaste grejerna från Japan. Våra Game&Watch-spel blev så omoderna och tråkiga när Lean Software Development visade sin spelkonsoll med både färgskärm och stereoljud. Det var fantastiskt, som att se in i framtiden!


Syskonen Agile och Lean Software Development har sedan länge daglig kontakt via Skype och planerar att samarbeta mycket mer i framtiden.

Vi har kommit till toppen av vårt släktträd. Här hittar vi: en japansk bil. Ja, det är sant. Syskonen Lean och Agile har sina rötter i ett nästan kliniskt rent verkstadsgolv i Japan. Historiens vingslag har tagit oss till landet med det vackra skriftspråket, de blomstrande körsbärsträden, sylvassa samurajsvärden och världens största bilmärke: Toyota.


Toyota Production System (TPS) är på god väg att forma en bättre värld med sina idéer om respekt för människor, lagarbete, kunskapsöverföring och ansvar. Ord som Kaizen (ständig förbättring) och Hansei (reflektion) är ett naturligt sätt att arbeta och leva enligt Toyota Production System. Enligt TPS räcker det inte med sk Quick Fixes då problem uppstår. Man går vidare och letar efter orsakerna till att de alls dykt upp, genom att ställa frågan varför? minst fem gånger. Toyotas filosofi är att: Basera besluten på ett långsiktigt tänkande, även om det sker på bekostnad av kortsiktiga ekonomiska mål.

TPS kan tyckas vara svaret på alla frågor, men glöm aldrig att det beror på (vilken fråga det är). Scrum, XP och Kanban är inte heller svaret på alla problem. Finns det ett svar då? Ja, det gör det faktiskt: 42. Vad frågan är får du lista ut själv.


Avslutning
Alldeles nyss fick jag ett meddelande, med avsändaren “TPS”:
- Du har mycket kvar att lära, David-san. Jag ser att du tagit hänsyn till A3-formatet. Men ditt släktträd skall vändas upp och ned.




(the English version)


The Agile Family

Who is that guy “Agile” anyway? Does he come from Japan? Where is his family? We have the right to know. I have done some research and here is the result of my work.


Let’s begin with the Star, winner of American Idol and the one everybody talks about: Scrum. Scrum has a kid sister, not yet as well known as her big brother. Her name is Kanban and is described by many as modern, attentive and a bit more up to date. Let’s be honest, all of us get old some day. So does Scrum. Please don’t tell him that, he is a bit sensitive about aging! The Rock n’ Roll attitude, simplicity and innovative ideas of lil’ sister Kanban are properties appreciated by the constantly increasing fan base.

Scrum and Kanban has another sibling. They call him XP and perhaps he is a bit overlooked. His real name is eXtreme Programming, but he was so bullied in school for it and really had to change his name. Sad, but that’s the real world. He also grew a beard very early in his teens, that didn’t help very much.

As a teenager, XP added some well needed attitude to his personality and he often wore T-shirts with statements like I Unit Test on the First Date. He started to hang out with his brother Scrum and they found out that they actually have a lot in common and complete each other well. Today they are the best of friends.


Scrum and Kanban are both extroverts. XP is very thoughtful and a passionate programmer. People say that when getting to know him, you will have a friend for life. He is the one that resembles his father most and without knowing about it, both his sister and brother see him as a role model.


What about dad? Well, his name is Agile. He is the kind of father all of us wish we had. A man of wisdom, laid back and always giving you attention. He is the one with good advices and has never stopped trying make the world a better place. He is very proud of his children and you will spot him on almost every of his kids TV and live performances. Do you see the bald guy at the front row smiling and cheering? That’s Poppa Agile.

Agile was a little kid once, like all of us. A boy that admired his older sister Lean. Her sense for quality, respect for people and long term thinking has made her well respected and admired all over the world. Agile did spend a lot of time hanging out with big sister and her friends. They played video games, laughed and listened to the radio playing the latest hits all day at home. He reminisces:
- Her girlfriends were so good looking and always knew what was cool and what was not. I was in love.


He continues: – All I know comes from Lean and she is still my biggest inspiration. My youngest daughter Kanban visits here every summer and admires her aunt a lot.

Aunt Lean also has a daughter, called Lean Software Development. She is the not so well known cousin of Scrum, XP and Kanban. I hear people say she is the next big thing.


Scrum says: - When our cousin was about to visit us, we all got so excited! We talked a lot about her, bragging about how cool she was. She always brought the latest stuff from Japan. Our Game&Watch toys was nothing compared to the gaming consoles she had, with the color screen and stereo sound. It was amazing. It felt like seeing into the future!


The Agile siblings and Lean Software Development both agree that they really should work together in the future. Let’s hope they do!

Yes, we have reached the top of the Family Tree. A car? Yep, that’s right. Both Lean and Agile comes from the garage. A very clean garage, I might add. The time travelling journey got us to the land of beautiful calligraphy, blooming cherry trees, razor sharp samurai swords and the best car brand in the world: Toyota.

Respecting people, team work, responsibility and sharing of knowledge is the soul of Toyota Production System (aka TPS). Will TPS make the world a better place? Kaizen (continuous improvement) and Hansei (reflection) must be a part of the daily work flow according to TPS. What about problem solving? Don’t settle with quick fixes. Try find the root cause by asking Why? at least five times. The philosophy of Toyota is: Base your decisions on long term thinking, even when they are in conflict with your short term financial goals.


Is TPS the answer to all your questions? Well, that depends. What about Scrum, XP or Kanban? Probably not. Is there an answer? Actually there is: 42. You go figure out the question yourself.


Final words
Recently I received a message from someone called “TPS”:
- You have still a lot to learn, David-san. I noticed that You have used the A3 format. Good. But your Family Tree should be turned upside down.

Visa vad du gör, eller "Dude, where's my Index Cards?"

(please scroll down for the English version of this post)

Idag finns det ett helt gäng olika agila metoder att välja till sin verktygslåda, många snickrar ihop en egen variant som passar bäst för den egna organisationen. Gemensamt brukar vara att information om projekten blir synlig för alla som är intresserade. Scrum-team har till exempel en demo av produkten de utvecklar med jämna mellanrum, en graf som visar på framsteg och så berättar man vad man gör just nu i dagliga stå-upp-möten. Kanban beskriver att man ska visualisera sitt arbetsflöde, i princip betyder det att använda någon slags vägg med arbetsuppgifter på. Det kan vara en riktig vägg på kontoret eller en digital variant i molnet. Många kallar det för Scrum- eller Kanbantavlan.

Personligen gillar jag en riktig vägg i gips, trä eller betong. Varför? Allt blir så mycket enklare: inga behörighets-trassel, dålig dra-och-släpp-funktionalitet eller obegriplig länk till en server någonstans i byggnaden. Med en riktig vägg tar man helt enkelt ett papper med arbetsuppgifter, flyttar, antecknar eller pekar och pratar med sina kollegor kring det som ska göras. Enkelt är bättre!

- Men ska man skriva allt för hand? Om man har en taskig handstil då?

Vi tar lite digital hjälp till det analoga teamet: Excel. Index Card Generator* är ett väl använt verktyg som fungerar som en enkel backlog för ett Scrum-team. Med ett knapptryck skapar man indexkort i A5-format, som man skriver ut och klistrar upp på väggen.

- Men om man inte vill använda Microsoft Office, finns det en Google Docs-version?

Japp, det finns. Det enda du behöver är ett Google-konto. Här är en video som visar hur verktyget fungerar.

Här hittar du Index Card Generator for Google Spreadsheet

Hör av dig med vad du tycker om verktyget, har förbättringsförslag eller hittar buggar!

(English version)

Dude, where’s my Index Cards?

There is a bunch of different agile methods to choose by for your toolbox these days and many teams create their own customized version for their organization. Agile methods usually makes information available to anyone that take interest in the current project.

Here are some examples: Scrum teams arrange product demos, use a daily progress graph and has the this-is-what-I’m-doing-today-meetings. Kanban describes that you should visualize your workflow, i.e. using a wall with swim lanes and index cards. Some teams use a real physical wall at the office and others use a digital wall somewhere in the Cloud.

I prefer the wall made of concrete. Why is that? Because everything becomes so much easier. You don’t need an Active Directory Folder Authorized User Group, there isn’t any drag-and-drop functionality that sucks and no weird links to a server somewhere in the building. At the concrete wall you simply take a piece of paper, move it and make notes without the need to press a Save button. Old School? Hey, I was born in the seventies!

- But what if no one can read my hand writing?

Let’s use some digital assistance: Excel. Index Card Generator* is a well known tool for managing a Scrum product backlog. Press a button (!) and you will get A5 formatted index cards to print out and paste at the concrete wall.

- But what if the organization doesn’t use the Microsoft Office Suite, is there a Google Docs version available?

Yes, and all you need is a Google account to get started. Check out the Youtube video that describes how to use the tool (the embedded movie above).

Please contact me if you make any improvements or find bugs!

Index Card Generator for Google Spreadsheet

* Index Card Generator for Excel

Feedback for dummies

Återkoppling – feedback – är centralt i agila metoder. Visst borde konstruktiv kritik, reflektion och återkoppling vara självklarheter?

Hur ser det ut där du jobbar?

Vi på Know IT i Stockholm träffades en kväll i våras och pratade om agila värderingar och verktygen som hjälper oss att arbeta mer smidigt i projekten. Här är en inspelning från kvällen, nedklippt till ett sk ”blixt-tal” (ca tio minuter).

Ge gärna din feedback!

I ett tidigare inlägg har jag skrivit om och översatt de agila principerna. Du hittar inlägget här: Agile remixed

Twitter Design Pattern

På Twitter har man 140 tecken på sig att säga något, sedan tar det stopp. Texten ska helst vara läsbar, så frktngr får man vara sparsam med.

[raderna ovan innehåller 140 tecken]

Det jag speciellt gillar är att man som twittrare måste ta bort all onödig information för att kunna leverera korta meddelanden utan brus. Finns det här designmönstret på flera ställen?

ONE: #business
Ibland pratar man om att berätta hissversionen av ett förslag eller en affärsidé:

Vi levererar det stora företagets IT-kompetens med det lilla företagets själ och den enskilde konsultens engagemang.
[116 tecken]

Här i Sverige pratar vi ju inte med varandra i hissen, men vad sägs om twitterversionen?

TWO: #requirements
I den agila världen används redan Twitter Design Pattern, där man gärna skriver krav i form av User Stories. Många Scrum-team och beställare gillar kortfattade och tydliga beskrivningar av det som ska göras:

Som en redaktör vill jag kunna lägga till och ta bort nyheter på internetbanken, så att bankens kunder kan ta del av aktuell information.
[137 tecken]

TWEET: #programming?
Jag har inte sett några tydliga tecken på Twitter Design Pattern i utveckling av mjukvara ännu. Men tänk om vi bara fick skriva 140 tecken när vi programmerar fram en metod? Enligt designmönstret behöver jag (trots begränsningarna) skriva koden både läsbar och meningsfull, helst utan krångliga frKrtNgr. Vilken utmaning!

Jag tror att resultatet skulle kunna bli lika enkelt och tydligt som på Twitter:
man behöver ju sällan läsa tidigare tweets för att hänga med. Meddelanden är isolerade och externa beroenden tar man med som länkar, taggar och re:tweets (Dependency Injection, Interface och arv?).

Vilka fler områden finns det som skulle kunna följa Twitter Design Pattern, har du några exempel?

http://twitter.com/davidvujic

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?

...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

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

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

Vi vill spela poker på jobbet!

Hur svårt kan det egentligen vara att gissa hur lång tid en arbetsuppgift tar att bli klar med? Vi som jobbar i IT-projekt brukar ju misslyckas med det här. Det har till och med gått så långt att våra misslyckanden av många betraktas som ett skämt!

Men det är ju en gissningslek och jag tror inte att det går att veta i förväg hur många timmar man behöver för en helt ny uppgift. Min erfarenhet är också att de som ska göra jobbet är bäst på att gissa och att fler personer gissar bättre än en person. Och det är här kortleken kommer in.

För att spela poker behövs en kortlek, som har en uppsättning av sifforna 1, 2, 3, 5, 8, 13 och 21 till varje person. Det går bra att riva papperslappar att skriva siffrorna på för att snabbt komma igång.

Innan man alls funderar på antalet timmar, pratar man lite om uppgifterna och försöker hitta den som verkar enklast. Den uppgiften får värdet en (1) poäng.

Nu är det dags att spela kort! Ta fram nästa uppgift och fundera en kort stund på hur mycket svårare den uppgiften är, i förhållande till den som var enklast. När alla med pokerfejs funderat klart: "Ett, två, tre!" och alla slänger samtidigt sina valda kort på bordet.

Man upptäcker snabbt att det ofta kastas kort med olika poäng och det är precis det som är poängen. Vi ser problem från olika håll och har kanske till och med tolkat arbetsuppgiften olika! Då korten skiljer sig, pratar man lite mer och berättar hur man tänkt. Sedan är det dags att spela igen - med samma uppgift. Så här håller man på till alla är överens.

När alla uppgifter är klara är det dags att prata om hur många timmar en poäng egentligen är. Är en poäng fyra timmar? Eller en dag? När korthajarna kommit överens har projektet nu en lista med uppgifter som tidsuppskattats. Troligtvis är den här typen av gissning bättre än då en ensam människa vid sitt skrivbord gör sina uppskattningar.

Den här metoden kallas planeringspoker och används ofta vid planeringsmöten i projekt som drivs med Scrum. Tro det eller ej, men det är också väldigt kul att tidsuppskatta med hjälp av poker.

Det ska vara kul att jobba!

Kan vi börja prata svenska, please?

Är svenska världens dåligaste språk, eller är kanske vi IT-folk dåliga på svenska? En presentation under en konferens om lättrörliga arbetssätt, fick mig att fundera på varför jag själv brukar ägna tid åt att förklara alla dessa uttryck som vi brukar slänga oss med om dagarna.

Jag gillar att prata om och arbeta enligt Scrum och vi som jobbar i projekt med hjälp av det här sättet, använder dagligen uttryck som Product Backlog, Sprint, Daily Scrum och Scrum Master.

Varför inte använda orden prioriteringslista, etapp, dagliga möten och lagkapten istället?

Jag tror inte att man behöver förklara vad ett dagligt möte är för något. De flesta av oss här i Sverige förstår nog också, på ett ungefär, vad som menas med en prioriteringslista. Hur många svenskar vet vad en Scrum Master är?

Jag brukar använda lättrörlig istället för det engelska ordet Agile, har du något annat förslag?

Börja dagen med att svara på tre frågor

Varför är det så komplicerat att jobba i team då man sysslar med IT? Är det våra verktyg som hindrar oss - skärm, tangentbord, skrivbord och mus - som inte direkt bjuder in till samarbete? Varför kan det inte vara som i datortillverkarnas annonser i tunnelbanan? Där några personer i fräsch kontorsmiljö ler stort och pekar på något spännande på datorskärmen.

De där annonserna är ju bluff, men jag har en idé: vi lämnar datorerna en stund och pratar med varandra istället!

Så här kan man göra
Alla som är med i projektet deltar i ett kort möte varje dag, som är max en kvart långt och förslagsvis klockan nio på morgonen. Under mötet svarar varje person på de här tre frågorna:

Vad har jag gjort sedan förra mötet?

Vad ska jag göra till nästa möte?

Har jag några problem som hindrar mig att lösa uppgiften?

Frågorna svarar jag på till hela laget och inte bara till chefen, projektledaren eller bästa jobbarkompisen. Eftersom mötet varar i en kvart, gäller det att vara kortfattad och hålla sig till ämnet. Eventuella problem löser man inte under denna kvart, men de personer i laget som kan hjälpa till träffas direkt efter mötet för att tillsammans komma fram till något bra.

Men blir det inte samma sak man står och pratar om varje morgon?

"Ja, jag sysslar fortfarande med dokumentationen..." eller "jag håller på med login-sidorna...".

Ja, det blir så om arbetsuppgiften är för omfattande.

Ett nytt problem har snabbt synliggjorts: vi behöver dela upp uppgifter till mindre delar. Allra helst deluppgifter som man kan göra klart på en arbetsdag. Dokumentationsuppgiften kan man ju dela upp till att skriva enskilda kapitel och systemutveckling är mycket enkelt att dela upp till mindre delar. Som login-exemplet ovan: ett formulär för att fylla i uppgifter, anrop till en användardatabas och så vidare.

Som projektmedlem känns det bra att berätta vad jag gjort klart under gårdagen och vad jag ska göra idag. Varje dag gör jag och laget små framsteg och kommer allt närmare ett avslut. På köpet får vi i laget dagligen en uppfattning om hur vi ligger till i projektet.

Det jag beskriver här är en av delarna i Scrum och kanske det enklaste att börja med i ett projekt. Vilka erfarenheter har du av att arbeta i team?

Några vanliga missförstånd om Scrum

Det verkar som att Scrum och andra lättrörliga (agile) arbetssätt provocerar många i vår IT-bransch. Vad beror det på? Kan det vara så att vi, som gillar att prata om sådant här, helt enkelt fokuserar på fel grejer? Jag tror att vi argumenterar för mycket och ofta ställer metod ett mot metod två: "så här dåligt fungerar det idag och så här fantastiskt blir det med Scrum!".

Jag tror att många slutar att lyssna när argumenten haglar och nyfikna frågor trycks ner av ännu mer agile-hagel. Det här bäddar för missuppfattningar.

Här är några vanliga missförstånd som jag ofta stöter på och förhoppningsvis lyckas jag med att reda ut dem.

I Scrum sysslar man inte med dokumentation
Den här nivån av detaljstyrning finns inte i processen. Dokumentation är ju uppgifter i att-göra-listan, oftast som en självklar del av en leverans och det är projektet som avgör vad som ska finnas dokumenterat.

Varifrån kommer den här uppfattningen? Jag tror att det kan vara just den där jämförelsen vi ofta gör mellan metod ett (till exempel RUP) och metod två, där man tar upp tung dokumentation som en dålig grej som inte behövs och är tråkig. Det kanske inte är så konstigt att tro att man inte jobbar med dokumentation i Scrum, när man lägger upp det så här.

Scrum är en hetsjakt mot projektledare
Varför kallas projektledaren för Scrum Master, var en av mina första frågor? När jag förstod att Scrummästaren inte är en projektledare, undrade jag då vem som styr och planerar projektet när man tagit bort rollen. Är projektledarens uppgifter onödiga?

Självklart inte! I Scrum har hela teamet leveransansvar. Laget planerar tillsammans, tidsuppskattar dagligen och varje individ tar själv uppgifter att göra: "jag tar den här pucken!". Scrummästaren är en del av laget och är i princip en person som ser till att alla arbetar enligt processen.

Man kanske kan säga att den traditionella projektledarrollens uppgifter finns både i ett team och hos beställaren (som brukar kallas produktägare i Scrum). Uppgifterna har alltså inte tagits bort, utan snarare fördelats om.

Scrum har hittats på av en dyr IT-konsult i kostym
Scrum är en variant av Lean, kan man kanske säga. Och Lean Production hittades på i Japan för mer än femtio år sedan! På Toyota har man sysslat med det här sättet att arbeta på i många år och vi som jobbar i IT-branschen ligger tyvärr hopplöst efter resten av världen. Här i Sverige: inom bank & finans, bilindustri och läkemedel är Lean ett välkänt begrepp. Men hur står det till bland dessa företags IT-avdelningar?

Vilka fler missförstånd tycker du finns?