Ja jag har inte ens sett den där "Commitments" rullen, men begreppet "Commitment" har jag funderat kring en del.
Att göra ett commitment är att förbinda sig, att förpliktiga sig att göra någonting. Att ställa upp helhjärtat för något och ingå en överenskommelse. Det här är ju en grundbult i all form av planering. Att kunna räkna med vad jag förväntas göra och att jag vet vad jag kan förvänta mig av andra.
Vissa personer är svårare än andra att få ett "commitment" från. Titta bara på hantverkare. Hur många av oss har inte fått "om en vecka" eller "i början av nästa månad" i ansiktet om vi frågat om den snälle rörmokaren/elektrikern/snickaren om han kanske eventuellt möjligen kommer snart?
Jag har mer än en gång raljerat över hur det skulle se ut om vi i IT branschen också gjorde så. För det gör vi väl inte? Vi säger väl alltid en fast tid och levererar väl alltid till den tiden? Vi kan väl enkelt räkna ut hur lång tid en funktion tar att införa? Tyvärr är det ju inte så. Jag tror att det till stor del på brister i våra commitments.
Dela upp saker i mindre uppgifter
Att få frågan "hinner du implementera denna funktionen på 3 veckor?" är oftast inte lätt att svara på. Tyvärr brukar jag lite väl snabbt göra ett överslag för att kunna svara "ja" direkt. Man vill ju inte sätta käppar i hjulen för en redan satt deadline och visst fixar man det där? Men en uppgift som tar 3 veckor att göra innehåller ju en hel del detaljer. Därför tycker jag att vi borde vara mer försiktiga med våra commitments och ta med oss en sådan fråga in på kammaren. Där delar man upp uppgiften i hanterbara delar som var för sig blir enklare att planera. Låt vara att det tar ett tag, men när man kommer tillbaka med sitt svar blir det mer säkert. Dessutom kan det självfallet också bli så att man svarar "ja, del 1,2 och 3 hinner jag. Men del 4 kommer inte finnas med". Då får beställaren bestämma sig för att tilldela mer resurser eller acceptera bortfallet.
Detta är en av delarna i Scrum som jag gillar skarpt. Att man avsätter tid i början av varje sprint för att planera, bryta ner och definiera vad man kommer hinna med. Att man faktiskt gräver ner sig lite i början för att kunna ge ett bättre commitment. Sen kan det ju finnas osäkra punkter man dyker på, men då är det ju ypperliga saker att börja med.
Daily scrum
Som jag skrev i ett tidigare inlägg är det här med "daily scrums" något jag tror starkt på. Vi har i teamet kommit överrens om vissa saker, vad som ska göras och när det kommer att vara klart. Att varje dag följa upp hur det går är att respektera våra gemensamma commitments. Då märker man tydligt om någon faller efter eller har svårt att klara sitt commitment. Eller förresten, det är ju hela teamet som gjort ett commitment och de har vi ju alla intresse av att klara av! Att inte följa upp varje dag blir att kasta en överrenskommelse i ett svart hål och sedan få reda på vad som kom ur det där hålet. Jaha, det blev en sån!
Tydlighet i uppdrag och commitments
Ska vi kunna ge bra besked till våra beställare måste vi vara tydliga mot varandra, både som uppdragsgivare och som den som utför uppdraget. Allt för ofta pratar vi i lösa termer som "när du har tid" eller "ja, när du känner dig klar med A, kanske du kan titta på B?" Vad är det egentligen man har förbundit sig till i ett sådant läge? Ingenting! Vad kan beställaren förutsätta att du gör? Dito! Lägg till detta att man inte kommunicerar läget på sina commitments dagligen och vilken planering har du?
Det skulle kännas så mycket bättre om jag själv var säker på vad olika kravställare förväntar sig av mig och att jag har varit tydlig med vad jag kommer leverera. Då behöver man inte lägga onödig energi på spekulation, besvikelse eller frustration. Iallafall inte beroende på sina och andras commitments.
Efter att ha skrivit detta inlägg började jag googla lite och hittade ett mycket intressant dokument som beskrev hur agila metoder motverkar teamets problematik. Ett av dessa problem var just "Lack of commitments". Läs gärna How agile practices adress the five dysfunctions of a team!
Over and out!
Dagens kodarmusik: Darude - In The Darkness
Visar inlägg med etikett daily scrum. Visa alla inlägg
Visar inlägg med etikett daily scrum. Visa alla inlägg
torsdag 26 november 2009
tisdag 17 november 2009
Utnyttja rädslan för att göra bort sig - på rätt sätt.
"Nothing motivates like the fear of appearing to be an idiot."
Tyler Jennings, Öredev 2009
Vid första anblick låter det kanske negativt, men om man funderar lite mer kan det ju användas på bra sätt.
Visst händer det att man gör saker som inte är prioriterade, kanske för att de är roligare eller för att man fått påtryckningar utifrån. Det händer ju också ibland att man allt för länge ältat ett problem men tjurskalligt gett sig fan på att lösa det på ett visst sätt. Eller varför inte när man underskattat uppgiften men inte vill erkänna att man tidsupskattat fel. Till slut blir det en dålig vana och sen sitter man där, sönderstressad för att klara de uppgifter som egentligen skulle göras på den tid man ursprungligen hade.
Allt det där kan ju fortgå om man får sitta helt ifred utan ifrågasättande. Dag efter dag, vecka efter vecka sitter vi där med en sporadisk fråga om hur det går. När det närmar sig release blir det extra kaotiskt och stressat, men så ska det väl vara? Visst blir det lite sisådär med kvaliteten, men mjukvara är ju komplext, eller hur? Nä. Så ska det inte vara. Det är bara destruktivt.
Men, tänk om man fick frågan varje dag, fast mera tillspetsad med
1. Vad gjorde du igår?
2. Vad ska du göra idag?
3. Finns det något som hindrar ditt arbete?
Detta är frågorna man får varje dag med "the daily scrum". Att träffas såhär varje dag tycker jag verkar extremt lovande. Det förhindrar ju att man
- Sitter med ett problem som någon annan har lösningen på, dvs inte frågar när man borde
- Sitter med uppgifter som inte ingår i det prioriterade arbetet, för att man blivit störd med ovidkommande eller för att man helt enkelt gjort något "roligare"
- Stångar sig blodig på sin lösning utan att någon ifrågasätter den
- Inser att man inte kommer hinna i tid men frågar ingen så...
Som utvecklare ska man inte se det som ett hot, utan som en möjlighet att bli av med de hinder man eventuellt har för att klara sina uppgiter. Eller som ett tillfälle att hjälpa andra att komma vidare. Allt för att bli bättre, och effektivare. Och om inte det funkar för dig, du vill väl undvika att verka vara en idiot, eller hur?
Prenumerera på:
Inlägg (Atom)