2 dagars agil coachning av 150+ proffs för 2000 spänn

Tycker du det är dyrt med agil coachning? Missa inte konferensen Agila Sverige nästa år, som just gick av stapeln i Stockholm. Där får du 2 dagars professionell coachning av 150-200 erfarna ledare, utvecklare, designers, testledare, projektledare, verksamhetschefer, IT-ansvariga, filosofer,  pedagoger, samhällsvetare mfl

Insikten kom till mig på vägen hem. Denna återkommande konferens, ordnad i enkelhetens namn, innebär oavsett om du är proffs eller rookie i området att du får 2 dagars personlig coaching av väldigt många agila proffs och möjligheter till att ta del av erfarenheter, nya och gamla kontakter, roliga historier, personliga samtal, rådgivning, underhållning, praktiska tips och filosofiska resonemang om kommunikation, design, system, teknik, politik, religion, verksamhetsutveckling, organisation, teamutveckling och allt annat nödvändigt för att vi ska kunna leverera det våra organisationer är till för – att skapa en kund – må den vara medborgare, medlem eller konsument.

Det är nu 5:e (?) året jag deltar och utbytet ökar. Fiskdammen har mognat till ett event av direkt, praktisk och filosofisk coachning.

Några ämnen som var uppe som jag lyckades fånga

- Form och funktion – är samma sak. Varför skilja på design och utveckling?
- Inkludera människor i ditt team istället för envist försöka assimilera. Bjud in!
- Tänk nästa steg när du funderar på att byta riktning – vad kommer efter ditt val nu?
- Metodöverflöd. Det finns en enorm mängd fantastiskt användbara metoder idag för att leverera nytta – Innovationgames, Lean Startup, Real Options, UX (User Experience Design)-områdets stora skara av metoder, Stop-the-Line, Kanban, A3-förbättringar, Toyota Kator, Enkla checklistor, Programming Anarchy… listan kan göras oändlig. Välj en – prova på i 30 dagar, utvärdera, förbättra och/eller välj en annan nästa 30 dagar.
- Det finns goda exempel på hur verkligt självorganiserande organisationer kan fungera, se t.ex Valves handbok för nyanställda även Länsstyrelsen Karlskrona omnämndes i det sammanhanget. Hade velat höra mer om
- Kommunikationsskuld. Den skuld du bygger upp genom att avstå från nödvändig kommunikation. Ungefär som teknisk skuld. Det du inte gör något åt idag börjar du betala ränta på, skulden växer tills dess du tar i tag och börjar betala av skulden. Hur har du det med kommunikationen med dina leverantörer eller beställare egentligen..?

Agila Sverige är ett smörgåsbord av tillfällen till coachning och lärande.

Nya boktips från pedagogiska mästaren Tobias Fors – The Power of Learning och Thinking fast and slow

Om man upprepar något tillräckligt många gånger blir det sant. Några saker behöver upprepas och påminnas om många gånger, bl.a perceptuell blindness, testa själv på

Awareness Test: Basketball players

Har du verkligen koll på allt?

Och det ständiga upprepandet av mantrat:

”Be inte om tillåtelse, be om ursäkt efteråt”

kommer snart ge resultat i våra organisationer – förväntar mig större turbulens och större förbättringar på arbetsplatserna för kunskapsarbetare närmsta åren..

Och sist men inte minst, den ständigt och självklara upprepandet på denna återkommande konferens – frågan

VARFÖR?

Det resonemanget tror och hoppas jag blir nästa års fördjupning.

Tack till arrangörernas idealistiska och aldrig svikande engagemang för att se till att vi har ett forum som utan att kosta skjortan kan ta oss ytterligare ett litet steg framåt i evolutionen av våra system.

Snygga bilder på några av dessa 150+ coacher finns här…  fotat av.. vem var det? Joakim S?

Foton Agila Sverige Dag 2
Foton Agila Sverige Dag 1

Tests aren’t about testing – Scandev 2012

At Scandinavian Developers Conference April 2012 there were some rememberable messages about testing – what I heard tests aren’t anymore about testing, if it’s ever has been.

Kevlin Henney @KevlinHenney first mentioned the message on testing in his keynote which was really about architecture and good coding – such as economy, visibility, spacing, symmetry and emergence.

About testing he said,  the point of automated tests is NOT how many tests you have,  it is in the meaning of them. To explicitily state rules, to know exactly what we mean in a row of code – that’s the point of testing

Tests turns belief into knowledge.

Gojko Adzic, @gojkoadzic, test and requirement change agent, told us the story of a French team that threw away their automated tests as soon as they’ve passed.  They used automated tests as a

shared understanding of what to do very effectevily

rather than a tool for testing.

He busted a lot about myths of BDD (Behaviour Driven Development) and the challenges on understanding of it from business. He called it

Businessting – the belief business users could write acceptance tests

I’m happy he brought this challenge up. I’ve seen so many teams waiting for business to suddenly show up with very clear, ready to automate, covering test specifications at exactly the right level. Gojko reminded us of the importance of conversation with business people on the rules, on the examples, on the code that’s gonna be written.

The main benefit of Behaviour Driven Development is that is supporting us longterm with information on what the system does – therefore you don’t always need to keep them tightly integrated to the code when they have passed once (!)

We’re obsessed with wrong details.

Jeff Patton,  reminded us also of conversation with business, and of the thing many of us seem to have forgotten about user stories.

User stories, no matter in what written template, was in the beginning there for the purpose of making business people telling stories! Stories about what’s happening in the business, and what could be happening in the future. Now many asks about how to write correct user stories, rather than asking their business person to tell.. their story.

So whatever we do we need to find ways to include business people in our daily conversations 

This seems to be the greatest challenge when it comes to Agile.

Mary Poppendieck, always insightful, brought the subject up of the importance of whole product team. She said we need to let go of ”software development” and talk about what we’re actually doing – product (or service) development to get business on our team so we can do great products and services.

If we believe in whole product teams, which I guess we do if we want to deliver good stuff, software development teams need to start to talk about products (and services)

Go from programming language to design language.

Projektledare – behövs de?

I torsdags kväll (25/8 2011) arrangerades debatten ”Projektledare – behövs de?” på Villa Ludvigsberg, Frontit/ProjektStyrning tillsammans med Dataföreningen Stockholm (projektledarnätverket). 50 reflekterande deltagare dök upp, och i startpanelen satt Andreas Larsson, Olof Melinder, Torbjörn Gyllenbring, Anders Ivarsson, Hanna Wallin, Carina Meurling och jag själv. Markus Ekelund, VD på Frontit modererade.

Upptakten var debatten som då och då blossar upp i diverse forum, än mer på sistone ju mer agile-rörelsen sprider sig. Vad ska vi ha projektledare till? Är det en utspelad roll på samma sätt som maskinskriverskor? Förhindrar projektledare ansvarstagande hos andra, eller är de nödvändiga för att nå ett resultat, koordinera och vägleda en grupp människor framåt som ska utföra en uppgift..? Är ScrumMastern den nya projektledaren?

Många frågor ställdes. Besvarade vi frågan under dessa 2 timmar? Skulle vi uppfinna projektledaren på nytt om det inte redan var en inarbetad roll?

Efter 2 timmars sansad diskussion och berättelser om situationer där projektledarens närvaro eller frånvaro påverkat oss på olika sätt, upplevde i alla fall jag att de stora tankarna började smyga in. De 2 första timmarna var ett ömsom lyssnande på andras perspektiv och vädrande av sina egna. Vi kunde konstatera att vi har olika erfarenheter av projektledare – allt från maktgalna kontrollfreaks till coachande, uppmärksamma hjälpande händer.

Det behövs någon som hjälper teamet att kommunicera, utåt och inåt, kanske kommer framtidens projektledare kallas kommunikatör i stället? Eller coach?  Det behövs också någon som agerar paraply ibland. En klok person i publiken sa att när solen skiner och allt är toppen, vem behöver då ett paraply som stör rörligheten? Men när det regnar och öser ner, är inte ett paraply bra att ha då? Hur ofta jobbar vi egentligen i ideala situationer för självorganiserande team?

Det kanske räcker med en ledare nånstans i bakgrunden som krattar marken, och verkar men inte syns, tyckte vi efter Andreas Ivarssons berättelse om ett projekt där teamet agerade helt själva – men naturligtvis hade det både bemannats och skrivits avtal och hållts kontakter mellan ”gubbar” eller ”gummor” för den delen med höga hattar. Kanske av gubbar och gummor som förstått vikten av att inte lägga sig i i onödan, som låter teamet blomma själv och bara ser till att teamet får vatten då och då.

Efter 2 timmar, halvt utsvultna, började diskussionen handla mer om långsiktighet, effekter och ansvaret för detta. Vi tror att styrgrupper och ledningar framöver kommer att tänka mer långsiktigt. Kanske kommer projektformen användas mindre och inte lika ofta för systemutvecklingsinsatser. Kanske kommer effektledare tillsättas snarare än just projektledare.

Jag tror att med lite lagom mat i magen och en paus hade vi kommit ett steg djupare. Om vi fortsatt 1 timme till hade kanske  de väldigt kloka frågorna ebbat ut till förmor för fler tydliga insikter. Detta var början för en grupp projektledare eller f.d projektledare att reflektera med andra över frågan. En fortsättning är nödvändig för att kunna ge några svar, och ta höjd för att det då kommer säkert krävas 2 timmar startsträcka för att de riktigt visa orden och insiktsfulla svaren ska höras. Jag är säker på att vi kan det.

Det var många som ville stanna kvar en bra stund efter debatten, trots hunger och sen kväll. Detta tyder väl på att detta ska fortsätta.

Eventuellt får jag möjlighet att sammanfatta debatten på 3 minuter under ett blixttal på konferensen ALE2011  (nätverk för Agile & Lean Europe) om 2 veckor. Vad tycker DU som var med att jag absolut måste ta med mig från debatten då?

Tack alla som bidrog genom att bara närvara, eller genom att prata, till en fantastisk diskussion.

Agila Sverige 2011 – 10 år av agile

Varje gång jag ser programkod på storbildskärm kan jag inte låta bli att bli sugen igen, att göra det riktiga hantverket/konstverket. Nya språk, roliga saker som händer, monader & Scala, funktioner och kvalitetstänk gör att jag undrar ibland hur det skulle vara att prova igen.
Programming, motherfucker liksom.

Vi andra gör ju bara (?) Managment, asshole

Min stora miss!  Att inte delta i open x-sessionen där man skulle para kund/programmerare och utveckla något snabbt som attan till en marknad.  Var istället en stor behållning att se några vänners blixttal bland annat Jocke Holm i 4D-glasögon som siar en framtid där vi organiserar vår verksamhet utifrån-och-in på riktigt och verksamheten både drar (pull) i utvecklingen och deltar i den (vilket borde vara fallet redan idag, dock en optimistisk framtidsvision fortfarande).

Roland Bäcklin visar hur man mha improvment communities på Ericsson tror jag, arbetar med förbättringar i större skala – där en medarbetare committar sig till ett tillfälligt community som har ett visst mål, när målet är uppnåt upplöses communityt och medarbetaren kan delta i ett nytt om han vill. Förutsättning – 5-10% avsatt arbetstid för att arbeta med och implementera förbättringar i verksamheten. Boktips: Succeeding with Agile – Mike Cohn.

Medarbetare, motarbetare och vårt inrotade språk om att tala om oss själva och andra som ”resurser” var på tapeten. Tack Maria Thelin, Jaybis för den insikten under FishBowl-debatten som var en mycket lyckad start där många fick chansen att med väl valda ord uttrycka sin syn på 10 år av Agile.

Individens egna ansvar, teamets ansvar att bli självorganiserade – tänkte fler än jag själv över. Bland annat Petter Wigle som tycker att alla kodapor bör se sig själva som kodlejon i stället, att i stället för att passivt vänta på att få information – se till att skaffa den själva.

Deltog i intressant Open X om Economy of Gifts, att vi kan om vi vill börja organisera oss enligt devisen ”jag hjälper dig med något så finns det säkert något som du kan hjälpa till med i framtiden”. Komma loss ur budget- redovisnings- och tidrapport-träsket – kan vi själva kanske göra något åt det t.om, genom att bjuda på oss själva och inte be om lov – utan be om ursäkt efteråt? Det fungerar på många ställen. Kopplade dessutom väl till det Björn Elmberg talade om på #Webbdagarna – att gamla sanningar är på väg ut i business, nya på väg in – Sharing economy om jag minns rätt pratade han om.

Den största aha-upplevelsen – #OutdoorFriday med Martin Persson. De arbetar utomhus en dag i veckan, för att stimulera hjärnan, hjärtat och kreativiteten – komma ur våra bunkrar, stänga av laptopen, packa en termos och ett liggunderlag och sitta ute, t.om i Februari. Med mer än märkbart resultat. Inspirerar mig att göra det jag bara tänkt länge – att ta med viktiga intressenter på kreativa möten utomhus. Uppbackat av forskning. Det var inte så svårt upptäckte vi under ett OpenX där vi helt plötsligt befann oss utomhus.

Almut Herzog berättade om att starta upp projektet med ”Inception Deck” – ett sätt att få projektteamet med på tåget, väntar in hennes presentation att länka här.

Hans Brattberg, inspirerar om att ge feedback i smått och stort med hjälp av tekniken Perfection Game där tre frågor ställs: Vad ger du mig för betyg på det här? Vad gillade du med det? Vad skulle jag göra för att uppnå det perfekta betyget?  Fråga att använda i team-retrospektiv: ”Hur skulle en perfekt sprint se ut?”

Fantastiskt många bra & underhållande tal i år, givande fikapauser, riktigt drag på middagen.

Tre saker som lyste igenom:
- Eget ansvar för att uppnå det vi vill
- Det behöver inte vara så svårt
- Testning ur alla perspektiv, exploratory, visualisering, automatisering, bdd’s vara eller inte vara, specflow..

Härligt nördig och samtidigt både mänsklig och väldigt medveten konferens som tidigare. Kvaliteten helt klart högre i år både på tal och open space, även om det var lite tunt med postningar på open x-schemat med tanke på det debattglada klientelet.

Vi saknar nästa generations deltagande – vad går 90-talisterna och funderar över därute på sina campus? Något för nästa år gissar jag. Också tvärfunktionella konferenssamarbeten är nästa naturliga steg, det är många som vill i olika forum.

Kram på er! We are the system, society & change.

Early bird – AYE conference – för ledare

En konferens att gå på för den som vill utveckla sitt ledarskap, teamförståelse, organisationsmönster, systemtänkande.

Garanterat No Slides!

Early bird ett par veckor till.

Vem vet, vi kanske ses?

Esther Derby, Jerry Weinberg, Johanna Rothman mfl

http://www.ayeconference.com/schedule/

 

 

Veckans ord: Mål

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?

Städning för projektledare

Städar upp bland anteckningar och lösa papper, anteckningar som skrivits ner i dialog med mina kära kollegor och vänner inom krav & projektledning.

En del värt att spara.

”Det är vi som projektledare som kan se det goda i att göra misstag och vända dem till lönsamhet och kundnytta!”

”Det är vi som står för tron och uthållighet.”

”Projektledare är förändringsledare i stället för mikro managers”

”Det är en illusion att det går att neutralisera kunskap och göra en allomfattande dokumentation”

”Ju mer folk, desto svårare blir det!” (varför agerar så många precis tvärtom? Att tro att med fler händer så går det säkert fortare..)

”Målgruppsanalys kan ge oväntade insikter” – lästips Swartling

”Det är vårt ansvar som projektledare, produktägare och ScrumMasters att se till att lärande prioriteras och får ta plats i kravprocessen. Lärpengar lönar sig”

Oj, den var svår, hur lyckas vi med det?  Säga till kund ”Det gör inget att vi byggde fel, att vi hade fel hypoteser från början, att det vi gjort hittills inte genererat värdeskapande funktionalitet, däremot många bra insikter så att vi nu kan göra (mer) rätt”

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?