Er din organisation agil ?

Agilitet – det fælles ansvar
Der er mange udviklingsafdelinger der ynder at kalde sig agile, men hvilke krav er der egentligt til en agil udviklingsorganisation ?

Lad os begynde med nerven i det agile setup –Teamet – og de krav der skal til, for at teamet kan kalde sig et agilt team.

Det er sikkert, at man ikke kommer nogle vegne uden en stor vilje til at tage ansvar for leverancer – her tænker jeg på både egne leverancer men så sandelig også et fælles ansvar for kollegers leverancer – både egne team-kolleger, men så sandelig også kolleger for andre team.

For at kunne tage et sådant ansvar er det nødvendigt at være seriøs omkring de agile værdier og lade det skinne igennem i alle sine handlinger.

Et af de vigtigste events i det agile setup er ”Sprint Retrospective”, hvor teamet aktivt forholder sig til egen performance og hvad der skal til for at forbedre den. Retrospective skal afholdes så ofte som muligt og må ikke springes over, for det er via retrospective at teamet sammen ”sliber kniven” og dermed har mulighed for at øge samarbejdet og produktiviteten i teamet.

Et team, der tager ansvar bør have fælles forståelse for estimater – fx Story Point – og følger efter hver sprint op på, om teamets velocity er stabil. Hvis velocity ikke er stabil forsøger teamet at ændre adfærd således at velocity kan blive stabil.

For at kunne opnå en stabil velocity er det nødvendigt at teamet sammen med Product Owner har en fælles roadmap for de kommende 3-6 måneders arbejde og til stadighed gennemfører Backlog Refinement på de højest prioriterede opgaver, således at de næste 1-2 Sprints opfylder Definition of Ready. Er det ikke tilfældet vil teamets velocity komme til at lide og kadencen falde.

Hvis vi fortsætter med ledelsen, så er kravene for at de kan kalde sig agile, bestemt ikke færre.

Ledelsen skal mobilisere samme seriøse indstilling til de agile værdiger som det agile team og selvfølgelig også lade dette skinne igennem i alle ledelsesmæssige handlinger.

Et nyt mindset for værdiskabelse skal introduceret og den gamle krystalkugle skal pakkes langt væk, sammen med klassiske scope, løsningsbeskrivelser, tidsplaner og økonomistyring.

Ledelsens vigtigste opgave er at sikre en fælles vision for det arbejde der ønskes udført samt at fastsætte rammer, råderum og retning for det agile team.

Dernæst skal ledelsen sikre den nødvendige arbejdsro for det agile team samt vise evne og vilje til at fjerne forhindringer, der sinker teamets fremdrift, således at teamet kan fokusere på at løse opgaver og tage ansvar for leverancer.

Konklusion:
Adfærd skal ændres og mange forandringer skal implementeres – En ny kultur i organisationen skal formes.

Agilitet kan alene opnås, hvis viljen er til stede.

Kan du være innovativ på kommando ?

SAFe, Innovation & Planning iteration.

De fleste kan ikke være innovative på kommando, men hvis du følger disse 4 punkter, er der meget større sandsynlighed for at du bidrager med innovation.

Accepter ikke status quo
Accepterer du status quo, vil du opleve at intet ændre sig. Der skal ofte et stærkt personligt motiv, drive og ønske om at gå ud over grænserne til, før du bliver innovativ.

Tænk muligheder frem for begrænsninger
Innovationens største hindring er ordet “nej”, så det er vigtigt at du tænker ud af boksen og ikke begrænses at et “nej”.

Vær frygtløs
De bedste innovatorer fortsætter trods deres fiaskoer, fordi de ved, at den største fiasko af alle er, at man ikke gør et forsøg på at innovere.

Hold op med at tænke
Innovative ideer kan komme til os på et hvilket som helst tidspunkt og kommer ofte når man foretager sig andet end at forsøge at være innovativ.

Konklusion: Spring ud i det med et fordomsfrit mindset uden frygt for fiasko – så vil de innovative tanker komme før eller siden.

SAFe – Scrum – Omvendt målhierarki

Transformation af en IT systemudviklingsproces fra en klassisk vandfaldsmodel til en agil model med SAFe og Scrum som framework er ikke enkelt.

Både på individ- og organisationsniveau sker der store forandringer – forandringer der kan virke meget voldsomme og omfangsrige for de berørte deltagere – deltagere som fremover bliver stillet overfor nye krav, ændret adfærd og brug af nye kompetencer, på mange områder.

Specielt afholdelse af hyppige Retrospective kan være skræmmende møder, hvor teamet reflekterer over, hvordan de som team kan blive mere effektive og efterfølgende justerer adfærd og processer

Hvis vi tænker på, hvor svært det er at ændre på eget adfærd og derefter tænker på, at hvert enkelt teammedlem har samme udfordring og dertil lægger ønskede adfærdsændringer som teamet sammen vælger at gøre noget ved, så er det forholdsvis enkelt at forstå at en transformation til et nyt agilt setup er hårdt arbejde og tager tid.

I en verden hvor der konstant er fokus på at forbedre og optimere processer og samarbejde, kan en alternativ metode til at finde områder, der har gode forbedringspotentialer være omvendt målhierarki.

Metoden praktiseres fx som en klassisk brainstorm, hvor deltagerne bedes om at komme med emner der sikrer, at vi som team kommer til at fejle eller blive en stor fiasko.

Jeg tænker at listen kommer til at indeholde uvaner, dårlig adfærd, historier som ”det var meget bedre i gamle dage” + alt det negative man kan finde på at sige om SAFe, Scrum, Confluence, JIRA og det agile setup i almindelighed.

Teamet kan efterfølgende arbejde med forbedringer og ændringer af adfærd på de emner, der for dem giver størst værdi.

De krav, der er til os som individ og team, skal matche vores potentiale – ja, vi bliver hele tiden målt og vejet – men husk også, at du selv har en forpligtelse til at få hele dit potentiale udnyttet.

Begynd med at være, en for teamet, positiv udgave af dig selv.

Brænder du, som mig, for SAFe, Scrum og de agile værdier, så er du velkommen til at LinkeUp med mig, så vi kan erfaringsudveksle og dele vores erfaringer.

Skriv gerne hvorfor du ønsker at LinkeUp med mig i din invitation.

SAFe – Scrum – Retrospective

Sprint 2 er nu vel afsluttet og teamet fortsætter sin transformation fra gammel vandfaldsmodel mod ny agil udviklingsmodel med Scrum og SAFe som framework.

Billedet er fra teamets Sprint Retrospective efter den netop afsluttede sprint, der blev afviklet ved at give hver deltager mulighed for at tale om et spørgsmål eller emne, som man følte for, ved at vælge blandt cirka 30 åbne spørgsmål, der lå fordelt på gulvet. 

En anderledes retrospective, der bestemt også gav en anderledes snak.

Vores tidligere Burn Down Chart har ikke været prangende, men denne gang lykkedes det os at ramme tæt på 90% af de kommittede User Stories.

Et specielt et flot resultat, når man ved at sprinten bl.a. har budt på en del mere Backlog Refining end oprindeligt planlagt, for at undgå samme sejtrækkende planning, som vi oplevede ved sidste Sprint Planning.

Et kort retrospective umiddelbart efter Sprint Planning havde opbakning til et endnu større forarbejde/refining af Product Backlog undervejs i sprinten samt en stadig mere konsekvent eksekvering af selv Sprint Planning mødet, for at holde indhold og mødelængde i skarpt fokus.

Begge gode initiativer og lære, som jeg glæder mig til at hjælpe med at implementere.

SAFe – Scrum – Teamstatus

Første sprint er afsluttet og der er gjort status på en  bestemt godkendt sprint.

Teamet havde besøg af RTE til Sprint Review, der sammen med Product Owner kunne godkende de afsluttede User Stories.

Ja, det hele lyder ganske problemfrit, men det er kun den halve sandhed og der har bestemt været mange udfordringer undervejs – specielt de 2 sidste dage i sprinten, hvor manglende adgang til testmiljø hos eksternt leverandør betød at flere User Stories ikke kunne godkendes – DoD var ikke opfyldt og vi må vente med at indtægtsfører vores Story Point til næste sprint.

Sprint Planning til den kommende sprint blev en sejtrækker og vi er vist alle enige om at der skal ske ændringer på det område til næste gang.

Som team fortsætter den positive udvikling, og jeg er ikke i tvivl om at der igen i sprint 2 vil ske et løft af overlæggeren – håber blot at jeg selv kan følge med.