Archive for April, 2014


Management Time: Who’s Got the Monkey?
Är en underbar artikel som publicerades i HBR för länge sedan och berättar inlevelserikt hur en ledare vandrar ner för korridoren och bär med sig fler och fler ”apor” till sitt arbetsrum som redan är fullt med sin egna och andras ”apor”. Med apor som en metafor för olika tidsinskränkningar och åtaganden så visualiseras bilden kring ”apor” som omhändertas på ett kreativt och visuellt sätt.

Denna artikel är än idag relevant och påminner oss om att vi bör endast ta hand om våra egna ”apor” och hitta vägar att återföra andras ”apor” till sin rätta ägare. Mina funderingar idag är även kring hur vi hanterar aporna i en snabbfotad agil miljö, där vi har gemensamma ”apor” och vissa kan betraktas som slöseri enligt Lean. Enligt de sju slöserierna (muda) som Shigeo Shingo identifierade vid sina studier av Toyota Production System är ju överproduktion den värsta typen av slöseri och vad händer då med de stackars ”aporna” som inte håller måttet eller som reproducerar sig kan man undra.

Enligt sägnen så blir man expert om man gör något i 10 000 timmar och om man tar hand om metaforiska ”apor” i ca 10 000 timmar så borde man bli expert på att hantera ”apor”, vilket är något som jag tror många av oss har gjort, men är vi alla experter på att hantera ”apor”? Känns inte riktigt så, man kanske måste blanda in fler element, så tänkte vi kunde dela upp våra  ”apor ” i några olika klassificeringar, ”apor” som du älskar, ”apor” som är bra för världen, ”apor” som du hanterar bra, ”apor” som du får betalt för och så metaforiska jätte Gorillor i mitten som kungen bland ”aporna”.

blog.yllemo.com - vem har dina apor

Är det Gorillorna som ligger i mitten som är de mest meningsfulla ”aporna” eller är det någon annan sorts ”apa” som skall favoriseras,  det är en fråga. En annan fråga är ju om du inte matar ”rätt apor” så vem matar då dina ”apor”?

Som konsult så är det viktigt att kunna redogöra för nyttan man skapar (vilka ”apor” man har hand om) och nyligen så postade IDG en artikel med 10 tips för att bli en bättre konsult. http://www.idg.se/2.1085/1.558324/10-tips–sa-blir-du-en-battre-it-konsult , kanske borde lägga till insikten kring effektiv tidshantering genom ”apor” som tips 11 på den listan då tidshantering är en viktig aspekt för att bli en bättre konsult.

”Vill du ha något gjort? Fråga någon som har mycket att göra”, har jag hört någon säga och det låter kanske logiskt i vissa sammanhang, men när det kommer till ”apor” så är det den ”ap-skötare” som endast vårdar sina egna och rätt sorts ”apor” effektivt man bör fråga istället för den med flest ”apor” att sköta och då helst en som har mer än 10 000 timmars erfarenhet i att hantera just den typen av ”apor”.


Tittar man på ett historiskt perspektiv kring systemutveckling så ser man att det har hänt mycket kring antalet roller och verktyg som är involverade under hela livscykeln. Mängden kommunikationsvägar  har samtidigt ökat radikalt, det är betydligt fler specialister med i utvecklingsprojekten än tidigare och det blir därmed svårare att avläsa status då det behövs aggregeras data från fler källor än tidigare.

kommunikationsvägar systemutveckling alm

Det är kanske inte så ovanlig att specialister vill ha de bästa verktygen för just den specialiseringen man nischat in sig på, som exempel så vill ju gärna testproffs använda sig av Test Management verktyg och programmerare vill ju gärna ha effektiva källkodshanteringssystem. Börjar man lista dessa specialist system så blir det snart en gedigen lista och det är inte alltid så lätt att få dessa system att kommunicera med varandra utan manuell handpåläggning.

Det finns en formel för att räka ut hur många kommunikationsvägar som finns givet antalet kommunikatörer, formeln är n*(n-1)/2 och används ofta inom projektledning för att räkan på hur många kommunikationsvägar som måste hanteras. Som exempel så kan vi tänka att ett systemutvecklingsprojekt består av 10 personer så blir kommunikationsvägarna mellan dessa 10*9/2=45, alltså kan kommunikationen färdas på 45 olika vägar.

Denna formel går även att applicera på verktyg som systemutvecklare behöver använda för att bedriva effektiv systemutveckling. Om vi tänker oss att det finns 10 olika verktyg för systemutveckling (så som verktyg för programmering, källkodshantering, dokumentation, rapportering, krav, test, arkitektur, tidsrapportering, bygghantering och drifthantering) då blir även detta 45 olika vägar som information kan tänkas behöva flyta för att få effektivitet i flödet. Enligt min erfarenhet så är det inte så många organisationer som lägger samma vikt vid denna typ av kommunikationsvägar som i projekten, men det borde man för det minimerar waste (se Lean) och förbättrar kvalitet på resultatet. Detta argument är centralt i ALM (Application Lifcecycle Management) verktyg, där fokus är att länka samman alla verktyg och underlätta för hela systemutvecklingsflödet både mellan människor i sociala relationer och mellan verktyg och informationsflöden däremellan.

Är man ansvarig projektledare för ett större systemutvecklingsprojekt och får den vanliga frågan ”Hur går det?” så blir ju svaret ofta ett konsultsvar – Det beror på…
Det är ju så många olika saker som väger in och det är ofta svårt att få insikt om hur det faktiskt går vid en given tidpunkt och ibland kan det faktiskt vara så illa att man inte ens har möjligheten att införskaffa sig insikt då det är för många kommunikationsvägar som saknas eller inte är kompatibla.

 
Vi vill ju ofta arbeta mer agilt och i många kortare iterationer vilket är bra då man efter varje cykel kan avgöra om man behöver ändra riktning. För att denna process skall fungera optimalt så behöver även verktygen samspela effektivt över hela applikationen så det inte uppstår köbildning i någon instans där informationsflödet kan komma ur synk. Genom att samordna verktyg och processer för att aktivt hantera alla kommunikationsvägar över hela applikationslivscykeln så faciliteters även de sociala kommunikationsvägarna.