Agile praksis er ikke bare for programvareutviklingsteam som sprinter for å kode, teste og slippe applikasjoner. Agile metoder, inkludert scrum og Kanban, brukes i dag av en rekke forretnings-, datavitenskap- og teknologiteam, inkludert IT-drift.
Selv om smidige metoder kan brukes på IT-drift med suksess, er det noen bemerkelsesverdige forskjeller i charteret, prioriteringene og kulturen til driftsteamene som trenger behandling. Å forstå disse forskjellene og deretter definere strategiske prioriteringer strukturerer hvordan selvorganiserende IT-operasjonsteam kan utføre sine initiativer og være bedre medlemmer av andre tverrfaglige smidige team.
Her er tre trinn du bør vurdere.
Omdefinere IT-operasjonenes oppdrag og charter
Medlemmer av IT-driftsteamet ser på sin primære jobb som å holde lysene på for produksjons-, avdelings- og utviklingsnettverk, systemer, applikasjoner og databaser. Mange følger ITIL (Information Technology Infrastructure Library) prosesser for hendelses-, problem- og endringsledelse og bruker billettsystemer som Cherwell, Jira Service Desk og ServiceNow for å spore dem. Når ansatte og andre sluttbrukere trenger hjelp eller har andre systemkrav, stoler IT-drift også på disse systemene for å fange forespørsler og støtte arbeidsflytene sine.
CIO vil sannsynligvis ha en eller flere strategiske veikart som er sterkt avhengige av IT-operasjonelle team. CIO har sannsynligvis en blanding av mobil, digital transformasjon, sky og datastrategier der IT-operasjoner kan spille både primære og støttende roller. Prioritetene kan omfatte skymigrering, infrastrukturprosjekter, store oppgraderinger av bedriftssystemer, nye støttemodeller for SaaS-verktøy, overholdelsesrevisjoner, installasjon av nye verktøy for samarbeid og arbeidsflyt, ERP-oppgraderinger og kontorflytting.
Spørsmålet er hvordan vil IT-drift styre arbeidet knyttet til disse tiltakene? Agile metoder er ideell for mange av dem, spesielt når det er dårlig definerte forhåndskrav, tekniske ukjente eller motstridende prioriteringer.
Men fordi mange i IT-operasjoner ser på smidig praksis som en utviklingsmetodikk, krever det litt coaching og diskusjon om deres mer viktige oppdrag, ansvarsområdet og måter å administrere sitt arbeid på.
Spesielt er mange innen IT-drift mer vant til å være oppgavedrevet av prosjektledere. De har ikke hatt muligheten til å spesifisere hvordan man best kan konstruere og implementere løsninger, sekvensere arbeidet og redusere risikoen på grunn av tekniske ukjente. Agile metoder behandler disse manglene ved top-down prosjektledelse. De krever at ingeniører går inn i smidige roller, deltar i seremonier og bruker smidige verktøy for å forstå en ny måte å jobbe på.
Omdefinere smidige metoder for IT-drift
Agile ledere kan ikke bare bruke out-of-the-box scrum eller Kanban til IT-driftsteam. Flere viktige forskjeller i kultur og driftsmodell trenger behandling. Her er noen få trinn å vurdere som en gruppe:
- Omdefinere smidige roller. De fleste IT-operasjoner har ikke produkteiere tildelt initiativene. I beste fall kan de ha prosjektsponsorer og analytikere som skriver krav. Det vil trolig kreve litt opplæring og coaching for å hjelpe folk med å påta seg produktansvar. Det viktigste er at de må definere hvem kundene er for deres initiativer og se på å prioritere arbeidet deres ut fra kundenes behov og verdier.
- Skriv historier og akseptkriterier. Ingeniører som jobber med systemer er ikke vant til å skrive krav som brukerhistorier og definere akseptkriterier. Mange ingeniører starter implementeringer ved å forstå det overordnede målet, og deretter jobbe med teknologien for å finne ut driftsmessige og optimale løsninger. Likevel er det vel verdt å legge til disiplinen med skrivekrav, da det hjelper med å utvikle en felles forståelse av målene fra et kunde- eller sluttbrukerperspektiv og deretter spesifisere akseptkriteriene rundt ikke-funksjonelle krav.
- Etablere prioriteringer. IT-drift må avbryte tiden for å svare på hendelser og oppfylle forespørsler sammen med sine forpliktelser om smidige tiltak. Utviklere har arbeidet sitt mest tilpasset sine smidige team og forpliktelser, men IT-operasjoner må svare på operasjonelle prioriteringer før de takler arbeidet med deres smidige etterslep. Mange IT-driftsteam bryter med hvordan de skal uttrykke prioriteringer, hva engasjement betyr når de kan forstyrres av prioritetshendelser, hvordan man estimerer smidige brukerhistorier og hvordan man måler kapasiteten.
- Velg passende smidige metoder. Arbeidstypene som er prioritert i IT-drift, stemmer bedre overens med noen metoder enn andre. Noen team som jobber med en samling av mindre tiltak kan ha nytte av å bruke Kanban; andre som jobber med lengre tiltak med komplekse krav, kan være bedre egnet for scrum. Større organisasjoner bør vurdere å støtte minst disse to metodene.
- Forstå rollene. IT-drift har forskjellige ansvarsområder i forskjellige smidige tiltak. De er sannsynligvis driverne for infrastruktur, migrering av skyer og sikkerhetsinitiativer og har definerte roller og ansvar for å føre tilsyn med smidige team. I andre, for eksempel devops, automatisering eller datastyring, er de sannsynligvis ikke driverne og deltar som smidige teammedlemmer. Begge scenariene krever å definere hvordan ingeniører engasjerer seg, basert på deres ansvar overfor teamet og programmet.
Integrer smidig med driftsverktøy
IT-operasjonelle team bruker allerede systemer for å håndtere hendelser og forespørsler, andre plattformer for overvåkning av systemer og tilleggsverktøy for å drive teamsamarbeid. Men ITSM (IT Service Management) -verktøy er ikke egnet til å spore flere ukes initiativer, og administrering av komplekse prosjekter med Gantt-diagrammer eller regneark bidrar til prosjektrisiko. Hvis operasjonsteamene skal bruke smidige metoder, trenger de det riktige verktøyet for denne måten å jobbe på.
Men IT-operasjoner som legger til et nytt smidig prosjektledelsesverktøy i blandingen, må ta hensyn til arbeidsflyten og dataintegrasjonen mellom deres prosesser og systemer.
Det er best å vurdere virkningen fra en enkelt ingeniørs perspektiv. De bruker kanskje PowWow Mobile for tjenestestyring, Jira for smidige tiltak, Slack for samarbeid og BigPanda for AIops. Det legger til overhead for å klikke på flere verktøy for å kjenne arbeidsprioritetene, hvordan du registrerer statusen for pågående arbeid, og hvor du kan dele informasjon med kolleger. Det kan også skape forvirring for interessenter når en ingeniør forplikter seg til å fullføre arbeidet med de smidige teamene, men blir trukket av oppgaven for å svare på en prioritert hendelse.
IT-operasjonelle team må vurdere hvordan arbeidsflyt og data kobles mellom disse verktøyene og sørge for at det er en lukket sløyfe-prosess. For eksempel kan en hendelse starte i servicedesket, få utbedringer implementert av et agilt team for IT-drift, og deretter kreve validering gjennom overvåkingsverktøy. Å spore ende til slutt gjennom tre eller flere teknologier legger til slit, og integrasjonen mellom forbedrer datakvaliteten.
Disse problemene er bare utgangspunktet. Det er viktig at IT-operasjonelle team bruker smarte retrospektiver for å diskutere hva som fungerer, hva som må endres, og hvordan de kan utvikle metodene sine.
