{"id":116,"date":"2014-02-10T07:00:20","date_gmt":"2014-02-10T06:00:20","guid":{"rendered":"http:\/\/qed.dk\/rasmus-kaae\/?p=52"},"modified":"2016-12-19T07:10:12","modified_gmt":"2016-12-19T07:10:12","slug":"breaking-agile-retrospective-meetings-2","status":"publish","type":"post","link":"https:\/\/agilerasmus.com\/wordpress\/breaking-agile-retrospective-meetings-2\/","title":{"rendered":"Breaking agile – Retrospective meetings"},"content":{"rendered":"

I dette indl\u00e6g vil jeg guide dig til nedbrydning af den agile tanke om retrospective meetings.<\/p>\n

\"bomb-154456_640\"<\/a>I mit daglige virke som agile coach har jeg observeret en r\u00e6kke guldkorn der alle bidrager til nedbrydning af den agile tankegang. F\u00f8lg med i de kommende indl\u00e6g og f\u00e5 flere hints til hvordan DU saboterer med st\u00f8rst mulig virkning!<\/p>\n

    \n
  1. Det er vigtigt at det er samme person hver gang som faciliterer m\u00f8det. P\u00e5 den m\u00e5de opretholdes samme struktur og kommunikationsform gennem hele forl\u00f8bet.<\/li>\n
  2. Facilitatoren skal helst v\u00e6re en person fra teamet og allerhelst projektleder eller scrum master. Det vil sikre at teamets vigtigste problemer bliver belyst og ingen begivenheder i det forgangne sprint bliver glemt!<\/li>\n
  3. Brug samme metode hver gang. P\u00e5 den m\u00e5de ved alle deltagere hvad de g\u00e5r ind til og man sikrer at f\u00e5 et ensartet output fra alle retrospective meetings.<\/li>\n
  4. S\u00e6t h\u00f8jest 30-60 minutter af til m\u00f8det og g\u00f8r det gerne kort. Hvis folk har forberedt input ordentligt inden m\u00f8det kan det afvikles hurtigt og effektivt uden den store diskussion. Tit vil problemstillingerne alligevel v\u00e6re de samme fra gang til gang – s\u00e5 hvorfor bruge mere tid p\u00e5 det?<\/li>\n
  5. Lad v\u00e6re med at udpege ansvarlige for besluttede handlinger. Det er vigtigt at hele teamet tager ansvar for de ting der skal \u00e6ndres i fremtiden. Hvis der udpeges en enkelt fra teamet risikerer man blot at det l\u00f8ses for hurtigt.<\/li>\n
  6. Hvis teamet er distribueret er det vigtigt at afholde separate m\u00f8der for hver lokation. At holde m\u00f8det via webcam eller andre tekniske vidundere er besv\u00e6rligt – desuden ved alle team medlemmer godt hvem der i virkeligheden udg\u00f8rer det store problem!<\/li>\n
  7. Hold m\u00f8det formelt og struktureret. Efterlev gerne mottoet “Form over indhold”. Hvis m\u00f8det afvikles med h\u00e5rde m\u00f8deledelse og en overdrevet struktur sikres et effektivt m\u00f8de hvor alle punkter bliver behandlet og f\u00f8rt til referat.<\/li>\n
  8. Kig aldrig p\u00e5 historiske fakta. Der er ingen grund til at vise teamet en burn down graf og diskutere de vigtigste begivenheder der har v\u00e6ret i det forgangne sprint. Teamet kender allerede til forl\u00f8bet og ved at grafer KUN er et n\u00f8dvendigt onde udt\u00e6nkte af ledelsen.<\/li>\n
  9. Facilitatoren skal gerne have forberedt en r\u00e6kke forbedringspunkter inden m\u00f8det. Det er vigtigt at facilitatoren har forberedt en hemlig agenda med hvilke \u00e6ndringer der skal indf\u00f8res i teamet. Undervejs i m\u00f8det kan facilitatoren nemt guide teamet hen mod de rigtige beslutninger!<\/li>\n
  10. Det er ikke vigtigt at alle er med – og ej heller at alle kommer med input. Hvis folk ikke har lyst til at dele deres erfaringer med resten af teamet – s\u00e5 skal de heller ikke tvinges. Det er besv\u00e6rligt og f\u00f8rer til un\u00f8dvendige konfrontationer i teamet. S\u00f8rg for at de v\u00e6rste problemskabere bliver holdt ude.<\/li>\n<\/ol>\n

    Jeg h\u00e5ber virkelig at disse observationer vil blive taget i mod med kysh\u00e5nd. Skriv gerne en kommentar hvis du har forslag til yderligere punkter eller har erfaring med implementering af ovenst\u00e5ende. God vind!<\/p>\n

    Se de \u00f8vrige indl\u00e6g i serien:<\/p>\n