{"id":984,"date":"2021-01-19T08:07:30","date_gmt":"2021-01-19T07:07:30","guid":{"rendered":"https:\/\/agilerasmus.com\/wordpress\/?p=984"},"modified":"2021-01-19T08:07:31","modified_gmt":"2021-01-19T07:07:31","slug":"sikkerhedsbriller-og-safe","status":"publish","type":"post","link":"https:\/\/agilerasmus.com\/wordpress\/sikkerhedsbriller-og-safe\/","title":{"rendered":"Sikkerhedsbriller og SAFe"},"content":{"rendered":"\n

Mange eksperter har tidligere udtrykt deres holdning til de store anerkendte rammev\u00e6rk for skalering. Her beskriver de nogle af de udfordringer, der opleves i markedet med skalering ved hj\u00e6lp af skaleringsrammev\u00e6rk. Ved en simpel s\u00f8gning p\u00e5 jobindex ser man en stigning i antallet af jobopslag med agile roller, f.eks. Scrum Master og Product Owner, men ogs\u00e5 de mere diskutable roller som Release Train Engineer, SAFe Program Consultant og Product Manager. Det understreger vigtigheden af at forst\u00e5 mekanismerne bag rammev\u00e6rkene men ogs\u00e5 konsekvenserne ved at indf\u00f8re dem. Ligesom med fyrv\u00e6rkeri s\u00e5 kan resultatet v\u00e6re festligt og farverigt, men uden sikkerhedsbriller og fornuftig h\u00e5ndtering kan man hurtigt komme galt afsted.<\/p>\n\n\n\n

Luxshan Ratnaravi, Agile Coach hos Bankdata, har lavet en liste af sp\u00f8rgsm\u00e5l man kan besvare, for at finde ud af om skalering er korrekt, og om man skal anvende et pr\u00e6defineret rammev\u00e6rk. Oversat til dansk er sp\u00f8rgsm\u00e5lene:<\/p>\n\n\n\n

  1. Hvilke udfordringer kan vi ikke l\u00f8se uden at skalere?<\/li>
  2. Hvad vil vi opn\u00e5 ved at skalere?<\/li>
  3. Kan eksisterende rammev\u00e6rk hj\u00e6lpe os \u2013 eller skal vi udv\u00e6lge enkelte praktikker for at komme videre?<\/li>
  4. Hvilke indikatorer kan vi m\u00e5le p\u00e5, for at se om vi g\u00e5r i den rigtige retning?<\/li>
  5. Er teamene modne nok til at starte p\u00e5 en skalering?<\/li>
  6. Har vi fors\u00f8gt at reducere afh\u00e6ngigheder?<\/li>
  7. Organiserer vi os efter v\u00e6rdistr\u00f8mme?<\/li>
  8. Er det muligt at skabe et m\u00e5l og en vision p\u00e5 tv\u00e6rs af de teams, der skal skalere sammen?<\/li>
  9. Bliver teamene bedre sammen end hver for sig?<\/li>
  10. Skal teamene arbejde som feature-teams?<\/li>
  11. Er interessenterne enige i at investeringen i skalering er mindre end fordelene?<\/li>
  12. Prioriterer vi p\u00e5 tv\u00e6rs af teams, produkter og kompetencer?<\/li><\/ol>\n\n\n\n

    Den type sp\u00f8rgsm\u00e5l er super relevante, og b\u00f8r indg\u00e5 i enhver beslutning om skalering. I till\u00e6g s\u00e5 er det min opfattelse, at skalering er en midlertidig h\u00e5ndtering af en f\u00e6lles udfordring. Og hvad betyder det s\u00e5? Det betyder at en introduktion af f.eks. SAFe b\u00f8r ses som en m\u00e5de at l\u00f8se de midlertidige udfordringer der identificeres med de 12 sp\u00f8rgsm\u00e5l. Over tid b\u00f8r organisationen arbejde p\u00e5 at reducere behovet for tv\u00e6rg\u00e5ende m\u00e5l og visioner med et slutm\u00e5l om at kunne arbejde som selvst\u00e6ndige teams, der kan finde ud af at tale sammen retidigt med resten af organisationen.<\/p>\n\n\n\n

    Uanset hvilket rammev\u00e6rk \u2013 eller intet rammev\u00e6rk \u2013 der v\u00e6lges, er det vigtigt, at forst\u00e5 de bagvedliggende mekanismer. Det kr\u00e6ver b\u00e5de stor erfaring i metoderne, kendskab til organisationen samt evne til at implementere og facilitere. Det opn\u00e5es typisk ved en kombination af eksterne eksperter sammen med interne medarbejdere og ledere. Der findes intet, der kan implementers udelukkende af eksterne, med et h\u00e5b om at organisationen efterf\u00f8lgende kan l\u00f8be videre med opgaven. Det kr\u00e6ver en forandring af organisation, medarbejdere, arbejdsform og leverancemodel.<\/p>\n\n\n\n

    Det mest udbredte rammev\u00e6rk for tiden er SAFe, som tilbyder noget s\u00e5 farligt, som en drejebog for, hvordan en organisation kan omstille sig fra traditionelle plandrevne metoder til noget, der minder om iterativ og inkrementiel udvikling. SAFe kalder det for \u201cSAFe Implementation Roadmap\u201d. Det farlige i drejebogen og egentlig i hele rammev\u00e6rket ses flere steder:<\/p>\n\n\n\n