Det är ju så lätt att programmera

3 02 2010

Är det inte märkligt hur många det är, som aldrig, eller nästan aldrig, har programmerat själv, som har så starka åsikter om hur lätt det är att programmera?

Som anser sig kunna avgöra hur lätt eller svårt det är att

- programmera ett system
- integrera ett system med flera andra
- att bygga ett GUI
- att testa
- att produktionssätta
- att drifta
- att dokumentera
- mm

och som också anser att en programmerare bör kunna alla verktyg, alla versioner, i alla tekniska miljöer och alla tänkbara applikationer det aktuella  utvecklingsprojektet är beroende av.

Vad vet du om programmering egentligen?

Skulle du som icke-ekonom, t.ex gå till ekonomerna som påstår att det är mycket och svårt att göra bokslut i år ställa dem mot väggen – hur svårt kan det va? Du är ju ekonom, det här har du ju gjort varje år, gud vet hur länge?

Skulle ekonomen möjligen uppfatta det som respektlöst beteende?

”Jag ser en risk i att bokslutet inte stämmer, pga ett antal oklara faktorer”

”Hur kan du påstå att det är en risk, det är väl bara att räkna, fram med kulramen bara!”

Det finns flera lätta sätt att ta reda på hur lätt eller svårt det är att programmera något, även för en icke-programmerare.

1. Besök varje morgonmöte / Scrum-möte i ett aktuellt team under 2 veckor, eller kanske bara 2 dagar. Lyssna på samtalen och du kommer att förstå.

2. Fråga om du får sitta bredvid och parprogrammera, som en trainee, under 1 vecka i ett utvecklingsteam. Eller eventuellt sitta bredvid och bidra med någon annan del, t.ex testning eller interaktionsdesign. De kommer ta emot dig med öppna armar, och du kommer att förstå.

Vill du verkligen veta?





Veckans ord: Innovation

15 12 2009

Hur och när inträffar innovation?

Hur ska vi lyfta blicken och sluta analysera och börja nyskapa?

Analys är bra till mycket, men kanske inte  just för innovation?

Vad ska få oss att tänka utanför våra rutiga boxar och pilar? Behöver vi alltid en Steve Jobs i teamet? Eller en konstnär? Eller räcker det med att vi drar ut på en tur på häst tillsammans? Eller sätter oss på ett café istället för i ett konferensrum?

Eller att ha anteckningsboken bredvid sängen?

Vad är ditt tips för innovation?





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: Förtroende

12 12 2009

Vilka underverk man kan skapa genom förtroende.

Senaste veckan har jag både fått och gett förtroende och det jag fått tillbaka är omtumlande om inte förvånande.

Jag är nära att tacka nej till ett arrangemang där jag är osäker på målgruppen och något osäker på temat. När jag försöker tacka nej till uppdraget övertygar beställaren mig att jag är rätt person för uppdraget. ”Jag vet att du är rätt person, du SKA göra det här.”. Jag bestämmer mig för att nog tacka ja och tar med mig en person som erbjuder sig att följa med och samarrangera, en person jag knappt känner men som jag har en stark känsla av att det här är rätt person. Har aldrig jobbat med henne tidigare. Jag ger henne förtroende att ta fram innehåll för en del av kursen och under detta bestämmer jag mig för att lita på intuitionen och låta henne tala till punkt och komma med sina idéer för ett för mig riktigt förtroendeuppdrag – jag får inte misslyckas.

Resultatet? Ja, jag har inte fått all feedback än, men direkt efter kursen fick jag spontan feedback från några deltagare som tyckte att det var fantastiskt bra och att de lärde sig mycket.

Sådan feedback och sådant genomförande får man endast genom att VÅGA få och ge förtroende.





veckans ord: Influensa

22 11 2009

Det får tyvärr bli veckans ord. Vilket ord är vanligast förekommande i din omgivning just nu..?

Sittande bredvid sjuka barn undrar jag om det är mediepådraget som gjort att jag ser på dem nu som om de fått en sjukdom i stället för som förra året, och alla andra år, en förkylning med feber och hosta. Och att jag är så himla medveten nu om dess ankomst och vågrörelser i samhället och omkring mig.

Att en yrkesmässigt mycket nära person råkat ovanligt illa ut spär på medvetenheten och osäkerheten.

Vad har det med projektledning och system att göra då? Ja, som vanligt (?) är det en himla massa projekt som drabbas av frånvaro. Viktiga möten är  inte så viktiga helt plötsligt, jag får vara glad om det går en eller ett par dagar enligt kalendern.

System – är det ”systemet” som gör att vi nu är så vansinnigt medvetna om denna tråkiga flunsa? Eller är den värre än tidigare? Hur många brukar egentligen vara frånvarande den här tiden och hur länge? Varsågod, den som har några svar.

 





På spaning: Projektforum 2009 – Är projektledare fyrkantiga eller runda?

19 11 2009

Under två dagar 18-19 november som deltagare och talare hade jag också uppgiften att göra en spaning. Jag valde att fånga upp trenden om projektledare är fyrkantiga eller mer cirkulära i sinnet idag. Spaningen är naturligtvis utifrån de seminarier och föredrag jag själv valde att gå på och försökte också lyssna på andra deltagares uppfattning om konferensen.

Denna konferens hade temat ledarskap & beteende, och lockade i år dubbelt så många deltagare (ca 250) som förra året vilket bara det visar en tydlig trend att projektledare idag är mer intresserade av just ledarskapet snarare än verktyg och modeller.

Jag såg att även de mest fyrkantiga talarna, t.ex ordförande för IPMA, inledde sina tal med mjukare frågor och trender. Klimatfrågan och interkulturellt samarbete stod högst upp på hennes trendanalys. Det är vår planet vi alla nu vare sig vi vill eller inte måste fokusera på – och har börjat göra.

Don’t waste the crisis var hennes budskap – Krisen triggar förändringar, beslut, sökande efter mening och turbulens som tvingar oss till handling.

Att lösningen för hennes del är att alla certifierar sig är hennes mission. Ett annat av hennes som många andras budskap är att hitta de projekt som EJ bör göras. Låter som en rätt så ”agil” princip i mina öron.

På ett verktygs-föredrag som handlade om hur man effektivt kan införa projektverktyg som kan låta torrt och tveksamt för en agilist så pratade även han om verktygen som att man bygger in verksamhetskunskap i dem, vilket lätt glöms bort. Ställ verktyget mot andra alternativ. VAD kan vi tjäna på verktyget? Vad är nyttan för olika användarroller? Inför verktygsstödet i etapper, i stället för big bang-lösning. Få de manuella processerna på plats först och ha alltid en mottagare.

Han berättade om en medarbetare som fem i tolv innan de skulle äta lunch tillsammans sa att ”jag ska bara fylla i min statusrapport” Efter två klick var han klar. Oj, vad fort det gick frågade vår man. ”Ja – jag skickar samma dokument varje gång tills någon säger till”. Skratt

Låter som ett rätt agilt tankesätt eller hur? Även verktygsmännsikor (inte alla men många) pratar lättrörlighet och nytta.

Intressant fråga på slutet – ”verktygsprojektet ska inte lösa processfrågan” – obesvarat denna gång. Jag diskuterar gärna vidare..

Den ”mjukaste” talaren var nog ändå Barbro Curman – Gestalthuset. Hon pratade HJÄRTA. Vi behöver agera med hjärtat, våga säga det alla vet, våga vara kreativa, innovativa. Civilkurage ger framgång. Ta vara på potentialen och den förnyelsebara energin inom människan. Vi kan åstadkomma underverk med klimatfrågan, med våra projekt, med vad vi vill om vi ser att vi själva ÄR miljön. Naturen är inget på sidan om, vi är naturen.

Jordens största slöseri kallade hon den mänskliga energin som inte tas tillvara. Mänsklig energi som riktas mot samma mål kan försätta berg.

Det behöver inte vara så krångligt.

Problemen med klimatfrågan handlar om konflikter och girighet som hindrar att vi kommer fram.

Prata högt om det egentliga problemet.

Som projektledare vet vi aldrig vad vi trampar på för minor i kulturen.

Vi kan göra något där vi är med drömmar, önskningar, visioner

Vi är ett fält av potentiella möjligheter. Vi behöver skapa nya färdigheter – nya strukturer.

Jag ser en underström av mogenhet för mjuka värden.

Vi är grottmänniskor för att skydda oss själva – genom att bli medvetna om det kan vi välja mellan att överleva – eller leva. Att agera utifrån rädsla eller Tillit är skillnaden. Det är först med tillit vi kan skapa nytt.

Feedback-boken av vår vän Gestalthusets Stefan Gunnarsson tar jag med mig hem. Rekommenderas.

Årets projektledare – väl värd sitt pris ser det ut som. Kaj Ahlbom från SKF, långtidslagring kärnkraft.  Han har lyckats med det som resten av världen brottats med i många år och med många medel. Receptet för framgången? Han & hans par-projektledare (formellt bitr.) fick bemanna hela teamet själva. Hela teamet brann för målet och syftet, alla älskade att borra hål i berg och undersöka lagring. De tydliga två målen var: Säkerhet och Acceptans – att få medborgarna med sig. Det fick de med hjälp av – ja – gissa en gång – Kommunikation kommunikation kommunikation och delaktighet

Tendens jag ser – många föredragshållare pratar högt om att ”vi vet att ni hört detta förut, slå in öppna dörrar mm – nu är det dags att agera.” Många tips och fokus på HUR. Vad kan jag göra som projektledare, individ, chef, medarbetare? Börja med dig själv. Andra härmar dig. Fantastiska projekt har börjat med ett fåtal individer.

Använd glädje – enthusiam – det smittar. Liknelse från Eva Kihlborgs om Karisma-koden. Nelson Mandela går alltid in genom en dörr med handen utsträckt för hälsning och ett stort leende. Vem kan inte bli glad med det bemötandet?

Kelly Odell. ”Det där med människor blir man tamejfan aldrig klok på” med sin härliga dialekt.

Som chef var plötsligt alla hans idéer även de halvbra (halvdåliga på svenska) fantastiska.

Kelly skojar om SAP, och de SAP-konsulter (?) som satt längst fram i bänken. ”De företag jag sett har varit precis lika bra som innan – SAP förstörde INGENTING!”

”Jag tror inte man kan förstöra ett bra företag genom omorganisering” men det är bättre att förbättra det som redan finns.

Kelly pratar mycket om resurser för kompetens, lärande, uppmuntran, kunskapsutveckling. Att räkna med det i budget. En filmproduktion anses inte värd att lägga 100 miljoner på om den inte är minst värd lika mycket i marknadsföring.

Förändringsarbetet i sig bör finnas med i budgeten – projekt är ju oftast en förändring i sig.

Han säger en himla massa kloka saker kort sagt. Rekommenderas. Deltagarna är med. Flera av mina fördomar krossas. Fördomar jag kanske haft om vad jag trott jag skulle möta för människor på en konferens ordnad av en (tidigare?) så fyrkantig organisation.

Kellys och hans sidekicks budskap är mod, ärlighet, våga prata om det ingen annan vågar

De flesta kan klara kriser och förändring, bara vi pratar om det.

Är det någon som fått ett buskap överkommunicerat från sin ledning..? Det finns inte överkommunikation om förändringar.

När vi står på våra kickoffs med ballonger och stand-ups, se till att ha kommunicerat före, under och efter, många många gånger. Intranät och e-post är sällan rätt hjälpmedel.

”Om jag inte sagt det till den har den inte hört det”

Kaizen och Go See -ledarskap.

Vibeke Paulhagen, VD tidningen Chef, pratar lite kontrast på sitt- Gå UT ur gruvan, sluta vara en medarbetare hela tiden och gör allt jobb, se till att som ledare få SYRE upp i luften och ge dig tid att tänka.

Kontraster använder karismatiska personer i sina tal – säger Eva Kihlström (Karismakoden). Vilket bevisas när Stefan Einhorn avslutar med en fantastiskt föredrag med många vardagliga exempel, kontraster  och  GÅ HEM OCH GÖR.

Det finns massor med att säga, massor av intressanta deltagare och talare  och jag kan bara konstatera att de allra flesta projektledare jag möter här är långt ifrån fyrkantiga.

Och att även de riktiga rundisarna faktiskt har en del fyrkantighet i sig som är svår att få bort – att alltid stärka sitt budskap med siffror och ”det finns studier på det här..” är vetenskapen alltid sanning undrar jag?

Så vill jag ju naturligtvis nämna Thomas Lundqvist – tidigare vd Junibacken och hans biologiska ledarskap som en av de mer praktiska och konkreta – gå hem och gör – övningarna. Ska prova och har omedvetet redan provat under dessa dagarna en del lättvunna beteendevetenskapliga sätt för kommunikation och förändring och acceptans. En fyrkantig metod som ger cirkulära och mjuka resultat!

Jag kan också se att många med mig är överens om att gränsen mellan projekt och verksamhet verkligen håller på att luckras upp. En befriande tanke. Vi vill alla åstadkomma nytta och ha kul samtidigt!

Tack alla talare! Och nyfikna glada runda fyrkantiga deltagare!





Veckans ord: Tid

16 11 2009

Just nu rapporterar jag tid i fyra (!) olika system, för olika syften.

Jag undrar hur många timmar som läggs ned på tidrapportering per år av konsulter bara i Sverige..?

Därmed inte sagt att jag inte gillar att ha koll på tiden, tidsfascist som jag är.. men man kan ju inte låta bli att reflektera.





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.





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

23 09 2009

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)?

21 09 2009

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?