Agil praksis er ikke kun for softwareudviklingsteams, der sprinter for at kode, teste og frigive applikationer. Agile metoder, herunder scrum og Kanban, bruges i dag af en række forretnings-, datalogi- og teknologiteams, herunder it-operationer.
Selvom smidige metoder kan anvendes til it-operationer med succes, er der nogle bemærkelsesværdige forskelle i chartret, prioriteterne og kulturen for driftsteam, der har brug for overvejelse. At forstå disse forskelle og derefter definere strategiske prioriteter strukturerer, hvordan selvorganiserende it-driftsteam kan udføre deres initiativer og være bedre medlemmer af andre tværfaglige agile teams.
Her er tre trin at overveje.
Omdefinere it-driftenes mission og charter
Medlemmer af it-driftsteam betragter deres primære job som at holde lyset tændt til produktions-, afdeling- og udviklingsnetværk, systemer, applikationer og databaser. Mange følger ITIL (Information Technology Infrastructure Library) -processer for hændelses-, problem- og ændringsstyring og bruger billetsystemer som Cherwell, Jira Service Desk og ServiceNow til at spore dem. Når medarbejdere og andre slutbrugere har brug for hjælp eller har forskellige systemkrav, er IT-operationer også afhængige af disse systemer til at registrere anmodninger og understøtte deres arbejdsgange.
CIO vil sandsynligvis have en eller flere strategiske køreplaner, der stærkt er afhængige af IT-operationelle teams. CIO'er har sandsynligvis en blanding af mobil, digital transformation, sky og datastrategier, hvor it-operationer kan spille både primære og understøttende roller. Prioriteterne kan omfatte cloudmigrationer, infrastrukturprojekter, større opgraderinger til virksomhedssystemer, nye supportmodeller til SaaS-værktøjer, compliance-audits, installation af nyt værktøj til samarbejde og workflow, ERP-opgraderinger og office-flytninger.
Spørgsmålet er, hvordan vil IT-operationer styre det arbejde, der er knyttet til disse initiativer? Agile metoder er ideel til mange af dem, især når der er dårligt definerede forudgående krav, tekniske ukendte eller modstridende prioriteter.
Men fordi mange i it-operationer ser agile fremgangsmåder som en udviklingsmetode, kræver det noget coaching og diskussion om deres mere vitale mission, ansvarsområdet og måder at styre deres arbejde på.
Specifikt er mange i it-operationer mere vant til at være opgavedrevne af projektledere. De har ikke haft mulighed for at specificere, hvordan man bedst kan konstruere og implementere løsninger, sekvensere arbejdet og afbøde risici på grund af tekniske ukendte. Agile metoder behandler disse mangler ved top-down projektledelse. De kræver, at ingeniører træder ind i smidige roller, deltager i ceremonier og bruger agile værktøjer til at forstå en ny måde at arbejde på.
Omdefiner agile metoder til it-drift
Agile ledere kan ikke bare anvende out-of-the-box scrum eller Kanban til it-driftsteams. Flere væsentlige forskelle i kultur og driftsmodel skal overvejes. Her er et par trin til gennemgang som en gruppe:
- Omdefiner agile roller. De fleste it-operationer har ikke produktejere tildelt deres initiativer. I bedste fald kan de have projektsponsorer og analytikere, der skriver krav. Det vil sandsynligvis kræve lidt træning og coaching for at hjælpe folk med at påtage sig produktansvar. Det væsentligste er, at de bliver nødt til at definere, hvem kunderne er til deres initiativer og ønsker at prioritere deres arbejde ud fra kundernes behov og værdier.
- Skriv historier og acceptkriterier. Ingeniører, der arbejder på systemer, er ikke vant til at skrive krav som brugerhistorier og definere acceptkriterier. Mange ingeniører starter implementeringer ved at forstå det overordnede mål og arbejder derefter med teknologien for at finde ud af operationelle og optimale løsninger. Alligevel er det værd at tilføje disciplinen med at skrive krav, da det hjælper med at udvikle en fælles forståelse af målene fra et kunde- eller slutbrugerperspektiv og derefter specificere acceptkriterierne omkring ikke-funktionelle krav.
- Fastlæg prioriteter. IT-operationer skal afbryde tiden for at reagere på hændelser og imødekomme anmodninger sammen med deres forpligtelser til agile initiativer. Udviklere har for det meste deres arbejde tilpasset deres agile teams og forpligtelser, men it-operationer skal reagere på operationelle prioriteter, før de tackler arbejdet med deres agile efterslæb. Mange it-driftsteam kæmper med, hvordan man udtrykker prioriteter, hvad engagement betyder, når de kan forstyrres af prioritetshændelser, hvordan man estimerer smidige brugerhistorier, og hvordan man måler deres kapacitet.
- Vælg passende agile metoder. De typer arbejde, der prioriteres i it-operationer, stemmer overens med nogle metoder bedre end andre. Nogle teams, der arbejder på en samling af mindre initiativer, kan have gavn af at bruge Kanban; andre, der arbejder på længere initiativer med komplekse krav, kan være bedre egnet til scrum. Større organisationer bør overveje at støtte mindst disse to metoder.
- Forstå rollerne. IT-operationer har forskellige ansvarsområder i forskellige agile initiativer. De er sandsynligvis drivkræfterne for infrastruktur, cloudmigration og sikkerhedsinitiativer og har definerede roller og ansvarsområder, der fører tilsyn med agile teams. I andre, såsom devops, automatisering eller datastyringsinitiativer, er de sandsynligvis ikke drivere og deltager som smidige teammedlemmer. Begge scenarier kræver, at ingeniører definerer, baseret på deres ansvar over for teamet og programmet.
Integrer smidig med operationelle værktøjer
IT-operationelle teams bruger allerede systemer til styring af hændelser og anmodninger, andre platforme til overvågningssystemer og yderligere værktøjer til at drive teamsamarbejde. Men ITSM (IT Service Management) -værktøjer er ikke egnede til at spore flere ugers initiativer, og styring af komplekse projekter med Gantt-diagrammer eller regneark tilføjer projektrisici. Hvis operationsteams vil anvende smidige metoder, har de brug for det rigtige værktøj til denne måde at arbejde på.
Men it-operationer, der tilføjer et nyt smidigt projektledelsesværktøj til blandingen, skal overveje workflow og dataintegration mellem deres processer og systemer.
Det er bedst at overveje virkningen fra en enkelt ingeniørs perspektiv. De bruger muligvis PowWow Mobile til servicestyring, Jira til agile initiativer, Slack for samarbejde og BigPanda til AIops. Det tilføjer overhead for at klikke på flere værktøjer for at kende arbejdsprioriteterne, hvordan man registrerer status for igangværende arbejde, og hvor man kan dele oplysninger med kolleger. Det kan også skabe forvirring for interessenter, når en ingeniør forpligter sig til at afslutte arbejdet med de agile teams, men trækkes ud af opgaven for at svare på en prioritetshændelse.
IT-operationelle teams skal overveje, hvordan workflow og data forbinder disse værktøjer og sikre, at der er en lukket loop-proces. For eksempel kan en hændelse starte i servicedesk, få afhjælpninger implementeret af et agilt team for it-drift og derefter kræve validering gennem overvågningsværktøjer. Sporing af den ene ende til den anden gennem tre eller flere teknologier tilføjer slid, og integrationen mellem forbedrer datakvaliteten.
Disse spørgsmål er kun udgangspunktet. Det er vigtigt, at it-operationelle teams bruger agile retrospektiver til at diskutere, hvad der fungerer, hvad der skal ændres, og hvordan man udvikler deres metoder.
