Daniel Nielsen

  • First off, excellent post, and it got me thinking.

    My personal experience is that this is a cultural thing. By culture, I mean the culture of the team and company in which you are working.

    I’ve been facilitating change (and retrospective for teams) where I agree with the British facilitator you mention, ie. that retrospectives can act as a valve…[Read more]

  • Som en del af min daglige rutine, kører jeg i dag i bil ca 1 time hver vej til kontoret. Jeg er modstander af spildtid, så jeg får hørt en del podcasts. En af dem jeg nyder er Scrum Master Toolbox (SMT).
    Hvad er […]

  • Det vil være interessant at høre mere om din erfaring, og håber at jeg får mulighed for det – gerne ansigt til ansigt 🙂

    At ThoughtWorks har sat SAFe på “hold” er nyt for mig, men grundene underbygger meget min egen bekymring.

    Som Rene siger, så skal man virkelig ikke undervurdere muligheden for indflydelse på organisationen. Det er sim…[Read more]

  • Begrebet facilitator (og coach og scrum master og…) er fluffy og ikke ens opfattet – deraf de tanker jeg har gjort mig i indlægget 🙂

    Jeg forstår facilitator som det du beskriver, men også som noget mere. Fx som SAFe Scrum Master har man en opgave i at teamet skal overholde de omkringliggende SAFe regler. Det vil jeg mene gøres bedst ved øge…[Read more]

  • Jeg har slet ikke bevæget mig ind på ScrumMaster / Agile Coach som facilitator. Men det er helt sikkert også en stor del af det samlede ansvar (hvordan afhænger selvfølgelig af konteksten).

    SAFe har jeg ikke konkret erfaring med. Det skal dog ikke stoppe mig for at have en holdning 😉 Jeg er ikke som sådan bekymret, men dog lidt påpas…[Read more]

  • … og hvad vil det sige at være Scrum Master for et team? De overvejelser har jeg gjort mig en del af i den sidste tid, da jeg har fået et Scrum Master lignende ansvar for et nyt team.
    Den klassiske Scrum […]

    • Jeg har slet ikke bevæget mig ind på ScrumMaster / Agile Coach som facilitator. Men det er helt sikkert også en stor del af det samlede ansvar (hvordan afhænger selvfølgelig af konteksten).

      SAFe har jeg ikke konkret erfaring med. Det skal dog ikke stoppe mig for at have en holdning 😉 Jeg er ikke som sådan bekymret, men dog lidt påpasselig af samme årsager som dig.

      Meget enig i Shu-Ha-Ri betragtningen omkring læring; som facilitator, som ScrumMaster og ikke mindst som team! Har man fået mere blod på tanden omkring “agil modenhed” i teams og organisation er der masser af litteratur der ude. Lige for tiden er jeg fascineret af Agile Fluency ( http://agilefluency.com/ ). Det har givet anledning til reflektion omkring de organisationer og teams jeg har været i kontakt med – og min egen rolle derved.

    • Begrebet facilitator (og coach og scrum master og…) er fluffy og ikke ens opfattet – deraf de tanker jeg har gjort mig i indlægget 🙂

      Jeg forstår facilitator som det du beskriver, men også som noget mere. Fx som SAFe Scrum Master har man en opgave i at teamet skal overholde de omkringliggende SAFe regler. Det vil jeg mene gøres bedst ved øge teamets buy-in på faste rammer sat uden for teamets kontrol; det ser jeg som en faciliteringsopgave, uanset om det er til teamets bedste.

      Godt du kunne bruge linket 🙂 Jeg vil mægtigt gerne høre dine kommentarer til AF!

    • Det vil være interessant at høre mere om din erfaring, og håber at jeg får mulighed for det – gerne ansigt til ansigt 🙂

      At ThoughtWorks har sat SAFe på “hold” er nyt for mig, men grundene underbygger meget min egen bekymring.

      Som Rene siger, så skal man virkelig ikke undervurdere muligheden for indflydelse på organisationen. Det er simpelthen guld værd, og en af grundene til at jeg i sin tid valgte at gå med, da min gamle afdeling i KMD blev centraliseret – på trods af øget mødeaktivitet.

      Jeg er vældig glad på dine vegne over at du har en god oplevelse med SAFe i din organisation 🙂

      • Om min oplevelse med SAFe er god eller dårlig sådan samlet set, har jeg vist ikke vurderet endnu. Der er et par skader som SAFe-indførelsen har medført og som vi arbejder på at rette op på. Der er så også de førnævnte fordele.

        Om skaderne kommer direkte af SAFe-metoden eller vores måde at indføre SAFe på er også stadig en ting jeg debatterer med mine kolleger og mig selv jævnligt :).

        Et eksempel på noget der har haft en negativ effekt er f.eks. point normalisering på tværs af teams i estimering. SAFe siger at man laver en engangs-normalisering hvor 1 point er 1 dag og det er utroligt svært at komme væk fra den tankegang, når man først er i den. Det har rodet noget så frygteligt med vores estimeringsevner – og forskningen siger jo også at man er bedre til at estimere relativt, så at binde point til tid er en dårlig ide. Effekten har været en opstået modvilje mod at estimere overhovedet.

        Jeg tager gerne snakken ansigt-til-ansigt en dag Daniel – sig til når du er i DK :).

    • Jeg er bestemt heller ikke fan af dybe hierakier og sidder i et rigtigt dybt et. SAFe har gjort at vi har udpeget folk i flere lag som har ansvaret for at løbe med impediments og det gør det nemmere – du har nemlig helt ret i at man som Scrum Master i teamet sidder alt for langt nede i hierakiet til at kunne løbe effektivt med impediments.

      Jeg sukker udelukkende over at flere møder i min kalender nu betyder at jeg er dobbeltbooket en del af tiden… Jep, det er mange møder… som jeg gerne tager fordi vi rent faktisk ændrer tingenes tilstand.

  • ThumbnailKMD2.0 er en hypotesedrevet forandringsproces. Når vi (Business Transformation) går ind for at forandre et forretningsområde, bruger vi derfor tid på at få opsat de vigtigste hypoteser for området. Men hvordan […]

    • Jeg har ad flere omgange brugt Value-Stream-Mapping til at genere hypoteser ud fra. Det har mange værdiskabende elementer. En klar fordel er at alle interessenter får et fuldt overblik over en given process og der er i fællesskab bliver defineret hypoteser/problemer/flaskehalse med mere.

      Det giver i min optik en mere styret og struktureret tilgang til generering af udsagn som senere kan bearbejdes ned i hypoteser der kan måles og afprøves.

      En ulempe ved at lave en “rå” brainstorm seance er at delagerne i visse situationer får gravet sig ned i et hjørne der efterfølgende kan vise sig at være et lokalt minimum i stedet for et globalt.

  • ThumbnailSom nogen måske husker, startede jeg denne blog i forbindelse med et nyt initiativ i KMD kaldet Agile Excellence. I forbindelse med Agile Conference @ Danske Bank holdt jeg et oplæg om agil udvikling i KMD. Titlen […]

  • Glimrende og pragmatisk overblik 🙂

    Min erfaring siger mig at så snart produktet når en hvis kompleksitet (overraskende lav, i hvert fald for mig) så er det ikke nok med en PO. Der skal selvfølgeligt være en og kun en med ansvaret, men vedkommende har brug for alt det hjæp der kan skaffes til ting som kunde & bruger involvering, speci…[Read more]

  • Hej Tore.
    Spændende at I prøver SAFe. Jeg har ikke selv prøvet den fulde SAFe pakke, så jeg er interesseret i at høre hvordan det går for jer. Men det første jeg tænker når jeg læser om SAFe er Troels Richter & Aino Vonge – Don’t kill Agility with Agile processes (https://www.youtube.com/watch?v=9ZXLqHSbePw). Dermed ikke sagt at der ikke er g…[Read more]

  • ThumbnailNår vi har besøgt forskellige dele af KMD, har vi bemærket forskellige syn på kravstyringen i forhold til produkterne. Nogen har en god opsamling af:

    Kundeønsker
    Fejl fundet i driften
    Andre interessenters […]

    • Hej Tore.
      Spændende at I prøver SAFe. Jeg har ikke selv prøvet den fulde SAFe pakke, så jeg er interesseret i at høre hvordan det går for jer. Men det første jeg tænker når jeg læser om SAFe er Troels Richter & Aino Vonge – Don’t kill Agility with Agile processes (https://www.youtube.com/watch?v=9ZXLqHSbePw). Dermed ikke sagt at der ikke er gode ideer i SAFe, så umiddelbart vil jeg nok vælge de dele der giver mening for et eksisterende setup og så se stort på resten.

      Jeg har god erfaring med Story Maps (kender ikke til noget godt digitalt værktøj, ud over mind mapping værktøjer 🙂 ) hvor man netop kan inddele themes i mindre themes, epics i mindre epics indtil man er helt nede på User Story niveau. Med lidt disciplin og en stor væg med masser at post-its og “elefant-snot” kan man få et ganske glimrende overblik.

  • Jeg er flere gange blevet mødt med spørgsmålet: “I det der agil udvikling, hvornår designer man så datamodellen?” Spørgeren kan tænkes at være en lettere forvirret løsningsarkitekt med en vandfaldsbaggrund. Derfor […]

  • Det er vildt spændende 🙂

    Grundlaget for udviklingsprocessen bliver lagt centralt, men alt er principielt set i spil når man vurderer tilpasninger. I vores setup er det den enkelte ScrumMasters ansvar at trække relevante pointer ud fra retrospectives og bringe det videre. I praksis er det sket at mindre tilpasninger fx til definition of do…[Read more]

  • Når et projekt er i den indledende opstart og man som område prøver at sætte rammerne for det fremtidige samarbejde er der mange overvejelser der skal gøres. Business case og andet bruges som input til en grov release planlægning og dermed også som input til backlog. Personale fra både forretning og udvikling skal allokeres og roller og ansvar skal placeres. Brugen af near-shore / outsourcing skal afklares og processerne omkring forretning, udvikling og kommunikation mellem alle parter skal overvejes. Alt dette er komplekst nok uden forstyrrelser, men i en omskiftelig verden med skiftende prioriteter kan forstyrrelser udefra ikke undgås. Jeg har besøgt et projekt i opstartsfasen hvor de indledende tanker og milestone planer var lagt.
    Første omgang

    Første udkast til projekt struktur

    Ser man på bemandingen var der lagt op en struktur som illustreret (fraregnet ledelse). Da jeg møder projektet er near-shore ikke tilknyttet endnu. De har identificeret analytikere, Lead Developer og nogle af arkitekterne. Ledelsen i projektet er kraftigt inspireret af en tidligere succes historie med Scrum i KMD (hvor jeg agerede ScrumMaster 🙂 ) og ligger op til at følge den samme model. Der er god åbenhed og samarbejdsvilje fra alle tilknyttet projektet – også ledelse. Der er enkelte personer i projektet med Scrum erfaring, men det generelle erfaringsniveau ligger på “har hørt om Scrum”. Projektets deltagere har tænkt mange tanker om hvordan udviklingen skal foregå. Noget kommer fra rygter internt i KMD, fra hvad man har fundet på nettet og man har sammenholdt dette med den måde man plejer at arbejde på. I grove træk er planen det at teamet af analytikere (de grønne) gør alt det en Product Owner skal. Indsamle krav, lave prototyper, skrive userstories, prioritere backloggen og meget andet. Lead Developer og Architects står sammen om de tekniske aspekter. De skal stå for at tegne den overordnede arkitektur som illustreres gennem en reference applikation. Review og estimering i story points af backlog items så de er klar til implementering. Ligeledes står de får kvalitetssikringen af kode leveret fra near-shore teams. Ikke urimelige tanker og heldigvis er jeg i stand til at rette de værste misforståelser ind, men det er svært at gå i detaljer omkring en udviklingsproces når der ikke er tilknyttet et Scrum team som man kan sparre med. Det bliver til snak og diskussioner. Der er nu ca 3 uger til det første near-shore team skal starte.
    Anden omgang
    Backloggen eksisterer, men indeholder kun kæmpe-epics. Jeg fokuserer på at hjælpe analytikere og Product Owner med at opbygge en god backlog med ”små” User Stories i toppen og de større længere nede. Lead Developer og Architects har rigeligt at se til og bliver flittigt brugt som sparringspartnere til backloggen. I fællesskab bliver vi enige om at hvert Scrum team har deres egen backlog og at disse backlogs fyldes fra en central backlog der giver overblik over alle PBI’er uanset hvilket team de er tilnyttet. Som elektronisk backlog værktøj vælger vi Team Foundation Server 2012, som har glimrende understøttelse for denne struktur. Da der er flere teams tilknyttet projektet, vælger vi at indføre en begrænsning. Alle teams skal have fælles Definition of Ready og Definition of Done. Ændringer til disse kan ikke vedtages af det enkelte team, men skal vedtages på tværs af alle teams. Der er nu ca 2 uger til det første near-shore team skal starte.
    Tredje omgang

    Andet udkast til projekt struktur

    Det bliver pludseligt meldt ud at der ikke er noget near-shore team der kan starte alligevel. Et andet projekt i KMD er i krise og skal bruge alle de hænder de kan stampe op af jorden. Det har store konsekvenser for releaseplaner og for moralen på projektet. Mit mål bliver at få gjort op med den foreslåede projekt struktur og derved at få praktisk erfaring med Scrum ind på projektet alligevel. Gode og konstruktive diskussioner mellem alle gør at vi får udfordret hvilke opgaver der skal løftes af de enkelte roller. Vi vedtager i fællesskab en projekt struktur som illustreret. Stemningen er væsentligt forbedret og forventningerne høje. Vi får etableret et Scrum team i Danmark og de opgaver der før gik uden om backlog ender nu i backloggen, prioriteret og styret af Product Owner. En certificeret ScrumMaster findes blandt analytikerne og tager villigt opgaven. Der er nu ca 2 måneder til det første near-shore team skal starte, men implementationen er begyndt og alle i projektet får erfaring med deres roller og Scrum processen.
    Fjerde omgang
    Vi har nu bevæget os hen over sommerferien og sådan en periode er fuld af overraskelser. Roller er åbenbart slet ikke så faste som først antaget. Den eksisterende ScrumMaster bliver Product Owner og den eksisterende Product Owner skifter til fuldtids-analytiker En deltids-allokeret person bliver fuldtids-allokeret til projektet og får i al hast en ScrumMaster uddannelse for at varetage ScrumMaster rollen. Nogle af analytikerne skifter afdeling. At min tid med projektet som første prioritet stort set er slut, gør ikke situationen nemmere. Heldigvis er alle ved godt mod og god sparring med de nye rolle-ejere gør at alt er klart til at near-shore teamet starter. Der er nu under 2 uger til det første near-shore team skal starte.
    Femte omgang
    Bemandingen virker stabil, udviklingen viser fremdrift og der forbedres iterativt på processen. Min rolle er nu at agere sparringspartner og måske kigge forbi og facilitere et retrospective. Jeg ser frem til at følge med i projektet. Near-shore teamet har kørt 2 sprints synkront med teamet i Danmark. (Detaljerne i et setup med flere teams, heraf nogle near-shore må vente til et andet indlæg)

    • Lyder spændene – glæder mig til at høre mere 🙂

      Det lyder som om at I styrer mange ting uden for eller centralt i teamsene – har du tænkt på om der mistes nogle af de fordele selvkørende teams kan give? Fx. kunne retrospectives give input til definition of done der ikke er relevante for andre teams?

      • Det er vildt spændende 🙂

        Grundlaget for udviklingsprocessen bliver lagt centralt, men alt er principielt set i spil når man vurderer tilpasninger. I vores setup er det den enkelte ScrumMasters ansvar at trække relevante pointer ud fra retrospectives og bringe det videre. I praksis er det sket at mindre tilpasninger fx til definition of done er implementeret ude i de enkelte teams og først senere er taget op i de andre teams.

  • Enig, vi er meget spændte på udfaldet 🙂

    Jeg var en del af det stagnerede commynity. Den primære funktion var et diskussions forum, så man kunne blive notificeret hvis der blev delt et link. Da jeg fandt siden, var det allerede stagneret så jeg er usikker på om der nogensinde har været andet. De snakke vi har haft ude i forretningen viser…[Read more]

  • I regi af Agile Excellence har vi introduceret en del teams for den agile verden og der findes flere områder i KMD, der kører agilt uden vores hjælp. Vi vil gerne sikre et forum for alle med interesse i agil udvikling, så de har et sted at udveksle deres erfaringer, specielt ScrumMastere og Product Owners.

    KMD har netop relanceret vores intranet på en SharePoint 2013 portal med en nogenlunde fornuftig håndtering af Communities. Vi har overtaget et stagneret agilt community (Skulle du, kære læser, sidde på en KMD PC på KMDs net, kan community’et tilgås her). Planen er at vi vil opbygge stedet for agil udvikling i KMD.

    Jeg forestiller mig, at vi dækker følgende områder:

    Praktisk information; såsom hvordan man bestiller nye Post-Its, magneter, tuscher, Poker Planning kort og alt andet der skal bruges til et Scrum kit.
    En anbefalet litteraturliste.
    Diskussions forum, hvor vi i Agile Excellence bestræber os på at være aktive.
    Kalender med meetups.

    Som udgangspunkt vil vi planlægge en tilbagevendende session af to–tre timers varighed. KMD har til huse flere steder i landet, så vi bør overveje om vi skal afholde et meetup på alle lokationer, eller afholde det hvor der er flest deltagere og så invitere dem der ikke tager rejsen til at deltage via videokonference. KMD bruger Lync i hele organisationen og alt andet lige, fungerer det udmærket. Faren ved at afholde disse på alle lokationer og holde dem offline er tilslutningen til meetup’et. Et meetup med to personer (inkl. facilitator) er ikke et meetup.

    Vi har endnu ikke bestemt os for formen på meetups, men jeg har tænkt over flere muligheder.
    ERFA
    En session hvor dagsordenen er kendt på forhånd. Sidste punkt på dagsordenen vil så være at fastlægge dagsordenen for næste møde. Formålet vil være at give deltagerne rum til at fremlægge de tiltag eller problemstillinger de har ude i de enkelte teams. Præsentationer er velegnet til videokonference, så denne form kan godt lade sig gøre.
    LEAN COFFEE
    Der er skrevet meget om Lean Coffee tilgangen og det er en klar mulighed for vores meetups. Her er den fysiske tilstedeværelse til meetup’et vigtig. Den frie diskussionsform om dagsordenen er ikke specielt velegnet til videokonferencer.
    SOCIAL
    Her kan man fx mødes til frokost ude i byen en fredag og diskutere frit. Herefter kunne man tage en øl / sodavand på en bar / pub og stadigt ville diskussionen være fri. Erfaringviser at sociale arrangementer nedbryder barrierer og efterfølgende vil det være nemmere at tage kontakt til de andre medlemmer af communitiet hvis man har spørgsmål. Denne form fungerer helt sikkert ikke via videokonference!

    Formen behøver ikke være den samme mellem hvert meetup. Lige nu er jeg tilhænger af ERFA formen med videokonference, krydret med sociale arrangementer for de enkelte lokationer. Det mener jeg virker som et fornuftigt kompromis.

    Men hvad kan man ellers gøre? I Agile Excellence har vi ikke stor erfaring med håndtering af communities, så vi er åbne for forslag.

    • Superinteressant udfordring.

      Min umiddelbare tilgang til det ville være at tage nogle snakke med folk i det stagnerede agile community og høre hvad de gerne vil have ud af et community og hvorfor det nuværende community er stagneret. Man skal jo ikke have et community for communitiet skyld, men for medlemmernes skyld. Hvis man finder ud af at folk ikke er interesseret i et community kan det være at en vedligeholdt FAQ var mere passende.

      Når det så er sagt, så håber jeg der er interesse for et community. Så kunne I f.eks. overveje om det skal være indenfor murene. Ville jeres folk have gavn af at I åbnede (nogle) sessioner for offentligheden, så der kom ny viden ind?

      Min erfaring med communities er at de har let ved at dø, hvis ikke der er ildsjæle involveret, men også ildsjæle kan dø ud. Hvad kan I gøre for at holde gang i ildsjælene – kan I påskønne dem på en eller anden måde (ofte er et klap på skulderen nok, men det kan også være mere konkret)? Har I en overordnet community manager (altså en der ved noget om communities og hvordan man får mest ud af dem)?

      Jeg ville nok afprøve alle de tre meetup-former og så se hvilken feedback I får på formen.

      • Enig, vi er meget spændte på udfaldet 🙂

        Jeg var en del af det stagnerede commynity. Den primære funktion var et diskussions forum, så man kunne blive notificeret hvis der blev delt et link. Da jeg fandt siden, var det allerede stagneret så jeg er usikker på om der nogensinde har været andet. De snakke vi har haft ude i forretningen viser at der er en interesse for noget mere end et forum, altså vidensdeling og sparring.
        Vi starter nok med noget ERFA + Social for at se om vi kan få bare en smule opbakning. Om det ender med en vedligeholdt FAQ + forum eller bliver til mere, det finder vi så ud af efterhånden.

        Det med eksterne oplæg / offentlige sessioner er en rigtig god ide. Jeg har været så fokuseret på et KMD-vendt arrangement, men der er intet der forhindrer os i at åbne det op. Evt kan vi invitere passionerede folk ude fra til at holde oplæg eller lave workshops.

        Vi starter med at det er ildsjælene i Agile Excellence der bidrager til community’et, og så vil vi gerne at det udvikler sig derfra 🙂 Jeg er faktisk usikker på om vi har en Community Manager eller tilsvarende rolle i KMD, men det er vi ved at undersøge.

    • Jeg har selv startet et agilt community op på min arbejdsplads. Det kræver en masse benarbejde for at få folk til at være aktive – specielt over flere geografiske lokationer.

      I det setup jeg er landet på kører vi en række forskellige event-typer alt efter hvilken type kommunikation vi vil tilvejebringe.

      Netmøder/Screencast/E-møder: Hvis vi primært har envejs kommunikation. Det kan være i forbindelse med introduktion af nye metoder, værktøjer eller lignende.

      Centrale møder: Vi afholder periodisk større møder der på mange måder minder om konferencer. Her beder vi både interne og eksterne agilister om at præsentere et emne som publikum senere kan debatere.

      Decentrale møder: På hver location laver vi små events, i visse tilfælde som lean coffee.

      Alle har hver sit fokus og værdi. Det er vigtigt at definere formål for at få success.

  • Jeg er usikker på hvad du spørger om?

    De surveys jeg her snakker om er beregnet på – forhåbentligt – at fange medarbejdernes mavefornemmelser for om den agile process har forbedret noget. De resultater vi får ind sammenholder vi med hvad vi ser og hører på retrospective.

    Vi har først lige indført denne survey og har endnu ikke haft anden ru…[Read more]

  • Ideen om et bat-signal er plantet lidt i de enkelte ScrumMastere. De har altid lov til at hive fat i os og få os ud i området for feedback, sparring eller hvad de nu har brug for. Det betyder så også at de ScrumMastere der buldrer mest, får mest opmærksomhed. Det kunne nemt tænkes at et område havde mere brug for os, men at deres ScrumMa…[Read more]

  • Jeg burde nok have nævnt at vi skam også har løbende sparring med både Product Owner og Scrum Master 🙂 Vi stoler ikke blindt på spørgeskema undersøgelser, men har dem med som input.

    Vi har valgt også at bruge et anonymt mavefornemmelses spørgeskema for forhåbentligt at undgå for meget Hawthorne effekt. Til de første retrospectives for et team…[Read more]

  • ThumbnailHvordan kan vi sikre os, at vi ikke bare forplumrer og forværrer tingene i de enkelte områder? Hvordan definerer vi om et besøg fra Agile Excellence i et område har været en succes?

    For mig personligt er det […]

    • Jeg synes det er interessant at I stiller de 4 spørgsmål med 10 ugers mellemrum. Hvad er jeres overvejelser om ikke at spørge oftere? Kunne man forestille sig at alle teams svarede hvert sprint og at I dermed fik et heatmap over hvor der er mest brug for jer? En slags bat-signal ;).

      • Ideen om et bat-signal er plantet lidt i de enkelte ScrumMastere. De har altid lov til at hive fat i os og få os ud i området for feedback, sparring eller hvad de nu har brug for. Det betyder så også at de ScrumMastere der buldrer mest, får mest opmærksomhed. Det kunne nemt tænkes at et område havde mere brug for os, men at deres ScrumMaster ikke buldrer nok. For at afhjælpe har vi løbende opfølgning på områderne.

        Et semi – automatisk bat signal kunne være en fordel, men implementationen skal vi nok passe på. Det skulle være hurtigt og nemt at opsamle data. Vi prædiker allerede at der bliver lavet et referat af alle ceremonierne for alle sprints. Måske det kunne bruges, hvis vi fik ScrumMasterne til at sende det til os… Det vil jeg overveje at få med!

    • Eeek.

      Jeg har super lidt tiltro til den slags målinger. Det kan være det blot er mig der er skeptisk/pessimistisk.

      Personligt har jeg haft større held med at lave periodiske “opfølgningssamtaler” med f.eks. Scrum Master, Product Owner og leder for at få en “team status” og evt. sætte nye agile tiltag i søen. De punkter der er listet i surveyen vil typisk også indgå, naturligt, i de punkter som bliver bragt op til diskussion af teamet på retrospectives.

      Du skriver også at det er vigtigt at det er en “erfaren” Scrum Master der tages i ed. Det er naturligvis et ønskeligt scenarie, men jeg finder det mere vigtigt at personen har de rigtige karakteristika – empati, ejerskab, drive og engagement.

      • Jeg burde nok have nævnt at vi skam også har løbende sparring med både Product Owner og Scrum Master 🙂 Vi stoler ikke blindt på spørgeskema undersøgelser, men har dem med som input.

        Vi har valgt også at bruge et anonymt mavefornemmelses spørgeskema for forhåbentligt at undgå for meget Hawthorne effekt. Til de første retrospectives for et team har vi flere gange oplevet at team members ikke er helt åbne omkring deres oplevelser. Det er både til den negative og positive side. Du har helt ret i, at går alt som det skal, bliver spørgsmålene naturligt diskuteret til retrospective.

        Når jeg skriver erfaren ScrumMaster “med et vist drive” er det med det håb at personen så netop har de karakteristika der skal til. Og kan man ikke få begge dele, foretrækker jeg klart en med de rigtige karakteristika frem for erfaring. Men hvordan valget af personer til de forskellige roller foregår er forskelligt fra område til område og kan fylde blog-posts i sig selv.

        • Et umiddelbart spørgsmål fra min side vil så være: Stemmer survey resultaterne overens med mavefornemmelserne og evt. de emner der diskuteres på retrospective meetings?

          • Jeg er usikker på hvad du spørger om?

            De surveys jeg her snakker om er beregnet på – forhåbentligt – at fange medarbejdernes mavefornemmelser for om den agile process har forbedret noget. De resultater vi får ind sammenholder vi med hvad vi ser og hører på retrospective.

            Vi har først lige indført denne survey og har endnu ikke haft anden runde ude i områderne. Så vi kan ikke sige om der er overensstemmelse mellem survey resultater og retrospective – men vi håber det 🙂

  • Load More