Blogginlägg 8.1

I ett sista inlägg kommer jag nu sammanfatta de tankar jag bollat under denna wallrafande resa i ett svenskt storbolag. En hårdvarukilles tankar om mjukvaruutveckling finner du här nedanför.

Från att aldrig ha sysslat med mjukvarurelaterad produktutveckling utanför gymnasiet och universitets skyddande murar har det varit en mycket lärorik resa! Skillnaderna mellan mjukvaruutveckling och hårdvaruutveckling trodde jag skulle vara större. Ser en tillbaka till blogginlägg 1 där jag försökte beskriva skillnaderna mellan olika typer av kundfokus håller jag fast till den teori jag framförde: att avdelningen jag varit en del av arbetar mer kundnära än tidigare utvecklingsprojekt jag arbetat i.

En viktig skillnad jag upplever mellan att utveckla hårdvara och mjukvara är benägenheten att ändra saker sent i projektet. Det får även stöd i litteratur i ämnet (Magazinius, 2012), men jag tycker mig ha sett att utvecklingsteamet haft stort intresse av att faktiskt göra något bra, mer gärna än att hålla fast vid tidigare beslut. Om det gäller mjukvaruutveckling i stort, eller är en del av den kultur som finns i teamet vet jag inte. Men även om det är lättare att radera 20GB kod än att skrota produktionsutrustning i en fabrik så kan antalet ingenjörstimmar mycket väl vara de samma. Därför borde de mänskliga reaktionerna på att just DITT bidrag tas bort från produkten vara liknande, oavsett om du utvecklar hård eller mjukvara.

Att arbeta agilt i team så som avdelningen gör kan också spela in till hur teamet ser på förändringar. Jämför jag med hur jag själv arbetar i min enskilda firma finns likheter, speciellt när det kommer till dokumentation och kraven på standardisering, mellan hur utvecklarna arbetar på bolaget och hur jag arbetar med små firmor i Göteborgsregionen. Fokus ligger på att få en fungerande produkt, snarare än att följa etablerade tillvägagångssätt. Det är absolut inte så jag arbetat på storbolag förut. Där har fokus varit att följa etablerade metoder och minsta förändring ska testas enl. konstens regler. Den snabba utvecklingstakten i projektet har dock ökat kravet på dokumentation, och samtidigt som jag började anställdes också 2 personer som enbart ska syssla med att dokumentera produkten. Det om något borde peka på att det finns en anledning till att arbetsprocesserna i stora etablerade bolag är stelbente, det funkar helt enkelt inte annars.

Å andra sidan behöver du släppa tyglarna för att nå innovation i organisation, blanketter och formulär har inte skapat en enda uppfinning mig veterligen. Det är därför sektionen avdelningen tillhör är frånkopplad huvuddelen och där med befriad från mängder av byråkrati.

Jag ser det som en pendel, du behöver ibland släppa kontrollen och låta bolaget arbeta mer fritt, för att ett tag senare strama åt svångremmen och styra upp den brokiga idéverksamhet som tagit form. Kanske frihet föder idéer och kontroll föder lönsamhet? Det ska hur som helst bli intressant att följa alla de agila nystartade bolag som poppat upp likt svampar i granskog den senaste tiden. Kommer agila lättrörliga metoder gå hand i hand med när konkurrensen hårdnar och ägarna kräver mer avkastning på investerat kapital?

De ingenjörer och andra produktutvecklare som bär upp alla produktutvecklingsorganisationer, har de i och med agila metoders framväxt sedan agile manifesto såg dagens ljus 2001 fått högre fart genom vattnet, eller är det samma gamla arbete fast klädd i ny skrud? Som det ser ut nu har jag svaret om ca 40 år när jag själv en dag lägger ingenjörskarriären på hyllan. Håll till godo.

Slutligen, och detta är något jag kanske borde göra till en LinkedIn status eller sprida på annat vis. Det är ingen större skillnad på att utveckla hårdvara kontra mjukvara om du skalar bort de rent produktspecifika attributen som hur du realiserar dina idéer och eller om produkten går att ta på eller ej rent fysiskt. För när allt kommer omkring så ska som utvecklare skapa en lösning som möter en kunds krav, no more no less. Sedan om du skriver kod, instruktioner eller drar streck i Auto Cad är bara olika sätt att logiskt lösa givet problem.

Referenser:

Magazinius, A. (2012). Exploring Software Cost Estimation Inaccuracy. Göteborg: Department of Computer Science and Engineering, Chalmers.

Blogginlägg 7.1

Detta inlägg spinner vidare på blogginlägg 5, i vilket kostnadsestimeringar i utvecklingsprojekt avhandlades. Då diskuterades forsknings och litteratur läget gällande kostnadsestimeringar och deras tendens att vara oriktiga. Inför detta inlägg har gruppchefen på den avdelning jag varit en del av fått ge sin syn på hur kostnadsförutsägelser påverkar hans jobb.

Budgetering är en process som årligen noggrant arbetas igenom på avdelningen. Sektionen får en summa pengar avsatt för R&D, från vilken de olika avdelningarna sedan söker en del av. Klassisk top down fördelning (Pinto, 2013) där bolagets ledning beslutar om utvecklingskostnadernas maximala storlek. Det hade varit intressant att veta vilka processer som leder fram till den faktiska summan, någon historisk koppling lär ju göras. Tyvärr är det organisatoriskt svårt att komma åt personer i top management skrået som har insyn i dessa processer. Från ett utvecklarperspektiv, och även avdelningschefens perspektiv kommer dock denna summa förvisso vara levererad “uppifrån” men eftersom det är flera sektioner som delar på budgetutrymmet spelar deras egna estimeringar stor roll.

Avdelningschefen berättar att han inför varje budgetarbete skapar en prognos för nästkommande år baserat på fjolårets räkenskaper. På så vis kan en också mena att budgetarbetet på avdelningen är en Bottom Up process, i vilken historisk data används för att förutspå kommande utgifter. Forecastmetoden (Pinto, 2013) är en metod som liknar det avdelningschefen beskriver. Den data som ligger till grund för prognosen består mest av head count kostnader, eftersom avdelningens största utgift är just personal.

Men även om kostnaderna för var anställd är relativt enkla att förutspå (Lön, sjukdagar, semester osv) så är kostnaden per värdeökande produktutvecklingstid mer komplicerat. Du kan inte bara översätta förra årets kostnader rakt av, utan måste ta hänsyn till att teamet blir mer sammansvetsat och att uppgifter går snabbare att utföra då personalens kunskaper ökar. Avdelningschefen beskriver läranade som en viktig aspekt. Han menar på att takten i vilken antalet features som implementeras i produkten ökar allt eftersom ett utvecklingsteam mognar. Processen beskrivs och teorin bekräftas också av Pinto samt annan Project Management litteratur.

Exempel på lärkurva (Pinto, 2013)

Men projekt förändras och avdelningschefen tar upp dessa förändringar som osäkerhetsfaktorer i sin estimering. När produkten mognar kommer fokus förskjutas från utveckling mot service, vilket både kräver andra kompetenser men en stundande kommersialisering i stor skala ställer också krav på organisationen. Det kan bland annat handla om att fler system i drift betyder fler varianter av produkten, och att ställa tillrätta eventuella felaktigheter kan kräva stora ansträngningar från personalen.

Slutligen, agil utveckling, eller egentligen all utveckling, ställs allt som oftast inför oförutsedda kostnader. När så sker, och kostnaderna överskrider vad organisationen klarar av inom sitt ordinarie scoop, har avdelningen möjlighet att äska mer pengar från centrala delar av bolaget. Sådana förfrågningar kräver väl underbyggda case för att godkännas, och beroende på konjunktur och ärendets karaktär är det olika enkel att få loss medel menar avdelningschefen.

Referenser:

J.k., Pinto. (2013). Project management achieving competitive advantage (3ed Edition). London: Pearson Education Limited.



Blogginlägg 6.1

Detta inlägg spinner vidare på blogginlägg 4. I inlägg 4 går jag igenom hur kunskap sprids till nya i organisationen. Vid den tiden hade jag hunnit bekanta mig med två olika metoder som användes på avdelningen, testing (för back-end programmeraren) och dokumentations-ansvarigas bild av hur de själva via sitt jobb skapat sig en stor kunskap om produkten.

Inför detta inlägg har jag suttit ner med avdelningens chef och diskuterat kunskapsspridning. Han beskriver mer utförligt hur dokumentationsansvariga på avdelningen skapat sin kunskapsbank. De personer som ansvarar för dokumentation är inhyrda på kontrakt från ett externt konsultbolag. Deras arbetsmetodik är skapad av en senior person från samma bolag med stor erfarenhet inom dokumentation och vad jag förstår är han välkänd i branschen för sina metoder.

De första 2-3 veckorna ägnade dokumentationspersonerna enbart åt att intervjua utvecklarna, koordinatorerna, UX ansvariga, Learning ansvariga, supportavdelningens medarbetare med flera. Deras mål var att skapa sig så god produktförståelse som möjligt, innan dokumentationsarbetet påbörjades.

Denna arbetsmetod menade den seniora personen var överlägsen om dokumentationen skulle bli korrekt utförd. Avdelningschefen håller med, dokumentationsarbetet har fungerat väl. Inte nog med att de fick teoretisk förståelse av produkten, de fick också en ingående presentation av produktens hårdvara. Detta innebar att dokumenterarna hade en stabil kunskapsgrund att stå på redan innan arbetet påbörjats.

För att likrikta dokumenterarnas systembild med den faktiska skapade dokumentationsgruppen kontinuerligt kartor och teoretiska modeller om hur produkten fungerade. Dessa visades och korrigerades tillsammans med avdelningens medarbetare tills konsensus om funktionaliteten rådde. På så vis påbörjades inte dokumenteringsprocessen innan produktförståelsen var fullständig (eller tillräcklig i alla fall). Detta kostade några arbetsveckor i början av arbetet, men lär enl. avdelningschefen besparat projektet tid totalt sett.

Processer likt den ovan brukar i management sammanhang benämnas ‘onboarding‘ och går ut på att få nya medarbetare involverade i avdelningens verksamheter. För de två dokumentationsansvariga löstes detta genom intervjuerna beskrivna ovan, men ponera att du anställer 100 personer samtidigt till en större avdelning. Att låta 100 personer intervjua nyckelspelare på avdelningen skulle kräva stora tidsresurser, därför beskriver avdelningschefen ett dilemma. Å ena sidan vill du införliva nya medarbetare i verksamheten på ett effektivt vis, å andra sidan är det inte praktiskt möjligt att använda sig av den onboardingmetod beskriven ovan om många personer anställts.

För att komma runt detta har avdelningschefen använt sig av det utbildningsmaterial som skapats om produkten. Detta material är främst tänkt att användas för att träna kunder i produktens uppbyggnad och funktion, men då materialet också kan användas internt har det får fungera som onboarding-verktyg. Ett dedikerat paket för att inkludera nyförvärv i avdelningens arbete finns dock på avdelningschefens agenda. Som han ser det får du brantare lärkurva om onboarding sker med motsvarande utfall som i fallet med dokumenteringsgruppen, samtidigt som den totala produktförståelsen blir bättre.

Avdelningschefens resonemang får stöd i facklitteraturen. Att skapa en systemöversikt är viktigt för att förstå sin roll i en organisation, och hur denna är kopplad till andra funktioner (Bradt, 2009). I samma bok finns checklistor och andra verktyg du som ledare kan använda för att evaluera och exekvera en onboardingprocess. Att använda standardiserade metoder för att onboarda nyanställda gör att du inte missar viktiga events, samt att om metoden är nedtecknad, så kan du också ändra och förfina den på ett enkelt och dokumenterbart vis.

Slutligen väcks nyfikenhet hos mig då jag scrollar förbi olika approacher till onboarding. I en av böckerna står följande att läsa: “

“One notable trend Wilde is seeing is a rise in employee-owned onboarding strategies. In these approaches, employees who’ve recently joined the company play a significant role in onboarding new hires. Organizations are realizing these individuals have the greatest understanding of what new hires need, since they’ve recently gone through the process themselves”. ( Zielinski, 2019).

Om avdelningschefen ska ta fram en standardiserad omboardingprocess kan det vara klokt att göra det tillsammans med nyligen anställda medarbetare, då dessa har mycket aktuell kunskap i vilka stötestenar en träffar på som nyanställd vid bolaget. Citatet är också intressant eftersom den går i linje med den metod den seniora konsulten förespråkade gällande onboarding av dokumentationsgruppen. Dokumenterarna fick själva intervjua avdelningens medarbetare och hade därför stor kontroll gällande vilken kunskap som frågades efter. Jämför det tillvägagångssättet med att avdelningen satt samman ett kompendium som syftat till att beskriva produkten. Antagligen har den approach som används vid införlivningen av dokumenteringsgruppen inte varit tagen ur luften, utan bygger på mångåriga erfarenheter hos den seniora konsulten. Dessa bör en absolut ha i tanken när en avdelningschefen skapar avdelningens onboardingprocess.

Slutligen; Inte konstigt att dokumenterings ansvarig beskriver i blogginlägg 4 att han sannolikt har en av de mest omfattande produktförståelserna på avdelningen, han har ju intervjuat alla och studerat produkten i detalj! Jag tar med mig dessa tankar om kunskapsspridning och olika metoder för att nå sådan i mitt framtida arbete.

Referenser
George B. Bradt, Mary Vonnegut. Onboarding: How to Get Your New Employees Up to Speed in Half the Time, John Wiley & Sons © 2009
Zielinski, Dave. OPTIMIZING ONBOARDING, HR Magazine, 2019.

Blogginlägg 5.1

Detta blogginlägg kommer beröra varför projekts kostnadsestimeringar i allmänhet och mjukvaruprojekts i synnerhet tenderar att gå över budget. För att få en bred bild av varför har jag gjort en litteraturstudie samt haft ett möte med en forskare på RISE som skrivit en avhandling på temat. Resultatet från litteraturstudien och tankarna från professorn kommer bollas med personer i den organisation jag själv sitter i för att senare i blogginlägg 7 kompletteras med även deras tankar.

Flertalet studier av avslutade projekt visar att det över 50% av projekten som studerats överskridit kostnadsramarna (Magazinius, 2012). Det betyder att varannat projekt som påbörjas med stor sannolikhet kommer att spräcka fastslagen budget. Mjukvaruutveckling, alltså den bransch i vilken jag befinner mig i under denna kurs, är inget undantag. Just mjukvaruprojekt uppfattas som lätta att ändra (Magazinius 2012) och har därför en benägenhet att ändra scoope och på så vis ändras de förutsättningar på vilka kostnadsestimeringarna en gång gjordes (Maylor, 2010).

Forskaren säger tänker högt och säger: “När det gäller agilt arbete är kostnadsestimeringar inte alltid intressant”. Det hon menar är att agila arbetsmetoder per definition uppmuntrar till scoope-creep och att kostnadsestimeringar i dessa är sannolika att missa mål. Denna tanke kring kostnadsestimeringar är mycket intressant för den avdelning jag tillhör, eftersom det nu är budget-tider. Jag kommer i slutet av veckan få reda på chefens syn på saken.

Tillbaka till varför kostnadsestimeringar i utvecklingsprojekt tenderar att missa mål. Textböcker i ämnet lägger stor vikt vid estimeringsmetoderna. Om estimeringarna visar sig vara felaktiga i slutet av ett projekt bör en gå tillbaka till estimeringsprocessen och förfina denna (Pinto, 2013) (Maylor, 2010). Studier visar också att 61% av all forskning som utförs om kostnadsestimeringars inexakthet pekar mot förfining av modeller för detta (Magazinius, 2012). Det verkar alltså finnas ett synsätt som säger att finare modeller ger bättre presterande kostnadsestimeringar. Men är det så?

Forskaren problematiserar: “Någon gång övergår planering till att göra jobbet”. Du kan alltså planera väldigt detaljerat vad som innefattas i ett projekt, och sedan använda estimeringsmodeller för att prediktera projektets kostnader. Men som forskaren påpekar så blir detaljerade planeringar tillslut övergående i arbete och estimeringarnas roll blir annorlunda då mycket av projektets arbete förläggs till planeringsfasen. Många av de modeller som presenteras i Project Management- böcker baseras på planerade aktiviteter i projektet, och om dessa utförligt ska planeras så ökar kostnaden för kostnadsestimeringen.

I avhandlingen Exploring Software Cost Estimation Inaccuracy nyanseras orsakerna till kostnadsestimeringarnas dåliga träffsäkerhet genom att väva in organisationspolitiska faktorer. Med ett exempel visar forskaren på behovet av att förklara kostnadsestimeringsproblematiken med andra ingångar än modellernas ofullkomlighet. Exemplet i stora drag:

  • Tänk dig att du kastar en boll mot en hink.
  • Om du noterar var bollen hamnar i förhållande till hinken kommer bollen ibland kastats för långt, ibland för kort.
  • Korrigerar du kaströrelsen efter detta kommer du antagligen tillslut träffa hinken.
  • Om bollen däremot alltid landat framför hinken, så visar det på ett systematiskt fel och att utfallet inte är slumpmässigt.

Med detta som ingång argumenterar forskaren för att om du vill förstå varför projekt ofta spränger kostnadsramarna så måste du också se att det inte alltid finns organisatoriska incitament att faktiskt hålla kostnaderna inom projektets ramverk.

Ett målande exempel på detta finns att hämta från Mats Engwalls avsnitt The Futile Dream fir the Perfect Goal:

Både Engwall och Magazinius menar att personer i projekt har organisationspolitiska incitament som hämmar kostnadsestimeringsprocessen. Sådana incitament kan exempelvis vara personliga mål, attityder, värderingar mfl. (Magazinius, 2012). Incitament som dessa kan vara en förklaring till varför det verkar vara ett systematiskt fel i kostnadsestimeringsprocessen. Estimeringarnas objektivitet blir svår att uppnå om personen som utför estimeringen kommer sätta sina egna mål högre än projektets gemensamma.

Mange Jørgensen har också lyckats bevisa att objektiva estimeringar ofta är förklädda expertbedömningar ( Jørgensen, 2005). Med andra ord spelar det ingen roll om du förfinar modellerna, eftersom den data de fylls med många gånger är expertbedömningar är personen i fråga vägt in sina egna mål.

Så, finns det ens lösningar på denna låsning? Ja, enl. samma man, Jørgensen, så använder redan många mjukvaruutvecklande organisationer checklistor för att förekomma estimeringsproblemen ( Jørgensen, 2004). Exempelvis bör organisationen projektet ska drivas i rannsaka sig och identifiera eventuella organisationspolitiska hinder. En antagligen ganska jobbig process, för vem kommer säga: “jag underestimerar kostnaderna för mitt arbete för att få med min produkt i leveransen” utan obekväma invändningar från kollegor?

Slutligen kan en då fråga sig, varför håller vi på med projekt över huvud taget? Forskning visar ju att vi 1. med stor sannolikhet kommer skjuta över budget, 2. vi vet också om varför och 3. det är svårt att göra något åt. MEN! Som Engwall illustrerade med exemplet ovan, och som även Psykologen Daniel Kahneman beskriver i sin bok lider många människor av optimism-bias, alltså att vi är överoptimistiska gällande vår egen förmåga (Kahneman, 2011).

Kahneman beskriver vår förmåga att överskatta oss som en av anledningarna till att bloggar skrivs, småföretag startas och kök renoveras. Han beskriver det till och med som kapitalismens motor. Detta kombinerat med våra egna personliga agendor verkar få världen framåt.

Referenser
Engwall, M. (2002). The Futile Dream for the Perfect Goal. Beyond Project Management.
J.k., Pinto. (2013). Project management achieving competitive advantage (3ed Edition). London: Pearson Education Limited.
Jørgensen, M. (2004). A preliminary checklist for software cost management. Dallas, TX: IEEE.
Jørgensen, M. (2005). Industrial Use of Formal Software Cost Estimation Models. Oslo: University of Oslo.
Kahneman, D. (2011). Thinking, fast and slow. Litauen: Scanbook UAB.
Magazinius, A. (2012). Exploring Software Cost Estimation Inaccuracy. Göteborg: Department of Computer Science and Engineering, Chalmers.
Maylor, H. (2010). Project Management (4th ed.). Harlow: Financial Times Prentice Hall.

blogginlägg 4.1

Föregående vecka har gått i programmeringens och programmerarens tecken. Kod och prat om kod har värvats om vart annat. Jag har undersökt hur kunskap sprids inom utvecklingsteamet, både genom att träffa programmerare, men också genom att tillsammans med kurskamrat driva ett avgränsat programmeringsprojekt. Det har varit intressant att jämföra dels hur jag själv löser problem när jag fastnar i uppgiften, och dels hur programmerarna beskriver hur de sins emellan löser problem.

Problemlösning i agila utvecklingsteam bygger på kommunikation inom teamet (Beck, 2001). När jag som “ny” samtalar med programmerarna i teamet får jag på frågan hur de själva kom in i rollen när de var nyanställda ett snabbt svar: “jag började med testing”. Det beskrivs av en teammedlem som ett snabbt sätt att förstå mjukvaran och produkten. När du testar beskriver han vidare, så ser du stora mängder information om hur saker är tänkt att fungera samtidigt som du också får se hur det egentligen fungerar.

Ikuijro Nonaka har skapat en modell (SECI) för hur olika typer av kunskap transfereras mellan individer (Nonaka, 1994). Jag tolkar det som att fallet programmeraren besrkiver rör explicit kunskap om produkten. Explicit kunskap om produkten kommer då den nya programmeraren till gagn genom att han tillgodogör sig kunskap i en process som Nonaka benämner Combination. Kunskapen inhämtas när programmeraren utför tester på mjukvaran och läser kod. Genom combination lär sig programmeraren hur systemet fungerar.

Programmeraren beskriver också hur det i början var nyttigt att sköta testproceduren, eftersom han tyckte sig få en stor mängd kunskap serverad “gratis”. Du har som han beskriver inte full koll på produkten från dag 1, och att fråga sina kollegor var gång en undrar något blir snabbt betungande för mottagaren. Därför menade han att han kunde snappa upp stora mängder med information via de tester han utfört, information som han inte ens vetat att han kunnat fråga någon annan om.

Sådan kunskap som du bär med dig utan att veta om att du har den benämner Nonaka Tacit konowledge. Programmeraren hade alltså funnit tyst kunskap mellan raderna ( No Phun Intended ) som han tillgodogjort sig. Skulle du frågat programmeraren när han fortfarande var ny är det nog troligt att han kunnat redogöra för sådan kunskap, eftersom han i den process som Nonaka kallar för internalisering gjort sig varse om kunskapen. Däremot är det inte säkert att programmeraren som skrev koden är aktivt medveten om dessa kunskaper.

Men att skriva och att läsa kod är olika ting. Och själva kodskapandet är en process som också kan beskrivas som: från Tacit till Explicit. Programmeraren tar kunskap om hur en bör bygga ett program och skapar ett läsbart program. Men bara för att du kan läsa kod betyder det inte att du kan skriva liknande kod. Bryggan där emellan är ett exempel på tacit knowledge.

Under ett samtal med en person vars uppgift är att dokumentera avdelningens alster framkommer en annan intressant vinkel kring hur kunskaper sprids i utvecklarteamet. I och med att han arbetar med att dokumentera allt som produceras kan han likt testaren skapa sig en helhetsbild, något som han menar är svårt för de som sitter med sina respektive områden. Hans hypotes var att om du arbetar med dokumentation kan du mycket väl vara en av de som har mest koll på hur produkten / verksamheten fungerar. Om han har rätt borde även de som arbetar med utbildning ha liknande bild. Och slutligen, borde en inte var och en rotera på de tjänsterna om de ger sådan komplett förståelse?

Slutligen, När jag själv sitter med kod och försöker få den att fungera som tänkt funderar jag ibland på vad som är skillnaden mellan mig och de som jobbar med liknande uppgifter dagligen. Allt som oftast landar jag i att de både besitter oändligt många mer explicita exempel än jag, samt har det tacida smörjmedel som krävs för att den explicita kunskapen ska anpassas efter aktuell situation. Men även riktigt erfarna programmerare verkar dra nytta av andras kunskaper i teamet, det känns fint.

Referenser:
Beck, K., et al. (2001) The Agile Manifesto.
Nonaka, I. (1994).  A Dynamic Theory of Organizational Knowledge Creation. Organization Science


Blogginlägg 3.1

De kommande två blogginläggen, inlägg 3 och 4 kommer att studera hur en leder agila organisationer (3) och hur kunskaper dokumenteras och sprids i sådana organisationer (4).

För hur leder du aglia organisationer? Frågan kan anses trivial, men jag misstänker att det inte är lika samma att leda agila utvecklingsteam jämfört med traditionella stage gate-team. För att forska mer i ämnet har jag intervjuat en scrum-master samt en senior produktledare på bolaget.

Vi börjar smått. I Agile Manifesto listas de tolv principerna för det som senare skola kallas Aglie Softwere Development (Beck, 2001). Bland flera principer finns denna:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Om du som ledare ska följa denna princip, så krävs det att du också har den tillit till ditt team som krävs. Tillåt mig komplicera resonemanget och väva in tanken i en teori utvecklad Douglas McGregor. McGregor menar att det finns två poler, teori X och teori Y (Maylor, 2010):

  • X: människor behöver kontrolleras för att åstadkomma något.
  • Y: människor åstadkommer saker naturligt och behöver frihet för att nå detta.

En ledares ledarstil kan utvärderas mot denna teori. Och det är i mötet mellan mellan agila arbetsmetoder och ledaren som friktion kan uppstå. För om agila metoder ska följas bokstavstroget, så kräver det att teamet får frihet i sitt utvecklingsarbete (Beck, 2001). Det ställer i sin tur krav på ledarens ledarstil. Ty om du som ledare lutar åt teori X, och önskar kontrollera medarbetarna i utvecklingsteamet, så kommer detta per definition krocka med de agila arbetsmetoderna.

Scrum-mastern beskriver sin syn på saken: “Personligheten hos ledaren är viktigt!”. Vidare beskriver han engagerat hur ledarna på den avdelning han modererar ger sina anställda erforderlig frihet. Han poängterar att de i största möjliga mån försöker vara transparenta och skapa förståelse kring de beslut som fattas högre upp i organisationen och påverkar teamet.

Den seniora produktledaren menar att om agilt arbete ska fungera kräver det att ledaren har förtroende för medarbetarna. Han beskriver ledarens roll som koordinerande mot kundens önskemål, samtidigt som ledaren måste ha stenkoll på den teknik som utvecklas: ” Eftersom man inte har all kunskap så funkar auktoritärt ledarskap dåligt (i agila team skribentens. anm). Man måste interagera med kund och projektets tekniska experter. Vilket gör att man måste fråga och lyssna mycket men samtidigt måste man ha en övertygelse och kunna förklara varför något ska göras på ett visst sätt”

Att leda agila organisationer verkar enl. resonemanget kräva att ledaren lutar åt teori Y, och ger teamet friheter. Samtidigt menar den seniora projektledaren att ledaren också måste ha god kunskap om det teamet arbetar om och på ett konstruktivt vis kunna medla mellan beställare (intern eller extern kund) och teamet. Att teori X-ledare kräver mer kontroll behöver alltså nödvändigtvis betyda att det är den typen av ledare som HAR best koll.

Scrum mastern ställer under intervju en mycket intressant fråga: “hur kommer det sig att modeller för hur en ska arbeta är så ofullkomliga?”. Han jämför med en mekanisk datormodell av en fysisk produkt. Säg att du ska simulera något med hjälp av modellen, visst, du kanske bortser exempelvis luftmotstånd, men i övrigt har du lagt mycket effort på att få modellen verklighetstrogen.

När det där emot kommer till modeller för hur en bör leda arbete så är modellerna enl. scrummastern väldigt förenklade: “det är som att jag skulle avbilda dig (pekar på mig) som en streckgubbe”.

Och det ligger något i scrum-masterns tankar. Han har rätt i att modeller för att leda människor inte tar hänsyn till alla de faktorer som mellanmänskliga relationer bygger på. Det är såklart inte praktiskt möjligt att ta hänsyn i en generell modell som Agile till varje enskild individ i de organisationer som använder metoden. Därför ställer det stora krav på top management i dessa agilt utvecklande organisationer att rekrytera ledare som passar arbetsmetoden, likt de ledare scrum-mastern refererar till. Annars uppstår snart konflikter med teamet.

Referenser: 

Beck, K., et al. (2001) The Agile Manifesto.

Maylor, H. (2010). Project Management (4th ed.). Harlow: Financial Times Prentice Hall.

Blogginlägg 2.1

Produktskapande med agila arbetsmetoder har präglat veckan som gått, både för oss interner och de anställda på avdelningen. Vi har fatt möjligheten att skapa ett skript som kommunicerar med en server vilken har hand om en på avdelningen utvecklad produkts applikationer. När vi själva sitter i utvecklingsmiljön förvärvar vi nya kunskaper som är användbara i tekniska diskussioner med våra medarbetare.

En stor fördel med ökad teknisk kunskap är både att du blir mer kompetent inom ämnet och att du på så vis kan ställa träffsäkra intervjufrågor som berikar bloggen och borgar för intressanta svar på frågeställningen i rapporten. Bemästrande av tekniska grepp och termer är inte häller enbart en tillgång i ditt direkta arbete, utan en möjliggörare för diverse “Power Technics” som vilka kan användas för att skapa sig en stark ställning bland medarbetare och chefer (Huczynski, 2004). Än så länge upplever jag dock att utvecklarna på avdelningen inte håller sig till sådana Power Technics i någon större utsträckning. Det kan såklart bero på att när jag frågar och hjälp eller behöver svar på bloggfrågeställningar så gör jag det i egenskap av student. Studenter är som bekant studenter och inte anställda vid Bolaget, och därför är vi inte i samma liga. En annan förklaring kan vara, och den här förklaringen är tacksam att göra men nödvändigtvis inte korrekt, att avdelningens agila metoder möjliggör kunskapsspridning på ett prestigelöst vis (jämf. Organisational learning, Argyris, 1995).

Jämför jag hjälpsamheten med de tidigare icke agila avdelningar jag jobbat och haft internship vid så är folk, precis som här, i allmänhet hjälpsamma och tillmötesgående. Mitt minne är såklart inte en bra källa, och jag lider garanterat av bekräftelse-bias (Kahneman, 2011), men när du är ny på ett ställe upplever jag att personer runt om mig har stort tålamod med nybörjaren. Ett bättre grepp för att förklara hjälpsamheten hos medarbetarna är i så fall att de är utvecklare lång / längst ner i en lång hierarkisk kedja, och därför inte direkt exponerade för de företagspolitiska maktspelet. De ser till tekniken och teknikens bästa varpå de agila metoderna med face-to-face kommunikation bidrar till starkt organisatoriskt lärande (Beck, 2001) (Argyris, 1995).

Organisationer i vilka du där emot har en väl inarbetad roll tenderar enl. min erfarenhet att visa sig från andra sidor. Speciellt vid högre tjänster. Ett internship jag gjorde på en Program Managementavdelning vid en fordonstillverkare visade sig från dag 0 vara extremt relationsbaserat och influerat av det som av Dave Buchanan definieras som “organisational politics”. Redan innan jag varit där meddelade min kontaktperson att: “Du bör klä dig såhär och såhär samt att Projektledaren du kommer arbeta med uppskattar det här och det här”. Hur jag klär mig, eller att exempelvis alla negativa nyheter bör bemötas med “det fixar vi” har ju inget att göra med hur jag kommer prestera som intern. Men lik väl ansåg hon som ordnade internshipet att jag borde vara medveten om dessa symboliska värden. Vilka är klassiska Power Technics. Så jag följde hennes råd, togs väl emot och hade en intressant sommar i kostym.

Sådana yttre värden har jag som nämnt två stycken upp än så länge inte sett röken av bland mina medarbetare på avdelningen, och de förklaringar jag just nu finner närmast är: 1. Avdelningen är långt ner i en hierarki samt 2. Jag som observerar är ny i sammanhanget.

Medan vi sitter och försöker få serverkommunikationen att fungera jobbar de ordienarie utvecklarna vidare i sina respektive agila processer. Då avdelningen inte är organiserad nära bolagets kärnverksamhet utan tillhör en division för utveckling av nya produkter och tjänster (se http://www.larandeochledarskap.se/andreasniklasson/2019/11/14/blogginlagg-1-1/ ) möter avdelningens medarbetare ibland hider som uppkommit till följd av att de etablerade supportfunktionerna i bolaget inte är direkt involverade i divisionens utvecklingstempo.

Ett sådant hinder har avdelningen tampats med den senaste tiden då ett system som testas av okänd anledning gått ner. Systemet som testas är utvecklat av teamet, men bygger samtligt på beprövad teknik. Varför testsystemet slutat fungera är ännu ovisst, men både interna och externa funktioner utanför avdelningen har tillkallats för att få rätsida på problemet.

När utvecklarna och de externa supportfunktionerna möts uppstår friktion. å ena sidan arbetar utvecklarna agilt, och produkten befinner sig i utvecklingsstadiet. Å andra sidan anväds befintlig teknik i systemet, och supporten av den sköts av funktioner utanför avdelningens kontroll. Därför kommer ärendets prioritering hanteras av någon utanför divisionen, och eftersom bolaget har flera system hos kunder världen över prioriteras ett krångladende testsystem inte lika högt jämfört med system som redan är i drift och vid eventuella problem påverkar miljontals människor. Dessa prioriteringar är såklart delvis ekonomiskt betingade, men ansvariaga för det krånglande systemet uttrycker när jag möter dem frustration kring det vakum som skapas då de tvingas se sig nerprioriterade.

Jag får beskrivet för mig hur de istället för att följa supportorganisationens linjära processer för att få systemsupport fått ärendet prioriterat genom att eskalera frågan till högre instanser. Tillvägagångssättet känner jag igen från fordonstillverkaren jag arbetet vid. När de ordinarie systemen är otillräckliga och stelbenta och ett ärende är tillräckligt akut så är det inte ovanligt att frångå de etablerade arbetsmetoderna.

En förklaringsmodell kring varför supportfunktionernas processer för att få just support är kan uppfattas stelbenta kan en hämta från Hellriegel & Slocum och benämns ‘control through machinery’, alltså att processer, exempelvis IT lösningar för support, är kontrollerande verktyg (Hellriegel, 1978). Det är vanligt att i gamla stora bolag försöka kontrollera processer med byråkrati ( Mintzberg, 1979). Dessa kontrollsystem krockar dock med agila tankar som att utvecklare och business folk bör jobba ihop dagligen för att nå framgång (Beck, 2001). Om då supportfunktioner distanserat sig från utvecklarna via byråkratiska kontrollprocesser finns risk för den friktion i organisationen som beskrivs ovan.

Sammanfattande analys: Byråkratiska system möter agila internkunder som inte uppskattar väntan utan på ett agilt vis löser situationen med organisational politics, istället för att använda de av bolaget designade kontrollmekanismerna för påkallande av support. Låter det komplext? Lägg då till att jag bara är en åskådare i detta, och att det antagligen finns många fler if and bouts’ i ärendet som jag inte tagit del av.

Jag valde att se om upplägget ovan stämmer i andra agila delar av organisationen. Under en intervju med en scrum-master (funktion inom det organiserade agila arbetssättet vid bolaget) på en avdelning tillhörande en annan division än den jag tillhör framkom det motsatta. Han beskrev att när projekt krisar överges de agila metoderna och management topstyr utvecklarna. Skillnaden i detta fallet var att systemet som krånglade inte var ett testsystem, utan ett system installerat hos kund.

Scrum-mastern beskrev att utvecklarna självklart reagerade när arbetsmetoderna radikalt ändrades, men att mellancheferna på ett transparent vis förmedlade att “såhär är det och nu gör vi som vi blir tillsagda”. Det finns strider en inte vinner, och så snart som krisen är avlöst menar scrum-mastern att arbetet återgår till det normala.

Men andra ord, när en agil avdelning på bolaget stöter på problem, och problemen anses tillräckligt akuta, så frångås agila arbetsmetoder till förmån för topstyrda motsvarigheter för att lösa problemet. Och när agila avdelningar stöter på patrull, men problemen inte är tillräckligt akuta för att påverka en slutkund, så frångås standardiserade eskaleringskedjor till förmån för att nå en lösning på problemet. Det finns intressanta följdfrågor kring dessa iakttaganden, och jag plockar nog en av dem till min senare rapport: hur kontrolleras agila organisationer med traditionella styrmedel?

Tankar mottages tacksamt.

Referenser:

Beck, K., et al. (2001) The Agile Manifesto.

Hellriegel, D., & Slocum, J. W. (1978). Management: Contingency Approaches

Andrzej Huczynski (2004): Powertalk Strategies

Daniel Kahneman (2011): Tänka, snabbt och långsamt

Chris Argyris (1995): Organizational Learning II

Mintzberg, H. (1979). The Structuring of Organizations: A Synthesis of the Research.

Blogginlägg 1.1

Hej korrekturläsare, examinator och andra intresserade som läser detta blogginlägg. Denna blogg kommer kontinuerligt beskriva min tid, med start förra veckan fram till början av 2020, vid ett teknikbolag (nedan kallat bolaget) på den svenska västkusten. 

Jag kommer värva tankar och lärdomar jag skaffat vid mina tidigare studier, arbetsplatser och internships med observationer och insikter jag tillskansar mig under min tid på bolaget. Många människor i min omgivning har tagit mig och min utveckling under sina vingar vilket inneburit att jag haft förmånen att se organisationer från både ett “top down” perspektiv och ett “bottom upp” via det bekanta “golvet” (skicka ett PM om du önskar min meritförteckning).

Erfarenheter från arbete och praktik i flera organisationer har möjliggjort att jag arbetat allt från med service, produktion men främst: produktutveckling. Traditionell produktutveckling enligt vattenfallsmodellen (Maylor, 2010), vilken jag är mest bekant med, har på den division vid bolaget jag tillhör övergivits till förmån för en mer agil sådan.

 Bolaget är både ett hårdvaru- och mjukvaruföretag, men avdelningen jag tillhör är främst mjukvaruorienterad. Agila arbetsmetoder har som bekant sitt ursprung i mjukvaruutveckling (Maylor, 2010) och avdelningens utvecklare beskriver när jag talar med dem att de trivs bra med arbetsmetoden. De lyfter framförallt det kollaborativa arbetet och den kortare ledtiden från idé till test som positiva aspekter.

Vi träffade en UX designer som visade hur gränssnitt förbereds åt frontend programmerare för en av de applikationer avdelningen utvecklar. UX arbetet bedrivs kundnära och designern hade spenderat delar av sommaren med att undersöka de behov användarna har. UX arbetet bedrivs av designern användarnära och iterativt enl. Design Thinking metodologin (Brown, 2008). 

Design Thinking processen illustrerad (Brown, 2008)

Kundnära, eller snarare användarnära produktutveckling rimmar bra med agila arbetsmetoder (Nilsson, 2017). Både Design Thinking och Agila metoder är iterativa (Brown, 2008) (Nilsson, 2017) och passar därför tillsammans. Under mina två första veckor förefaller samarbetet mellan UX och programmeringsenheterna fungera väl. Designern poängterade dock att bolagsspecifika metoder kräver att hon arbetar på ett visst vis för att möta de krav som ställs i dessa processer. Därför är hennes arbetsmetod inte exakt sådan som skolexemplet i bilden ovan. Denna och motsvarande utmaningar med det agila arbetssättet vs. den traditionella bolagsstrukturen kommer jag beröra närmare i kommande blogginlägg. 

Jämför en bolagets arbetsmetoder med hur en stor fordonstillverkare i samma region utvecklat produkter fram till 2018 så skiljer sig arbetsmetoderna åt, både vad gäller produktutvecklingsmetod (Agil vs. vattenfall) men också vad gäller kundorientering.  Om en jämför den tidigare mer KPI styrda fodonstillverkarens organisation med den agila divisionen på bolaget jag nu studerar visar sig en stor skillnad vad gäller kundorientering, Customer Orientation. Kom ihåg att ägarorientering alltid sker alltid på bekostnad av kundfokus (Nilsson, 2017). Därför ska det bli intressant att de kommande veckorna få studera hur en kundorienterad och agil organisation arbetar eftersom mina tidigare erfarenheter av storbolag främst kommer från ägarorienterade och “stela” organisationer. För att förtydliga resonemanget har jag placerat in företagen i visualiseringsmodellen nedan. 

Fordonstillverkaren markerad med ljusblå cirkel med grå ring.
Divisionen i bolaget jag nu studerar markerad med mörkblå cirkel.

När organisationer i olika kvadranter möts uppstår vissa friktionsmoment, vilka är mycket intressanta att analysera ur ett ledarperspektiv. Speciellt om du inte själv är direkt införlivad i någon av de två organisationerna. Innan jag färgats för mycket av den organisation jag de kommande veckorna kommer spendera tid i hoppas jag kunna observera intressanta skeenden, både aktivt och passivt. Mer om detta i nästa blogg, håll till godo.

Referenser: 

Maylor, H. (2010). Project Management (4th ed.). Harlow: Financial Times Prentice Hall.

Nilsson, L. F. (2017). DET AGILA FÖRETAGET. Malmö: Roos Tegnér.

Brown, Tim. (2008). Design Thinking. Harvard Business Review.