7 beste fremgangsmåter for eksterne, smidige team

Agile metoder fungerer best når alle i teamet er sammen på ett sted. Når team deler et arbeidsområde, er det enkelt for lagkamerater å stille spørsmål, parre programmeringsoppgaver og løse problemer uten å planlegge møter. Å bruke teknologier som nettkonferanser, gruppechatter og e-post er bare ikke like effektivt som direkte person-til-person-interaksjon.

Teknisk søkelys:
Samarbeid svarer på samtalen

Fjernarbeid, nå og for alltid? (Computerworld)
Hurtigreparasjoner for videokonferanser trenger en nytenking når pandemien er over (Network World)
8 viktige sikkerhetshensyn for å beskytte fjernarbeidere (CSO)
7 hemmeligheter for vellykkede eksterne IT-team (CIO)

Når det er sagt, kan organisasjoner få smidige metoder til å utmerke seg med eksterne og distribuerte team, men det tar litt arbeid og eksperimentering. Teammedlemmer må finne optimal bruk av teknologier og tilpasse seg kommunikasjonsstiler for å sikre teamets produktivitet, samarbeid og kvalitet.

Med utbruddet av COVID-19 må mange smidige team skifte fra å jobbe på kontorer til å jobbe eksternt. Dette vil være en ny opplevelse for mange mennesker som ikke har jobbet hjemme en betydelig del av karrieren, og for team som er vant til personlig interaksjon. Videre kan noen teammedlemmer bli syke eller møte andre vanskeligheter på grunn av den voksende pandemien, så smidige team må tilpasse seg en ny måte å jobbe på.

Denne artikkelen er en enkel guide som er rettet mot å hjelpe teammedlemmer, team og organisasjoner overgang fra primært personlige agile team til høyt distribuerte team.

Velg riktig utstyr, verktøy og arbeidsplass

Hvis du skal jobbe eksternt, må du sørge for at du har et oppsett som fungerer for deg, din bedrift og teamet ditt. Tenk på det som et kontorflytt og invester tid på forhånd for å evaluere alternativene og sørg for at du har alt du trenger for å være produktiv, komfortabel og i et rom der du er minst sannsynlig å bli distrahert.

Vurder disse 12 hensynene når du arbeider eksternt i lengre perioder som inkluderer anbefalinger om arbeidsdisipliner, arbeidsområde, utstyr, nettverk og verktøy.

Noen endringer du må gjøre, blir ikke tydelige før etter at du kommer i gang. Hvis du har dårlig tilkobling, kan det hende du må flytte den trådløse ruteren eller bytte til en kablet tilkobling. Plasseringen til skrivebordet kan trenge justering hvis du skal gjøre mye videokonferanser. Du må sannsynligvis be familiemedlemmer om å holde avstand når du jobber.

Vær til stede og snakk med lagkameratene

Agile team lykkes med å balansere tiden som er viet til samarbeid, med tiden som er brukt på den konsentrerte innsatsen som kreves for koding og andre utviklingsaktiviteter. På kontoret er det litt lettere å se en lagkamerats fokus, og disiplinerte smidige team finner måter å unngå distraksjoner og kontekstbytte.

Når du jobber eksternt, må teamene være online, men også dele tilgjengeligheten. Verktøy som Slack og Microsoft Teams lar deg angi tilgjengelighetsstatus mens andre samarbeidsverktøy lar deg dempe varsler. Å bruke statusinnstillingene er kritisk viktig når team har åpent for fleksibel arbeidstid.

Agile team må planlegge tid for formelle samarbeidsøkter og gjøre arbeidet for å fullføre brukerhistorier, men teammedlemmer bør også delta i småprat. Folk reagerer ulikt på tider med stress og å jobbe eksternt, så det er viktig å sjekke inn med hverandre. Dessuten har folk forskjellige kommunikasjonsstiler online kontra personlig, og det er en ny mulighet til å få flere mennesker med i online-samtaler.

Scrum-mestere, tekniske ledere og produkteiere bør regelmessig stille teamet spørsmål om deres forståelsesnivå rundt kravene, sperrer for deres fremgang, og hvis det er noe de trenger for å forbedre produktiviteten og gleden.

Til slutt bør scrum-mestere og tekniske ledere fra flere lag være i regelmessig kontakt med hverandre. Deres erfaringer og problemer med å administrere sine eksterne team er sannsynligvis ikke unike. Å dele kunnskap om hvordan de får sine smidige team til å samarbeide eksternt, vil utvilsomt være til fordel for hele gruppen.

Gjennomgå tilnærminger til smidige seremonier

Agile team som skifter til eksternt samarbeid, trenger ikke å redesigne prosessen eller gjøre unna smidige seremonier. Men å gå fjernkontroll kan kreve at scrum-mestere tenker nytt over hvordan de skal gjennomføre møtet, avhengig av størrelsen på teamet og de tilgjengelige samarbeidsverktøyene.

For eksempel må personlige team som ser over scrumbrettet under den daglige standupen, utvikle en digital versjon av denne seremonien. Hvis teamet er lite og historisk sett har opplevd relativt få blokkeringer som hindrer brukerhistoriene i arbeidet, kan de kanskje gjøre unna et møte og erstatte det med en planlagt chat-samling.

Andre forslag for eksterne smidige team:

Bruk digitale tavleverktøy for sprintplanlegging og designøkter
Sett opp videokonferanser for forpliktelsesmøter
Velg en person du vil skjermdeling under sprintanmeldelser
Bruk undersøkelser eller programmer med lav kode for å fange tilbakemeldinger i ettertid

Forplikte seg til realistiske team- og individuelle oppgaver

Agile team som skifter fra personlig til eksternt samarbeid, må tilbakestille sprinthastighetene og gjennomgå nivået og kompleksiteten i arbeidet de realistisk kan forplikte seg til og fullføre. Scrum-mestere og smidige ledere bør anvende praksis som ligner på nyopprettede smidige team og la teamene tilpasse seg nye måter å jobbe på.

For eksempel er det dårlig å anbefale å forplikte seg til komplekse brukerhistorier som krever bidrag fra flere teammedlemmer fordi noen lagkamerater kan bli utilgjengelige i løpet av sprinten. Hvis det er mulig, bør disse historiene deles opp i mindre eller forsinkes hvis produkteieren er i stand til å prioritere dem.

Tilsvarende vil smidige team kanskje unngå å forplikte seg til historier som har avhengighet av arbeid fra andre lag. Det ekstra samarbeidet kan ta et par sprinter å definere for nydannede fjernteam.

Øk dokumentasjonsnivået

Agile utviklingsteam prioriterer arbeidskode fremfor forhåndsdokumentasjon, men det betyr ikke at dokumentasjon av arkitektur, API-er og kode ikke er nødvendig.

Team som jobber eksternt i lengre tid, vil kanskje diskutere dokumentasjonsstandarder og se om det er nødvendig med mer betydelig innsats. Noen ganger kan dokumentering av koden erstatte noen av de personlige implementeringsdiskusjonene rundt hvordan en kodemodul fungerer eller hvordan en lagkamerat adresserer teknisk gjeld.

Invester i pigger, CI / CD og adressering av teknisk gjeld

Team som forventer å jobbe eksternt i lengre perioder, kan finne det lettere å fokusere på mer tekniske historier i stedet for de som krever interaksjoner med produkteier og interessenter. For eksempel involverer instrumentering av en flerstegs brukeropplevelse samarbeid mellom produktseier, designere, utviklere og testere. Det kan være vanskeligere å koordinere diskusjoner eller utvikle en felles forståelse av sluttbrukernes behov når team akkurat begynner å jobbe eksternt.

Det er andre muligheter for å prioritere arbeid som krever mindre samarbeid og mer individuell konsentrasjon og innovasjon. Prioritering av små pigger for å teste nye ideer er et eksempel, spesielt hvis en utvikler kan jobbe med et kort bevis på konseptet med få forstyrrelser eller kontekstbytte. Et annet alternativ er å prioritere adressering av teknisk gjeld på kodenivå, spesielt omforming av kodemoduler, legge til enhetstesting eller forbedre unntakshåndtering. Et tredje alternativ er å investere tid på å utvikle eller forbedre CI / CD-automatisering.

Disse mer teknisk utfordrende oppdragene hjelper også utviklere å konsentrere seg om å fullføre en jobb i områder der de ser fordelene direkte.

Gjennomgå distribusjonsstrategier og reduser risikoen

Meget samarbeidende smidige lag lærer å jobbe sammen som høyytelses hockeylag. I hockey, selv om pucken beveger seg raskt og kan sprette uregelmessig, bruker spillerne en blanding av designet spill og improvisasjoner som muliggjør både sterkt defensivt spill og eksplosivt offensivt spill.

Flytt nå dette laget fra en innendørs arena og be dem spille på en utendørs innsjø, så trenger de litt tid på å tilpasse seg elementene. De vil spille konservativt forsvar en stund til de blir komfortable med det nye miljøet og gjenvinner rytmen.

Det samme gjelder for smidige lag og smidige organisasjoner av flere lag. Det er sant om lagene jobber med eldre systemer eller bygger sky-første applikasjoner ved hjelp av den nyeste devops-fremgangsmåten.

Forholdene som krever at smarte team jobber eksternt, vil sannsynligvis påvirke andre aspekter av virksomheten, inkludert drift, kundeforventninger og dynamikk i forsyningskjeden.

Kunder og sluttbrukere vil kanskje ikke ha samme distribusjonsfrekvens, spesielt hvis denne frekvensen risikerer påliteligheten eller ytelsen til applikasjonen. Hvis du har API-er som fungerer med bedriftens leverandører, kan disse leverandørene være mindre tilgjengelige for å delta i å teste endringene. Hvis programvaren er underlagt overholdelse eller tilsyn fra myndighetene, kan det være vanskeligere å få de nødvendige gjennomgangene og godkjenningene.

Agile team må anerkjenne det bredere settet med endringer som påvirker organisasjonens forretningsmodell, kunder og arbeidsmiljø. Organisasjonsprinsippene som kjørte alt fra hastigheten og frekvensen av distribusjon til de typer arbeid og brukerhistorier som blir prioritert, må gjennomgås fra et nytt driftsperspektiv.

En stor del av å være smidig, og ikke bare følge smidig praksis, er å erkjenne når og hvordan man kan endre seg.