Veckans ord: Acceptans

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.

samlade reflektioner – Är det bra att en utvecklare får ScrumMaster-roll?

Under vår nätverksträff med 7 deltagare (användbarhetsexperter, projektledare, ”verksamhetsfolk” och utvecklare) filosoferade vi över denna fråga. Här är mina minnesanteckningar.

Är det närvaron i teamet som är huvudsaken? Ett exempel gavs från en utvecklare som kommit in som ScrumMaster och varit mycket uppskattad, teamet blev väldigt glada. Den tidigare ScrumMastern var både icke-programmerare och icke-närvarande och alltså ogillad. Var det närvaron eller den tekniska kunskapen som var det viktiga här, eller båda i kombination? Svaret lämnas öppet.

Personligheten spelar roll. Om du har intresse och fallenhet för ledarskap och team är av störst vikt. (?) Om du har rätt teknisk bakgrund men saknar rätt intresse och motivation är det ju naturligtvis bättre att ha en person med en annan bakgrund som ScM, men som engagerar sig i teamet och utvecklingen.. självklart.. Men vad är egentligen personlighet? och ”egenskaper”? Intressant diskussion utan anteckningar.

Blir kvinnor i större utsträckning ScrumMasters även när de har en tung teknisk bakgrund? Frågan parkeras.

Basen bör vara vana av system och IT-projekt. Du kan t.ex vara ”kravanalytiker” med stor domänkunskap, men med stor vana av system- och IT-projekt får du tillslut väldigt god förståelse för teknik och verktyg. Exempel från KTH, en person med sekreterarbakgrund som är landets mest eftertraktade proffs på en komplex nationell databas (gissa vilken och vem  – ni Kth:are som följer det här ”Jag är inte tekniker” är hennes standardfras. En lämplig både Produktägare och ScrumMaster i våra ögon.

Olika skeden i ett team, kan behöva olika typer av ScrumMasters. Olika team behöver olika typer av ScrumMasters. Har teamet stora tekniska utmaningar, eller har prioriterat dessa, behövs troligen en ScM med programmerarbakgrund. Om teamet framförallt prioriterar utmaningar gällande användbarhet och ux-design, är det lämpligt med ScM med användbarhets-bakgrund. Hur mycket stöd behöver Produktägare från ScM i ett aktuellt team, och vad för slags stöd – tekniskt, kravmässigt, ledarskapsmässigt t.ex?

Problemen i IT-projekt beror sällan på tekniken! De är nästan alltid användbarhets-problem!

En ScrumMaster som förstår den röda tråden  – som förstår helheten och effektkartor mm. önskade en användbarhetsexpert i rollen som produktägare.

(Parentes – User Story Mapping – för att förstå helheten. Boktips Jeff Patton. Koppla User stories till effekter och se helheten.)

ScrumMaster ansvarar för processen och att alla områden täcks in.

En icke-tekniker kanske är bättre på att förmedla saker till människor.. hrm.. måste ju säga att jag inte håller med där 
En ScM ska kunna se både helheten och delarna i helheten - och kunna förmedla det!

Produktägare och ScM behöver ha en mycket tight relation.

Teamet har ett gemensamt ansvar för helhetssynen!

Vem är egentligen icke-tekniker? Diskussion om olika bakgrunder. Måste man ha programmerarutbildning? Måste man ha programmerat? Är 20 års erfarenhet av testledning att vara tekniker?  De flesta utomstående skulle kalla alla oss i rummet för tekniker, även de två som absolut inte anser sig som IT-tekniker (dvs ”verksamhets”-personerna).

Både ScM och XP-coacher behövs i ett team! En utvecklare som är superteknisk och gillar att coacha och intresserar sig för teamfrågor, kanske passar som XP-coach? Att sitta som utvecklare och coacha på practices typ parprogrammering, refaktorisering, tdd mm. En ScM KAN knappast coacha sådant utan att programmera själv. Du kan som icke-kodande ScM inte på riktigt coacha ett teams XP-practices. Det har vi erfaranhet av. Som ScM behöver du  en XP-coach för att teamet ska lära sig arbetssätten i koden – även när du som ScM har programmerarbakgrund gör du ju inte själv. Därför jobbade jag som ScM STENHÅRT på att få med en XP-coach i mitt team. Hans huvudsakliga uppdrag var utvecklare – hade alltså inte gått att kombinera med ScM-roll.

En diskussion om effektkartor och ”vems” ansvar det är att rita upp dessa. Slutsats – hela teamet naturligtvis: Produktägare+ScM+utvecklare+ux:are

Att sitta i samma rum med kravfolk får inte underskattas – igen. Bjud in ”den andre” i din värld.

ScrumMaster har ansvar för att teamet skall förstå processen. Men egentligen inte ansvar för själva processen – för det har ju teamet  själv, även om de ofta behöver mycket vägledning i början. ScM skall bygga team där alla tar ansvar.

Egenskaper är de glasögon vi ser världen genom. Om man skolat sig i den tekniska världen har man tekniska glasögon – alltid (?)’

Det är ScrumMasters uppgift att sätta ner foten och se till att man får den kompetens som saknas i teamet - må det vara XP-coach, UX:are.. frågan parkeras.

Mina anteckningar avslutas med det kryptiska ”Verksamhetsprojekt ej IT-drivet, verksamhetsprojektledare och IT-projektledare” och efter Nettans roliga film på deras projekt på Microsoft Surface, min fråga ”Varför prioriteras inte moderna designprojekt i utvecklingssammanhang?”

Är det bra att en utvecklare får en scrum master roll (vice versa)?

Den här frågan ställdes inför vår nätverksträff (SjuttonFemton) att reflektera över:

”Är det bra att en utvecklare får en scrum master roll (vise versa)? Min tanke är att en utvecklare generellt kanske inte har den typen av bakgrund för att coacha ett team, eller är det så att det är bra eller ett måste att ha en teknisk bakgrund för att bli en bra scrum master?”

Min reflektion:

”Äntligen en tekniker som projektledare!” har jag fått höra av många utvecklare när jag kommit in i ett team. ”Äntligen någon som förstår oss!!”

Många utvecklare verkar ha erfarenheten att en ren administratör kliver in, alternativ någon ekonom, någon som aldrig lärde sig programmera, någon som är chefens syskonbarn, någon som är chefens flickvän.. whatever kommer in som ett steg i någon slags befordran, och skall driva ett IT-projekt. Inte så bra erfarenheter av detta.

Så tidigare skulle jag ha svarat, ”ja, visst” självklart ska projektledaren vara teknisk. Men frågan är ju som alltid mer komplicerad än så. Det blir särskilt aktuellt nu när den traditionelle projektledarrollen i Scrum delas in i Produktägare och ScrumMaster. Är det något en produktägare skall vara så är det ju expert på domänen, då kanske man nödvändigtvis inte måste vara tekniker. Eller? På Toyota leds utvecklingen av product champions / chief engineers, dvs personer som är extremt kompetenta på både kunder och marknad OCH har bakgrunden som ingenjörer på Toyota. De är  på golvet själva och skruvar lite för att göra ett bra jobb.

Vad som tyvärr hänt i Scrum-världen verkar vara att minst 80% (helt egen erfaren siffra) av alla ScrumMasters är utvecklare som förväntas vara utvecklare i projektet + ha ScrumMaster-hatten på sig på 20% sin tid eller kanske mindre. Bara facilitera lite möten ungefär. Ajajaj det är där det gör ont. Hur ska den utvecklaren ha en chans att coacha något team?

I vissa projekt tilldelar man ScM till någon utvecklare och så har man ”vanliga” projektledare på sidan om. Utöver produkätgaren. Då börjar ledarskapet bli lite komplicerat och ScM-titeln är nästintill värdelös. Du blir en mötesadministratör och det var ju inte tanken med ScM-rollen. Och projektledaren, var är den?

Därför gillar inte jag ScM-titeln, den är för knuten till Scrum som metod och den är svårförklarad. Om jag kommer in som ScM hittar jag lätt min roll, men det beror troligen på att jag

1. inte utvecklar samtidigt även om jag intresserar mig för utvecklarnas jobb, val av verktyg, modellering mm

2. hade en fantastisk coach (guess who)  i mitt första Scrum-projekt som hjälpte mig förstå min roll

3. också har utbildning, erfarenhet och intresse av medial och marknadskommunikation och har jobbat mycket med kundrelationer

4. har utbildning i statsvetenskap och intresse för politik

Jag tror att en bra ScrumMaster har en bredd i sin bakgrund. Det är bra att ha teknisk kompetens särskilt i rollen som ScM, men jag tror att på samma sätt som produktägarrollen är det bättre att hitta en tillgänglig person, med brinnande intresse för system, personlig och teamutveckling än att hitta efter den mest ideala personen – chief engineern.

En utvecklare kan bli en utmärkt ScM BARA HAN FÅR TID och har intresset (vilket långt ifrån alla tilldelade ScM har!). En psykolog kan bli en utmärkt ScM bara hon intresserar sig för utvecklarnas vardag – jag vet flera t.ex marknads/bi-utvecklare som lärt sig testverktyg och installationsprocesser mm bara för att förstå. Det kan bli tuffare att kommunicera med tekniker utan den bakgrunden själv, å andra sidan bidrar en icke-tekniker med andra perspektiv, t.ex det ekonomiska vilket väldigt ofta saknas när utvecklare som jag blir ScM.

Vill du att din projektledare och chef skall ha liknande utbildning och kompetens som du själv, eller vill du ha någon från en annan domän?

Veckans ord: Sympatisk

Sympatisk. Är inte det den bästa beskrivningen man kan få eller ge om en annan person? ”Det är en mycket sympatisk person” brukar jag säga om vissa personer som helt enkelt är sympatiska. Jag gillar dem, de förtjänar att gillas och andra förtjänar att få upptäcka dem.

Som ledare, kan du vara sympatisk trots att du kan vara både stark, tuff och envis. Om du är sympatisk får du dina medarbetare med dig.

Sympatisk är nog inget man kan träna upp som andra egenskaper, t.ex empatisk. Sympatisk är man. Eller har jag fel?

Trevlig är något helt annat, det är de flesta som inte står under enormt tryck av något slag.

Sympatisk är ett passande ord den här veckan då jag senaste arbetsveckan, efter en lång ledighet, omgetts av sympatiska personer.

Do you use the spoilt brat pattern?

Underbart inlägg apropå användbarhet

http://annaforss.wordpress.com/2009/06/15/do-you-use-the-spoilt-brat-pattern/

Veckans ord: Mod

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!

ord: Förtröstan

Hav förtröstan. Förtröstan, för mig, är att veta att det kommer att gå. Det kanske inte kommer att gå som planerat, eller som tänkt, men det kommer att gå. Till skillnad från högmod, som är en övertro på sin egen förmåga, vilket föregår fallet enligt Bibeln åtminstone. Jag är inte så säker på att högmod, eller övermod alltid leder till fall. Det verkar som en hel del kommer väldigt långt på detta. men kanske kommer ändå fallet tillslut.

Förtröstan i projekt är enligt min erfarenhet att det går till slut, kanske inte så som det var tänkt från början, och framgången kanske  visar sig på ett annat sätt en den ursprungliga planen, men det blev framgångsrikt. Jobbigt på vägen, och många tunga beslut och hinder att klättra över, men det gick. Målet blev uppfyllt på ett eller annat sätt.

Förtröstan är tro på ens förmåga att inte bryta ihop när det är svårt, ibland extremt svårt, förmågan att alltid gå vidare och utveckla och utvecklas, och det är ett inte vikande hopp.

Agila Sverige 2009, 8-9 juni

Bra människor, intressanta ämnen och roliga tal, trevligt format, dessutom lågt pris.
Vad väntar du på? Det är bara att anmäla sitt blixttal eller deltagande.

http://agilasverige.se/

Veckans ord: Känsla

Känsla, när jag tänker på det engelska ”Emotion”, har en mycket större betydelse för vårt arbete än jag tidigare egentligen tänkt på. Ungefär som fokus på ”Förändring” som en naturlig del av utvecklingens art börjar accepteras särskilt i och med spridning av lättrörliga/agila tankesätt. Förr tyckte många utvecklare och projektledare, och än idag, att förändring är något som skall bekämpas och hanteras i särskilda projekt.

Känsla eller rättare sagt känslor, spår jag blir den nya naturliga ingrediensen. Det påverkar oss så oerhört att det inte går att bortse från när vi skall  utveckla en produkt, en tjänst, ett informationssystem. Vi behöver lära oss mer om hur känslor fungerar, vilka käppar i hjulet de kan vara och vilka fantastiska möjligheter de ger. Människan handlar ju efter känslor och kan vi förstå dem och använda dem istället för att försöka bekämpa dem som något som inte hör hemma i professionella sammanhang, så tas ytterligare ett steg på vägen mot mer framgångsrik utveckling. Vi systemutvecklare skall alltså nu också bli terapeuter bortsett från allt annat. Det verkar inte finnas någon ände. Eller är det så helt enkelt att gränserna och rollerna börjar uppluckras. Att arbeta med ”system” börjar bli något som inte enbart är tekniskt. Vi behöver en spridd skara av människor och tvärvetenskapliga idéer för att lyckas.

Det andra ”känsla” då. Den där magkänslan, som är något annat. Att ha ”känsla” för något – att laga mat, att skapa musik, att förstå människor, att designa vackra och användbara gränssnitt, att förstå användare, att bygga en hållbar systemarkitektur, att skapa strukturer i en viss domän. Det är kreativitet. Att bejaka ”känslan” vi har för diverse områden lär också vara nyttigt för att uppnå våra mål och hitta mer användbara, innovativa och hållbara lösningar.

Känn efter – eller kanske före i fortsättningen?

Går det att jobba ihop fast man har olika mål?

En gång var jag underkonsult till ett företag vars mål låg väldigt långt ifrån mina. Det insåg jag snabbt. Huvudkonsulten hade som enda mål att tjäna pengar, snabbt och mycket. Mitt eget huvudsakliga mål var att skapa snygga och användbara webblösningar av hög kvalitet. Vi hade olika uppfattningar om hur man kan tjäna pengar. Jag tror inte min är den rätta för att tjäna pengar snabbt i alla fall men tullar man för hårt på kvalitet och inte har någon riktig kärna i produktidén tror jag att det måste bli svårt att få en vinst.

Nåja, vårt samarbete varade inte så länge även om vi personligen gillade varann. Fortfarande har vi kontakt och dricker gärna öl ihop om tillfälle uppstår.

I ett annat jobb hade jag en chef som också hade helt olika mål med sitt arbete än jag. Ungefär detsamma som ovan, han ville göra snabba klipp helst och bli rik medan jag ville bygga bra webblösningar med nöjda användare. Vi gillade också varann personligen. Det här samarbetet varade mycket längre och gick mycket djupare. Vi hade och har fortfarande stort förtroende för varandra fast det är längesen och skulle tillfälle uppstå skulle inte jag tveka en sekund att jobba ihop igen.

Så vad var skillnaden i dessa två situationer med samma ”indata”? Vad gjorde att vi i det andra fallet snabbt byggde upp ett starkt förtroende och i det första fallet i princip lämnade varandra, eller jobbade väldigt ytligt ihop?

Yrkesmässig personkemi förutom den personliga? Delade allmäna privata värderingar? Fokus? Gemensam uppfattning om hur man kan tjäna pengar?

Hur kan jag känna igen möjligheterna till långsiktigt samarbete nästa gång? Ja, på mitt nya jobb fick jag samma känsla för min nya kund och sedemera chef tror jag som vid det där andra tillfället. Den omtalade magkänslan. Det här känns bra till skillnad från det här känns inte helt bra som jag spontant kände vid det samarbete som inte fungerade så bra.

Är det så att vi skall gå bara på magkänsla när vi väljer samarbeten? Ja, kanske. Lita på första intrycket. Kan det vara så enkelt?

Vore roligt med några idéer och kommentarer på detta.