Veckans ord: Kontroll

6 06 2010

Har du läget under kontroll? Har du koll?
Koll på vadå? På ungdomarnas nya mönster, på historien? På marknaden eller människans potential?

Den bild som dyker upp i mitt huvud när jag tänker på ordet kontroll är en bild på en gymnast, på en bom, som gör en sådan där fantastisk långsam bakåtvolt, går ner i brygga bakåt och runt. Det tycker jag är att ha koll på läget.

Vad händer då om bommen börjar svänga från sida till sida samtidigt som du gör den där bakåtvolten?
Det lätta svaret är naturligtvis att gymnasten (du) får anpassa tekniken och färdigheten till den nya situationen, den svängande bommen (omvärlden).

Vissa skulle nog försöka stoppa bommen från att svänga och det går antagligen till en viss del. Agilister skulle säga att det är något dåligt. Bättre anpassa sig till den nya rörelsen än förhindra den.

I hur stora vinklar och hur fort ska bommen svänga för att det inte ska vara en fara för hela rummet (hela systemet) och vi helt enkelt MÅSTE försöka hindra den på något sätt för att den inte ska skada någon, i stället för att bara anpassa vår teknik (metoder) och  redskap till att själva kunna röra oss smidigt på bommen?

Erfarenhet av liknande svängningar, känsla och omtanke för omgivningen är det som också där ger det rätta svaret, skulle jag tro. Och då har vi den positiva innebörden av kontroll, för visst finns det en sådan.





Veckans ord: Mål

18 04 2010

Hur många av er därute har varit med om att det finns SMARTA mål i samma stund ni har blivit engagerade i ett projekt? Vore jätteintressant att få del av era erfarenheter och kommentarer.

Med SMART menas (en av flera översättningar):

S – Specifikt
M – Mätbart
A – Accepterat (Agreed)
R – Relevant
T – Tidsanpassat (Timely)

Varför frågar jag? Därför att insikten har slagit mig hur väldigt många utvecklingsprojekt som initieras och investeras i som inte alls har något som liknar SMARTA mål,  utan som enbart baseras på ett behov ”Vi behöver byta ut en gammal teknik..” ”Den här gruppen behöver ett systemverktyg..”, ”vi behöver en ny hemsida..”, ett behov som oftast är högst relevant men som – hur ofta – omvandlas till tydliga och relevanta mål för ett team att jobba mot?

Målet finns där  men gömt i annan information eller diffust uttryckt är min erfarenhet.

Om ett team av bergsklättrare gav sig ut på expedition med tanken att ”vi behöver ett berg att klättra upp på”  i stället för  ”vi ska bestiga Mount Everest den här månaden” – hur många flaggor skulle då sitta på en bergstopp däruppe? T.ex.

Hur viktigt är ett mål egentligen?





”och hur eliminerar man risken med integration?”

10 02 2010

forts på tidigare inlägg..

Om du vill eliminera risken för missförstånd mellan uzbeken och svensken helt vad gör du då? Eliminerar samarbetet helt, eller hur? De behöver inte prata med varandra alls eller ha något alls med varandra att göra.

Det enda sättet att eliminera risk med integration av olika system är alltså att eliminera integrationen.

Men om det inte går att eliminera, de måste kommunicera, hur minskar du risken för missförstånd mellan uzbeken och svensken?

1. En tolk är naturligtvis bra. Motsvarigheten i den tekniska världen är en medlare – en utvecklare som aktivt arbetar i båda systemen. Han kan båda språken, kulturen, designen och miljön.

2. Kvittenskommunikation. ”Sa du det här?” Bekräfta den kommunikation du har så tidigt som möjligt. Om uzbeken ritar upp en sol med händerna, rita ner det du uppfattar, dvs solen, på papper.  Uzbeken skakar på huvudet och visar med en spark att det är en boll han menar.

Detta händer dagligen i integration mellan system. Genom att snarast kvittera det meddelande det andra systemet skickar ökar förutsättningen för kommunikation.

I praktiken: Bygg integrationen först! Integrera först. vänta aldrig med att visa upp och bekräfta en fungerande kommunikation mellan systemen. Prioritera alltid uppvisning av integration.

Hur gör du själv för att eliminera eller minska risker du själv ser i ditt arbete? Vad brukar fungera?





Fördelen med att vara två om att lösa en uppgift

13 12 2009

Om jag nu skulle glömma eller behöva motivera

  • Innehållet blir bättre genom att lösa problem och bolla idéer tillsammans
  • Det finns alltid en som kan göra jobbet, om den andra plötsligt råkar vara borta
  • Det blir roligare för mottagaren och för oss. När något är roligt blir det också ett bra resultat.
  • Det går snabbare att göra samma uppgift
  • Båda två får nya kunskaper genom att få ta del av den andres perspektiv
  • Vi undviker en del onödiga (och kostsamma) misstag genom att få feedback direkt
  • Vi lär oss förstå andras perspektiv, genom att tvingas vara tydliga gentemot den vi löser uppgiften tillsammans med
  • Vi lär oss förstå våra egna perspektiv och åsikter, genom att förklara dem för någon annan (added by Rasmus)

Har jag glömt något?





Veckans ord: Acceptans

29 09 2009

Tänk vad svårt det kan vara att acceptera att en annan person beter sig på ett sätt som man själv absolut inte skulle göra, eller hur? Detta gäller naturligtvis både privat och på jobbet.

Exempel (fiktivt). En av dina team-medlemmar och utvecklare orerar vitt och brett om hur viktigt det är att hålla TDD-disciplinen, och att ett tecken på att en  utvecklare är kompetent är att denne kan erkänna när han/hon inte håller sig till disciplinen. ”Jag orkade inte”, ”jag slarvade”.. osv. ”Om man åtminstone kunde erkänna att man gått i backlash” säger han.

Veckan därpå sitter du och parprogrammerar kod med honom, som du VET att han jobbat med veckan innan, utan dig. Du ser att inte det minsta av koden är tdd:ad, inte ett endaste litet test kan du hitta, och frågar om det. ”Ja, visst är det slarvigt att inte kunna erkänna” säger han utan att nämna ett ord om att det faktiskt var han med sina medprogrammerare som rapporterat på Scrum-mötet att den funktionen var testad och klar.

Kan det bli mer kortslutning hos en själv i den situationen. vad säger man? ”Men vaddå, det är ju du som kodat den där biten!” Nej.. då är vi i sandlådan. Är det någon mening att argumentera?

Och detta gör han gång på gång.

Acceptanskriteria: Vilka kriterier ska vara uppfyllda för att jag ändå skall ta in den här personen i mitt team, och uppskatta honom och tycka det är värdefullt att arbeta med honom?

Att han förutom denna irriterande vana, att förespråka ärlighet och disciplin, för att själv göra precis tvärtom, är en fantastiskt rolig individ, som får hela teamet att må bra, som är en stark parprogrammeringsaktivist, som får demonstrationerna att lysa, som engagerar användare och alltid hittar innovativa vinklar och perspektiv på lösningar och frågeställningar.

Räcker det?

Exempel 2: Du jobbar med en lite besvärlig testledare, som inåt sett verkar gilla Scrum och dess testprinciper,  men utåt sprider sitt ogillande över en i hennes ögon anarkistisk modell, som klagar för chefer utanför dina öron, utan att vända sig till dig eller teamet. Som under retrospektiven nickar och håller med men därefter i princip spyr galla över hela projektet. En person som inte gör minsta anspråk på att själv försöka påverka den enligt henne pådyvlade Scrum-metoden.

Samma person har 20 års erfarenhet av domänen, kravarbete och testning. Fantastiskt disciplinerad och produktiv och kreativ testare när hon får göra på ”sitt” sätt. Oerhört nätverk i organisationen och en stor respekt från övriga medarbetare på driften och förvaltning. Är det tillräckliga acceptanskriteria?

Jag tror på mer acceptans från alla sidor. Det är alltid två i en konflikt. It takes two to tango.





Veckans ord: Mod

5 08 2009

Jag fick veta om en organisation som innan semestern bestämde sig efter ett antals år luddigt utvecklande/konverterande av ett gammalt gigantiskt IT-system att lägga ner projektet. Efter att ha spenderat ett par hundra miljoner sek i ett hål som inte levererat och inte kommer att leverera nytta då hela projektorganisationen och initieringen av projektet varit uppsatt av fel skäl och med en struktur som omöjliggort leverans av värde.

Det är det modigaste jag har hört på länge! Grattis! En tårta och champange tänker jag till den organisation som har dessa modiga ledare och beställare som vågade fatta detta fantastiskt svåra och jobbiga beslut. Äntligen händer det saker där ute i IT-världen. Våra beslutsfattare börjar bli modiga!

Mitt firande grumlades dock något när jag fick veta om deras utvärderingsmöte som de skulle ha efter det här erkännandet av att projektet gått fel, riktigt fel. Utvärderingsmötet fick jag veta, skulle absolut inte syfta till att hitta orsaker till varför projektet gått fel eller någon sorts påtagande av ansvar – vilket annars är en mycket motivationshöjande åtgärd. ”Ja, det var mitt fel som projektledare/beställare/styrgruppsmedlem/linjechef.. whatever” att det gick snett den här gången. ”Ja, vi har bränt pengar till ingen nytta. ” .. och.. ”ja, jag tror ändå att vi uppnått en annan sorts värde och nytta av dessa grundläggande problem genom det vi lärt oss, genom det våra leverantörer lärt sig och genom hur vi kommer att arbeta i fortsättningen, och bygga våra utvecklingsaktiviteter på framöver”.

Nej, utvärderingsmötet var till för att ”bocka av” att utvärdering gjorts, och resultatet av mötet får absolut inte visa några resultat eller orsaker som de ansvariga för mötet inte vill höra eller erkänna.

Ja, en bit på väg iaf. Och faktum är att utvärderingsmötet inte hållts än, så än finns det hopp om mera mod!





Veckans ord: behov

20 02 2009

Om vi redan under utbildningen, både privat och offentlig, ägnade mer tid åt att fundera på hur vi som tekniker, projektledare, beställare, verksamhetsanalytiker, användbarhetsexperter mfl kan lära oss att möta våra kunders behov i stället för att enbart fokusera på lösning av problem, skulle det bli lättare för oss att samarbeta på riktigt då?

Det tror jag.

(tack Agile Sweden för den frågeställningen som dök upp på listan)





Tips för att lyckas bättre med acceptanstestning

15 12 2008

Vanligt är att skriva acceptanstester efter utvecklingsaktiveteten. Men att identifera vad som skall testas, vilka acceptanskriteria som skall vara uppfyllda efter utvecklingen redan har utförts ter sig rätt märkligt vid närmare analys. Då är ju produkten redan skapad.

Att istället identifera acceptanskriteria – vilka kriterier som skall vara uppfyllda för att en del av en produkt skall anses fungerande, och accepteras, av kund före en viss del av en produkt (t.ex en viss funktion i ett informationssystem) byggs ter sig aningen mer effektivt. Det blir färre överraskningar på slutet.

Detta är inga nyheter. Detta arbetssätt har länge använts inom produktutveckling inom industrin, som att bygga flygplan exempelvis. Identifiera först vilka test som skall passera – bygg sedan ett inkrement som gör att testet passerar.

Genom att synkronisera identifieringen av acceptanstest med kravutredning effektiviseras arbetet och onödiga fel undviks som beror på fördröjning mellan kravanalys och analys av testkriteria. Dokumentation blir mer korrekt och lättare att underhålla och överblicka.

Genom att kombinera kompetens hos traditionella kravutredare med kompetens hos traditionella QA-avdelningar kan en organisation få ett kraftfullt verktyg att uttrycka krav. Detta är också till stor hjälp för utvecklarna som när de utvecklar en viss funktion redan vet vad som kommer testas och alltså vet vad som förväntas av en särskild funktion som skall byggas.

Att därtill lägga iterativ (kontinuerlig) uppdatering av krav/test-specifikationer med hjälp av tidig feedback från utvecklingsteamet (genom kontinuerliga leveranser), tidig feedback från kund (genom att denne tidigt ser vad som utvecklats) och i en ideal situation, tidig feedback från användare, tas acceptanstestningen och värdet av produktutvecklingen ytterligare ett steg framåt.








Följ

Få meddelanden om nya inlägg via e-post.