Det agile manifestet forklart og hvordan du bruker det

Hva er det smidige manifestet?

Det smidige manifestet er en skriftlig erklæring som inneholder fire verdier og 12 prinsipper, utformet for å forbedre arbeidsmåter innen programvareutvikling.

Manifestet er mer filosofisk enn foreskrivende og var ment å kunne tilpasses ulike teamstørrelser, mål og forhold.

Det smidige manifestets 4 verdier

Det offisielle smidige manifestet består av disse 4 verdiene:

1. Enkeltpersoner og samhandling fremfor prosesser og verktøy
2. Fungerende programvare fremfor omfattende dokumentasjon
3. Samarbeid med kunden fremfor kontraktsforhandling
4. Å reagere på endringer fremfor å følge en plan

Det er interessant å merke seg at forfatterne fulgte verdiene med denne presiserende uttalelsen: "Det vil si at selv om det finnes verdi i punktene til høyre, verdsetter vi punktene til venstre høyere."

Dette understreker at det smidige manifestet ikke handler om å følge en bestemt prosess eller bruke et spesifikt smidig verktøy. Det handler om å ta til seg en bestemt tankemåte.

Det smidige manifestets 12 prinsipper

I tillegg til de fire verdiene beskriver det smidige manifestet 12 støttende prinsipper som forklarer hvordan verdiene skal tolkes og anvendes i smidige prosjekter.

1. Sett kunden først

Den høyeste prioriteten er å tilfredsstille kunden gjennom tidlig og kontinuerlig levering av verdifull programvare.

2. Ta imot endringer

Ta imot endrede krav, selv sent i utviklingen. Smidige prosesser utnytter endringer til kundens konkurransefortrinn.

3. Lever ofte

Lever fungerende programvare ofte, fra et par uker til et par måneder, med en preferanse for den kortere tidsskalaen.

4. Samarbeid på tvers av team

Forretningsfolk og utviklere må arbeide sammen daglig gjennom hele prosjektet.

5. Dyrk talent

Bygg prosjekter rundt motiverte enkeltpersoner. Gi dem miljøet og støtten de trenger, og stol på at de får jobben gjort.

6. Snakk sammen

Den mest effektive metoden for å formidle informasjon til og innad i et utviklingsteam er samtale ansikt til ansikt.

7. Mål det som betyr noe

Fungerende programvare er det viktigste målet på fremdrift.

8. Tilpass arbeidstempoet for å unngå utbrenthet

Smidige prosesser fremmer bærekraftig utvikling. Oppdragsgivere, utviklere og brukere bør kunne opprettholde et jevnt tempo på ubestemt tid.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

9. Fokuser på kvalitet, så går arbeidet raskere

Kontinuerlig oppmerksomhet på teknisk kvalitet og god utforming styrker smidigheten.

10. Omfavn enkelhet

Enkelhet–kunsten å maksimere mengden arbeid som ikke blir gjort–er avgjørende.

11. Ikke detaljstyr

De beste arkitekturene, kravene og utformingene oppstår i selvorganiserende team.

12. Reflekter og juster

Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt, og finjusterer og justerer deretter atferden sin.

Historien, forfatterne og tilblivelsen av Det smidige manifestet

I teknologiverdenen diskuteres Det smidige manifestet med den samme ærbødigheten og respektløsheten som enhver hellig tekst som har blitt overlevert gjennom tidene.

I februar 2001 kom 17 programvarefagfolk som kalte seg «Den smidige alliansen», sammen i den amerikanske delstaten Utah for å utvikle det de kalte et «Manifest for smidig programvareutvikling». Dokumentet, som legger vekt på fire verdier og 12 prinsipper, er nå kjent som Det smidige manifestet.

Forfatterne av Det smidige manifestet omtales ofte som Den smidige alliansen, og inkluderte representanter for ulike utviklingsprosesser, blant annet ekstrem programmering, Scrum og Crystal. 

Et raskt blikk på det offisielle nettstedet for manifestet viser forfatterne i en sammenheng som kan gi assosiasjoner til et hemmelig selskap eller et møte mellom grunnleggere. Det var tydelig at hensikten deres var å skape noe som skulle ha en varig innvirkning på bransjen. Det har det utvilsomt hatt.

Selv om personene som møttes i Utah, ikke var pionerene innen smidige prinsipper generelt, konkretiserte de verdiene som hadde vokst frem en stund i bakgrunnen av programvareutviklingsverdenen.

I dag har den smidige metodikken gjennomsyret nesten alle bransjer.

Forfatterne inkluderte:

• Kent Beck
• Mike Beedle
• Arie van Bennekum
• Alistair Cockburn
• Ward Cunningham
• Martin Fowler
• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries
• Jon Kern
• Brian Marick
• Robert C. Martin
• Steve Mellor
• Ken Schwaber
• Jeff Sutherland
• Dave Thomas

Hvorfor Det smidige manifestet fortsatt er viktig

Det smidige manifestet er fortsatt relevant på grunn av fokuset på menneskesentrerte arbeidsmetoder og muligheten for fleksibilitet.

Raske teknologiske endringer medfører ofte skiftende prosjektkrav. Det smidige manifestet gjør det mulig for prosjektledere å prioritere tilpasningsevne og samarbeid ved å skape et responsivt og robust prosjektmiljø som samtidig kan levere arbeid, innovere og endre retning ved behov.

Det fremmer også en kundesentrert tankegang ved å verdsette fungerende løsninger fremfor omfattende dokumentasjon. Dette gjør det mulig for prosjektledere å innhente tilbakemeldinger tidlig og kontinuerlig videreutvikle arbeidet sitt, slik at prosjektet samsvarer tett med brukernes behov. Denne iterative og kundedrevne tilnærmingen øker prosjektets suksessrate og tilfredshet.

Slik anvender du Det smidige manifestet

La oss gå litt dypere inn i hver av de fire verdiene i det smidige manifestet. Ved å gjennomgå kjerneverdiene skal vi også utforske de 12 prinsippene som bygger videre på hver av dem.

Verdi nr. 1: Individer og samhandling fremfor prosesser og verktøy

Kjernen i smidig handler om mennesker. Smidig legger vekt på at et team arbeider sammen, samarbeider tett og tar beslutninger selvstendig. Smidig handler ikke om å fortelle et team hva det skal gjøre eller bygge. 

I smidige prosjekter må kommunikasjonen flyte fritt og være kontinuerlig, ikke være definert og planlagt. Å arbeide i lukkede siloer er ikke det smidig handler om.

Evaluer teamkommunikasjonen

Spør deg selv: Har du og teamet ditt samtaler ansikt til ansikt? Eller er dere avhengige av e-post, dokumenter og enkelte svært populære meldingsverktøy (uten å nevne navn her)? 

Selv om dere arbeider eksternt, kan en samtale ansikt til ansikt bidra til at ting skjer raskere. Dette gjelder spesielt når et team nettopp er i ferd med å bli dannet, fordi synkron kommunikasjon fremmer tillit og åpenhet og bidrar til å bygge relasjoner.

Vær mindre av en kontrollfrik

Vi har alle gjort oss skyldige i dette av og til. Men tillit er avgjørende for smidig arbeid. Ser du etter noe du kan sette i verk med en gang? IKKE DETALJSTYR (ja, jeg mente å rope det).

Det er fristende å gå i detalj på oppgavene, dele dem ut til teamet og deretter følge dem opp frem til de når den pålagte fristen (eller ikke gjør det), slik at du har kontroll over alt. Men hvis du virkelig skal gi teamet ditt myndighet, må du trekke deg litt tilbake og la dem ta eierskap til arbeidet sitt!

Oppmuntre til et selvorganiserende team

Det handler ikke om å administrere – det handler om å lede og legge til rette. Et selvorganiserende team betyr et team som velger hvordan arbeidet best kan utføres. De bør bestemme hvordan de skal omforme arbeidskøen til kode som kan lanseres. Men ikke gå til den motsatte ytterligheten og ikke tilby noen hjelp eller veiledning – teamet trenger fortsatt en visjon, motivasjon og hjelp til å løse hindringer.

Hvordan kan du da gå bort fra å dele ut oppgaver og i stedet finne ut hvordan du kan legge til rette for arbeidet?

Ikke stress med prosessen eller verktøyet

Jeg vet, jeg vet – det snakkes stadig om prosjektstyringsverktøy og smidig prosjektstyringsprogramvare i verdenen for smidig prosjektledelse.

Men her er saken: Kunden din bryr seg ikke om den interne smidige arbeidsflytprosessen din. Det bør de heller ikke gjøre.

Smidig metodikk handler om å ha en kundesentrert tilnærming og gjøre teamet ditt i stand til å levere bedre og mer verdifullt arbeid. Mer om den kundesentrerte tilnærmingen senere!

Fjern siloer

Siloer hindrer samarbeid og svekker derfor de smidige verdiene. 

Vurder disse tipsene for å gå bort fra siloer:

• Samle teamet på samme sted: Ja, denne igjen. Det er flott hvis designerne dine kan sitte i nærheten av hverandre og snakke om designting, men er det ikke bedre om de snakker med utviklerne om å bygge dette flotte produktet? Jeg vet at dette kan være vanskelig å gjennomføre i en større organisasjon eller i eksterne arbeidsmiljøer, men selv det å møtes i en felles Slack-kanal eller ha planlagte samarbeidsøkter der folk kan arbeide konsentrert samtidig og eksternt, kan holde teamet mer samkjørt.
• Unngå overleveringer mellom avdelinger: Den mer trinnvise, fossefallsinspirerte tilnærmingen, der hver avdeling arbeider i etapper (UX, deretter design, så utvikling og til slutt QA), kan ofte føre til kommunikasjonsbrudd og økt sløsing i et prosjekt. Vurder å få teamet til å arbeide sammen om funksjoner i stedet for å overlevere dem nedover i en kjede. Selv om dere arbeider i sprinter, men med en innledende designsprint, bør du involvere utviklerne i designsprinten – det er tross alt de som skal bygge dette!

Verdi nr. 2: Fungerende programvare fremfor omfattende dokumentasjon

Husk at manifestet ikke sier at dokumentasjon skal fjernes – det verdsetter ganske enkelt elementene til venstre høyere enn dem til høyre. Det betyr at dokumentasjon fortsatt finnes. Scrum har for eksempel brukerhistorier som forteller en utvikler hvordan de skal komme i gang med byggingen.

Men hva kan du gjøre for å bevege deg bort fra den omfattende og tidkrevende dokumentasjonen og raskt komme i gang med noe konkret?

Forenkle dokumentasjonen du bruker

Identifiser eventuelle smertepunkter eller hindringer i prosessen. Har du for mye dokumentasjon? Bruker du en evighet på å utarbeide det perfekte kravdokumentet, bruker lang tid på funksjonelt omfang og går deretter tom for tid til å bygge produktet? Reduser unødvendig dokumentasjon ved å:

• Fokusere på design- og utviklingsoppgaver som skal inn i selve produktet, fremfor et skriftlig dokument som til syvende og sist ikke vil bli brukt
• Holde arbeidsmøter på forhånd for å definere krav og neste steg, i stedet for å skrive lange dokumenter. Dokumenter og del resultatene med bilder og korte notater.

Kom raskt i gang med byggingen

Å skrive store mengder kravdokumentasjon er én måte å kartlegge behovene til virksomheten, klienten og kunden på. Men til syvende og sist er det mye mer nyttig å se noe som fungerer, oppfører seg og reagerer.

Vurder noen av følgende måter å drive prosjektet raskt fremover på:

• Komprimer den innledende utforskningen eller definisjonen til en kortere tidsperiode: Ved å begrense hvor mye tid du bruker på å definere og avklare ting, kan du raskere komme frem til noe designerne og utviklerne kan ta fatt på. Du kan fremskynde prosessen ved hjelp av disse spørsmålene til utforskningsmøtet.
• Hold arbeidsmøter: Arbeidsmøter med teamet samler interessenter slik at beslutninger kan tas raskere.
• Endre prosjektplanen: Har du lagt opp til definisjon, deretter design og så utvikling? Vurder å fremskynde utviklingen og få designere og utviklere til å produsere noe sammen, tidligere.

Bruk prototypemetoder i stedet for statiske design

I stedet for å se på fremdrift som et definisjonsdokument eller et statisk design som fungerer som en avkrysningsboks for kunden din, kan du vise dem noe som blir en del av det ferdige produktet.

Bruk rask prototyping for å få noe som fungerer og kan brukes – og, enda viktigere, noe du kan teste med kunder. Å samle inn tilbakemeldinger på en prototype blir en nyttig måte å følge fremdriften på, i stedet for å stole på en leveranse som ikke har fordelen av å være en del av sluttproduktet.

Du kan lage prototyper med ulike detaljnivåer:

• Lav detaljgrad: Klikkbare design. Dette er når du raskt trenger å lage en skisse for å teste med kunder, mer som en test av utseende, følelse og enkle interaksjoner.
• Middels detaljgrad: Bruk av noe bevegelse eller animasjon.
• Høy detaljgrad: Fungerende HTML. Brukes til komplekse interaksjoner, men kan videreføres til kode som kan settes i produksjon.

Prototyper med høy detaljgrad ligger nærmere «fungerende programvare» enn de andre typene, men kan ta mer tid å produsere. Prototyper med lav eller middels detaljgrad gir utviklere bedre veiledning enn statiske design.

Lever noe til sluttbrukeren eller kunden raskt

Dette er viktig.

Med hyppige lanseringer av fungerende programvare kan kunden ta i bruk alle nye funksjoner som er lansert. I stedet for å vente til slutten av prosjektet med en stor lansering, er det avgjørende å levere verdi til kunden tidligere for å få et bedre produkt.

Hvordan kan du oppnå hyppigere leveranser i organisasjonen din?

• Gå gjennom prosjektplanen eller prosjektveikartet: Har du planlagt å fullføre utviklingen og deretter lansere på slutten av prosjektet? Samarbeid i stedet med teamet ditt om å dele opp arbeidet i funksjoner eller arbeidsdeler som kan lanseres uavhengig underveis.
• Fokuser på blokkeringer: En sentral del av rollen din er å hjelpe teamet med å fjerne hindringer når problemer oppstår. Hvordan kan du hjelpe dem med å levere mer effektivt? Finnes det arbeidsmåter som forsinker lanseringer? En sprintretrospektiv med teamet ditt kan avdekke muligheter for prosessforbedring.
• Automatiser: Hvis organisasjonen din legger ned mye arbeid i lanseringer, bør du automatisere prosesser der det er mulig. Automatisert testing og distribusjon kan for eksempel spare manuelt arbeid og redusere innsatsen som kreves for en lansering. Snakk med det smidige utviklingsteamet ditt om prosessene de bruker, og mulighetene for automatisering.

Verdi nr. 3: Kundesamarbeid fremfor kontraktsforhandling

I stedet for å utforme en svært spesifikk kontrakt i begynnelsen av et prosjekt som beskriver nøyaktige leveranser, omfang, budsjett og tidsplaner, bør du holde den smidige kontrakten så overordnet som mulig. Ta beslutninger underveis i prosjektet ved å samarbeide tett med kundene og interessentene dine.

Smidig utvikling handler ikke om å bruke masse tid på å definere krav på forhånd. Det handler om å komme i gang med et prosjekt og lære underveis, basert på kundetesting og tilbakemeldinger fra fungerende programvare.

Ha kunden i sentrum

Jeg liker dette sitatet fra en artikkel av Neil Killick:

«En som tenker smidig, spør hele tiden: «Hva er den enkleste eller raskeste måten å skape verdi for kunden på?» Stiller du deg det spørsmålet hver dag? Hvis ikke, er det ditt første steg.»

Det er ikke bare designere og utviklere som bør tenke slik – prosjektledere bør også gjøre det. Vi har også ansvar for å levere det best mulige produktet eller den best mulige tjenesten til en kunde. Kunden din, brukeren av produktet eller tjenesten din, bør stå i sentrum for alt du gjør.

Sett sluttkunden i sentrum av planen

I stedet for å planlegge rundt leveranser og estimater bør du planlegge rundt verdifulle resultater for kunden. Hva ønsker vi at kunden skal gjøre, og hvorfor? Hvordan skal vi måle om dette fungerer?

Vri samtalen slik at den fokuserer på hvilken verdi vi har levert til kunden, i stedet for på hvor mange arbeidsoppgaver vi har levert.

Involver kunden din tett

I stedet for å holde et ukentlig statusmøte og deretter levere til kunden og interessentene dine på slutten av en bestemt periode, bør du arbeide for å involvere kunden i prosjektet på daglig basis.

Hvis du arbeider etter en mer Scrum-basert prosess, kan du gjøre kunden til produkteier. Produkteieren har ansvar for å samle forretningsmessige, tekniske og kundemessige krav. Det er avgjørende å få kundens støtte og samarbeid tidlig og ofte for å unngå forsinkelser. Dette gir til syvende og sist et bedre produkt eller en bedre tjeneste for sluttkunden.

Involver en kunde som er langt unna

Hvis kunden din ikke har tid til å bidra i prosjektet eller av andre grunner ikke er engasjert, må du sørge for at noen i teamet representerer kunden. Det er avgjørende at noen tar hensyn til kundens og virksomhetens behov.

Selv om kunden ikke er involvert fra dag til dag, må du sørge for å kommunisere med dem regelmessig og som et minimum involvere dem i all smidig planlegging og alle diskusjoner om prioritering. Samarbeid med dem for å vise fordelene ved å være involvert.

Lag et produktveikart

Vurder å bruke et produktveikart for å kartlegge produktets utvikling. Et produktveikart kommuniserer planen for produktet og visualiserer funksjoner som er planlagt levert. Et veikart er ikke fastlagt i begynnelsen av et prosjekt; det utvikler seg i stedet over tid for å gjenspeile endringer i prioriteringene.

Sørg for at du snakker med sluttbrukerne eller kundene dine

Jeg kan ikke understreke dette nok – du må prøve å teste produktet ditt med sluttbrukere og kunder tidlig og ofte. 

Testing gir så mange fordeler:

• Du kan sikre at produktet oppfyller kundenes behov, det vil si: Er produktet verdifullt for kunden og dermed for virksomheten? Dette hjelper deg med å vurdere samsvaret mellom produkt og marked.
• Du kan innarbeide tilbakemeldinger fra kundene i design- og utviklingsprosessen, noe som gir et bedre sluttprodukt.
• Du kan få innsikt som kan brukes i fremtidig arbeid.

• Den ofte nevnte utfordringen med kundetesting er budsjettet – det kan være dyrt. Her er noen måter å teste på, uansett prosjektbudsjett:

Geriljatesting: Jeg liker denne metoden fordi den er billig og enkel. Tilby deg å kjøpe en ekte eller virtuell kaffe til folk hvis de vil svare på noen spørsmål om designene eller prototypen din. Det er vanskeligere å bestemme hvem som svarer på spørsmålene dine, men noen raske tilbakemeldinger kan være nyttige når du tester utseende og følelse eller enkle interaksjoner.

Spørreundersøkelser: For å samle inn kvantitative data fra et bredere utvalg mennesker kan du lage en spørreundersøkelse for å evaluere designet eller gå dypere inn i kundenes atferd.

Nettsteder som usertesting.com: Du kan laste opp designene dine til et av disse nettstedene og rekruttere personer gjennom dem, ved å bruke kriterier om nødvendig. De vil deretter klikke seg gjennom designene dine, ta opp tankene sine og svare på spørsmål.

Testing ansikt til ansikt: Ja, dette kan være et dyrere alternativ, siden du sannsynligvis må rekruttere personer og betale godtgjørelser. Det kan imidlertid være uvurderlig hvis du tester komplekse interaksjoner eller funksjoner med høy risiko.

Verdi nr. 4: Å reagere på endringer fremfor å følge en plan

Smidige prosjekter og fossefallsprosjekter kunne ikke vært mer forskjellige på dette området. I tradisjonelle programvareutviklingsprosjekter fastsetter du krav, kostnader og tidsrammer på forhånd, mens smidig utvikling åpner for og omfavner endringer.

Endringer er bra! De er ikke onde! Hvor mange prosjektplaner har fungert nøyaktig slik du utformet dem i begynnelsen? Ikke mange, vil jeg tro (jeg har jobbet med prosjekter med dusinvis av gjentakelser av prosjektplanen.)

Planer er et beste estimat på et bestemt tidspunkt, som du kan gjøre mer presist etter hvert som arbeidet skrider frem – de legger imidlertid vanligvis ikke til rette for endringer. Hva skjer hvis kundens behov endres? Hvis virksomheten endrer kurs? Hvis kunden endrer prioriteringer? Hvis funksjonen som er spesifisert, ikke er så enkel å bygge som du trodde?

Smidige arbeidsmetoder omfavner usikkerhet ved å ta i bruk en adaptiv planleggingstilnærming, for eksempel planleggingspoker. Scrum-verdiene tilsier for eksempel at teamet planlegger arbeidet sprint for sprint. Før en tidsavgrenset arbeidsperiode starter, velger smidige team oppgaver fra oppgavelisten og prioriterer dem for utvikling.

Selv om det ofte er et press om å fastsette kostnader, tidsplan og omfang i begynnelsen av et prosjekt, gir det ofte et mye bedre sluttprodukt å være mer realistisk om usikkerhetene du står overfor. Til syvende og sist er dette det du, kunden og interessentene dine bør ønske. 

Her er noen måter å begynne å legge til rette for endringer i prosjektene dine og oppmuntre til større fleksibilitet:

Lag en «lett» plan for å tilfredsstille interessentene

«Men vi trenger en plan!», roper interessentene dine. I stedet for å skremme dem ved å si «Overraskelse, det finnes ingen plan!», kan du lage en enkel leveranseplan som gir dem trygghet i den litt mindre formelle tilnærmingen.

Hvis du driver med smidig prosjektledelse ved hjelp av Scrum-prosesser, har du en liste over prioriterte og estimerte brukerhistorier i backloggen din. Samarbeid med produkteieren for å gruppere disse i foreløpige leveranser, og knytt dem til produktets veikart.

Prøv å ikke planlegge alt, for da undergraver du fordelene ved å bruke Scrum-metodikken. Vis interessentene hva du planlegger i de to eller tre første leveransene, og forklar deretter at omplanlegging er en sentral del av en smidig arbeidsmåte. Du kan kommunisere oppdateringer og ytterligere leveranser etter hvert. Forhåpentligvis vil dette gi dem den nødvendige tilliten!

Introduser teamet gradvis for en sprintbasert tilnærming

Mike Cohn foreslår i artikkelen sin «Å introdusere en smidig prosess i en organisasjon» å hjelpe team med å innføre Scrum gradvis ved å definere et sett med sprinttyper, for eksempel:

• Prototyping
• Innhenting av krav
• Analyse og design
• Implementering
• Stabilisering

Her beskriver han hvordan dette kan være til hjelp:

«Vi samarbeider deretter med teamene for å definere artefaktene som skal komme ut av hver sprinttype. Bruk av sprinttyper tilfører akkurat nok formalisering til at teamene tydeligere kan se veien gjennom prosjektet. Etter hvert som teamene blir flinkere til å arbeide uformelt i den smidige prosessen, legger de gradvis bort konseptet med sprinttyper.»

Dette er en annen måte å utforme leveranseplanen på. Hvis du tildeler en «type» til hver sprint, kan interessentene se hvordan planen tar form, samtidig som du slipper å garantere funksjoner. Teamet ditt får også en bedre forståelse av hva de skal arbeide med.

Gå bort fra faste tidsfrister

Å gi teamet ditt en tidsfrist eller kommunisere en fast dato til kunden er strategier som enten er dømt til å mislykkes eller i det minste vil føre til stress underveis. Det er avgjørende å bygge tillit mellom deg og teamet ditt, og mellom deg og kunden eller interessenten, for å bevise at du vil levere – og levere verdi – til sluttkunden.

Husk at du prøver å redusere behovet for flere kontrollpunkter og godkjenninger. Å innføre tidsfrister i prosjektet vil ikke hjelpe deg med å nå dette målet. Det er heller ikke bra å puste teamet i nakken og mase på dem om arbeidet de «lovet» å levere.

Som nevnt ovenfor kan veikart og leveranseplaner være gode virkemidler for å bevege seg bort fra en tilnærming med faste datoer. Når interessentene får en forståelse av hva som vil bli levert i nær fremtid, kan det forsikre dem om at det finnes en plan.

Bruk et omfang basert på tid og materiell

Hvis du har et fastprisomfang med faste leveranser, er det vanskelig å levere på en mer smidig måte. Du kan absolutt ta i bruk noen av teknikkene jeg allerede har omtalt, for eksempel å legge til rette for et mer samarbeidsorientert team. Men du vil være begrenset når det gjelder hvor mye du kan svare på og tilpasse deg endringer, la teamet bestemme hva de skal arbeide med eller bruke en mer kundesentrert tilnærming.

Samarbeid med det interne teamet og kunden for å etablere et omfang basert på tid og materiell – det vil si at kunden betaler for et team i stedet for faste leveranser. Til å begynne med kan kunder bli nervøse hvis de ikke vet nøyaktig hva de får.

For å redusere denne bekymringen kan du inkludere en backlogg med aktiviteter eller oppgaver som kan vurderes for lansering, som en del av omfanget. Spesifiser i kontrakten at teamet skal planlegge backloggen på nytt og prioritere den med innspill fra kunden etter hvert som prosjektet utvikler seg (selv om dere kanskje ikke behandler alle punktene).

For å håndtere skiftende prioriteringer og leveranser kan team bruke programvare for smidig styring til kontinuerlig å prioritere backloggen på nytt, og samarbeidsverktøy for programvareutvikling til å koordinere samarbeid på tvers av funksjoner.

På denne måten binder du deg ikke til et fast omfang, samtidig som kunden får færre bekymringer rundt hvordan sluttproduktet vil se ut.

Fortsett å følge fremdriften

Det å følge med på og visualisere fremdriften forsvinner ikke selv om det ikke finnes en formell prosjektplan. Når fremdriften er synlig for teamet og interessentene, sikrer det ikke bare at du ikke mister potensielle hindringer og flaskehalser av syne, men holder også interessentene oppdatert. 

Et Kanban-lignende WIP-brett eller smidige oversikter fungerer godt for smidige prosjekter. Når du har visualisert prosessen, kan du begynne å kartlegge støttende oppgaver og aktiviteter. Dette hjelper deg med å oppdage flaskehalser som du kan fjerne for å legge til rette for raskere levering til kunden.

Kritikk av Det smidige manifestet

Som enhver annen prosjektstyringsmetodikk er smidig ikke perfekt. Kritikere påpeker at forfatterne av Det smidige manifestet var en homogen gruppe som kanskje ikke tok alternative tilnærminger til arbeid i betraktning, for eksempel fordelene ved å jobbe eksternt eller hvordan man kan bruke smidige metoder utenfor programvareutvikling.

Tatt for langt kan smidig bety beslutninger ved komité, noe som senker arbeidstempoet. Mangel på dokumentasjon kan ende opp med å skade prosjektleveransen, særlig i et eksternt arbeidsmiljø der asynkron kommunikasjon er avgjørende.

Hvis du bestemmer deg for å bruke smidige metoder i prosjektene dine, bør du sørge for å konsultere de smidige verdiene og prinsippene. De er en nyttig veiledning for å holde de verste tendensene ved smidig arbeid i sjakk.

Les mer om debatten om hvorvidt smidig er en metodikk eller en tankegang her.

Smidighet, ikke smidig metodikk

En siste tanke er: Husk retrospektivet! Som manifestet sier:

Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt, og justerer deretter atferden sin.

Uansett hvilken type prosess du bruker, er retrospektivet en effektiv måte å undersøke hvordan dere arbeider på og optimalisere for å lykkes. Sørg for at du inkluderer prosjektretrospektiver regelmessig i prosessen du bruker – og at du har en mekanisme for å innarbeide det dere lærer! PS: Det er viktig å få de stille teammedlemmene dine til å snakke i retrospektivene også – slik gjør du det.

Hva skjer videre?

Hvis du vil lære mer om hvordan du implementerer smidige arbeidsmetoder og lærer av de beste prosjektlederne i bransjen, kan du se nærmere på DPMs medlemskapsalternativer.