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

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