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