Agil udvikling i KMD. Kan man overhovedet det?

Min interesse indenfor softwareudvikling har altid været bred. Det er et spændende felt! Hvad fik man valgt til og ikke mindst fra? Kan brugerne hitte ud af systemet? Hvordan sikrer vi at løsningen yder tilfredsstillende med 10.000 samtidige brugere? Men på det seneste har jeg fundet delen omkring samarbejde mellem udvikling og forretning og udviklingsprocessen mere interessant end ellers.

Efter en større organisatorisk omrystning havnede mit daværende projekt i den gren af KMD der har det mundrette navn ”Borgernære softwareløsninger & Application Management” (BNS&AM). Her har ledelsen fastsat et øget fokus på samarbejdet mellem udvikling og forretning og på udviklingsprocessen. Derfor blev gruppen Agile Excellence dannet og da jeg fik muligheden, sprang jeg på.

Hvad er så planen med Agile Excellence? Tanken er at vi skal højne det agile niveau i hele forretningen under BNS&AM, et forretningsområde af gangen. Processen skal være genkendelig for alle typer medarbejdere på tværs af områderne. Det har resulteret i at vi har valgt Scrum som primær tilgang og har en række anbefalinger til hvordan man i praksis gør. Der er også et krav eller to der skal overholdes – men detaljerne må vente til et andet indlæg.

Vores tilgangsvinkel er rimeligt klar; opbyg en backlog af forretningsområder og deres teams. Start fra toppen. Men hvordan prioriteres et team kontra et andet? Vi har ikke noget endegyldigt svar, men har valgt at prioritere frivillighed, timing og plads til forbedring. Det har affødt en grov inddeling som fås ved at stille følgende spørgsmål:

  1. Ønsker I selv at vi kommer på besøg?
  2. Er I i en opstarts fase?
  3. Er der langt fra den nuværende udviklingsprocess til en agil tilgang?

Vi har ledelsesmandat til at besøge alle områder, men det er åbenlyst bedst at besøge steder der gerne vil have os. Så er planen at de gode erfaringer gør at flere melder sig frivilligt.

Vi vurderer at det er nemmere at påvirke et projekt i et område under opstart frem for et allerede etableret. Dermed ikke sagt at de etablerede slipper, men de ryger længere ned i backloggen. Pladsen til forbedring har vi valgt at afklare i forhold til hvor agil en tilgang der allerede er på plads. De områder der allerede kører agilt har naturligt mindre brug for os. Backloggen er, som en god backlog er, et dynamisk dokument og områder springer til og fra løbende.

Men hvordan ville du, kære læser, gøre? Giver et projekt som dette overhovedet mening?

Share Button
The following two tabs change content below.
Profile photo of Daniel Nielsen

Daniel Nielsen

Agile Coach af Teletronics.ae
Daniel har en sund interesse for software udvikling og alt hvad der hører til. Han arbejder primært som Agile Coach // Scrum Master. Interessen for udviklingsprocesser og samarbejde mellem mennesker har været tilstede fra første job og er ikke blevet mindre de seneste 10 år.
Profile photo of Daniel Nielsen

Nyeste indlæg af Daniel Nielsen (se alle)

7 kommentarer for “Agil udvikling i KMD. Kan man overhovedet det?

  1. Anne Mette Bragh Frederiksen
    22. maj 2014 at 13:32

    Kære Daniel. Spændende indlæg og spændende opgave du/I står overfor. Der kan jo være mange tilgange til en øget professionalisering, som den du beskriver. Det forekommer mig at man hos Jer initielt har valgt frivillighedens vej og efterfølgende forventer, gradvist som de positive erfaringer med Jeres besøg spreder sig som ringe i vandet, at ønsket om at blive inddraget vil vokse i alle grupper og projektet går fra at være et specielt initiativ til at være dagligdag. Jeg kan ikke udfra dit indlæg konkludere, hvor tydelig ledelsen er ift. initiativet. Min erfaring er at forandringsledelse ikke kan fordeles i løse mandater, men skal komme klart og konkret fra toppen. I mine øjne er der forskel på at man fra ledelsens side udtrykker ønsket om “øget fokus” og så til rent faktisk at signalere et strategisk sigte med denne forandring og de procesmæssige samt i sidste ende økonomiske gevinster dette sigte kunne give. Det er i princippet et spørgsmål om, hvor god tid man har. Jeg ville klart foretrække at det blev et markeret ledelsesmæssigt skridt, en konkret udmelding som man ditto konkret forklarede, hvordan man ville følge op på. Måske stadig med en vis grad af frivillighed, men også med en klar prioritering af de områder, der har størst forretningsmæssigt fokus. Hvis fokus er på at styrke samarbejdet mellem forretning og udvikling, ligger det jo principielt lige for at få forretningen til at udpege de områder, hvor den produkt- og procesmæssige modenhed kunne styrkes. Held og lykke med opgaven. Meget spændende. Venligst Anne Mette Bragh Frederiksen

    • Profile photo of Daniel Nielsen
      22. maj 2014 at 14:04

      Det er helt rigtigt set. Vi vil gerne frivillighedens vej. Og som du selv bemærker er ledelsesforankring absolut kritisk for om Agile Excellence(AE) kan lykkes. Generelt i KMD blæser forandringens vinde kraftigt over hele firmaet og ikke mindst i BNS&AM. AE er organisatorisk forankret under ledelsen for BNS&AM. Som med de fleste større virksomheder kan det være svært at forstå kommunikationsvejene internt i firmaet, men så vidt jeg er orienteret er ledelseslagene på de enkelte forretningsområde orienteret om AE. Det er sket i forbindelse med de samlede strategi seminarer de har haft i starten af året.

      Så for de projekter og teams der ligger i denne del af KMD tror vi på forandringen :-)

  2. Anne Mette Bragh Frederiksen
    22. maj 2014 at 14:38

    Hej igen. Ja, der er jo forskel på at være orienteret og så tage en beslutning, lægge en plan, iværksætte initiativer og definere de resultater man forventer som konsekvens, følge op samt tydeliggøre for medarbejderne at det er noget de bliver målt på. Endnu engang held og lykke, det bliver spændende at følge. Venligst Anne Mette

  3. Profile photo of agilerasmus
    28. maj 2014 at 7:24

    Jeg synes det lyder som en rigtig spændende opgave. Belært af forskellige organisationer synes jeg helt bestemt at det giver mening. Mange er rigtig gode til den mekaniske del af de agile metoder, men det halter voldsomt når det kommer til det mere filosofiske. Det er muligt at køre f.eks. Scrum eller Kanban uden at være agile. Ligesom det er muligt at være agil uden at køre selvsamme metodikker.

    Den største caveat, i min optik, er at der skal være “buy in” fra ledelsen således at man ikke ender op i en vandfaldsverden og ønsker at køre agilt. Et af de første symptomer på en sådan defekt er, hvis der kræves stor analyse/scoping der fastlægger 75 % af de efterfølgende arbejdsopgaver. Det er hverken agilt eller optimalt i forhold til at skulle kunne reagere interaktivt på de tilbagemeldinger der kommer fra brugere/kunder.

    • Profile photo of Daniel Nielsen
      28. maj 2014 at 18:58

      Helt enig. Den mekaniske del har tekniske folk typisk nemt ved. Det at følge en beskrivelse ala Henrik Knibergs “… from the trenches” serier er nemt i forhold til at have det agile mindset på plads. Den anden dag faldt jeg over Mike Cohn (igen-igen) og han har skrevet http://www.mountaingoatsoftware.com/blog/the-one-true-way-to-be-agile . Det passer meget godt overens med det du skriver :-).

      I forhold KMD og ledelsens “buy in”, så afhænger det rigtigt meget af området, projektet og evt kunden hvis vi snakker Application Management. Det kommer jeg forhåbentligt tilbage til når jeg får skrevet indlæg omkring de enkelte områder vi får startet.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *