Agile ødelægger dit produkt

Jakten på små, hurtige og autonome hold skaber fragmenterede, forvirrende og usammenhængende oplevelser.

Illustration af Joan LeMay

Problemer i paradis

I mit arbejde som produktcoach og konsulent er det første spørgsmål, som jeg normalt bliver stillet, ”Hvordan kan vi være mere [berømt teknologiselskab X]?” Dette spørgsmål er blevet besvaret utallige gange i veldokumenterede casestudier, f.eks. Amazons "to-pizzateam", Spotifys "trup, stammer, kapitler og guild" -model, og Facebooks siden pensionerede "bevæge sig hurtigt og bryde ting" -mantraet. Taget som en helhed, tegner disse historier et overbevisende billede af, hvordan produktudvikling ser ud i bedste-i-klassen digitale virksomheder: små, autonome teams, der arbejder i lynhastighed.

Ideen om små, autonome teams - kernen i mange agile metodologier, der bruges af moderne teknologiselskaber - tilbyder et tiltalende alternativ til de bureaukratiske, kommando- og kontrolstrukturer, der stadig dominerer erhvervslivet. Og alligevel medfører denne tilgang også en betydelig risiko: at de produkter, der er skabt af små, autonome teams, vil føles som et frakoblet sæt små, autonome funktioner.

Afsnittet

For eksempler fra det virkelige verden på dette antimønster behøver man ikke se længere end flagskibsprodukterne lavet af nogle af disse meget ”bedst i klassen” digitale virksomheder. (Se afsnittet "Udforsk" på Facebook's hjemmeside for et særligt galende eksempel, eller prøv at navigere problemfrit mellem produkterne, der engang var kendt som "Google Apps.") Når digitale produkter bliver større og mere komplekse, er det vigtigere end nogensinde vi ser ud over individuelle funktioner og tænker over, hvordan disse funktioner kombineres for at skabe sømløse, sammenhængende oplevelser. Og at gøre det vil kræve anerkendelse af, at netop de afhængigheder, der bremser arbejdet i små, autonome hold, undertiden kan være gode for de kunder, som disse teams i sidste ende tjener.

Driftshastighed vs. kundebehov

Agile-bevægelsens principper og praksis har vist sig at være særdeles overbevisende for organisationer, der ønsker at holde trit med en verden, der hurtigt forandrer sig. Og uden tvivl vil sandsynligvis øge hastigheden, hvormed hvert hold kan frigive forbedringer af det bestemte stykke af det produkt, som det er ansvarligt for, at opdele store og indbyrdes afhængige teams i små autonome teams.

Problemet, viser det sig, er, at den interne friktion, der fjernes af små autonome teams, stadig mærkes af eksterne kunder. En artikel fra Harvard Business Review fra 2013 kaldet "Sandheden om kundeoplevelse" er et kritisk punkt, der ofte går tabt i samtalen om små, autonome teams: Fra en kundes perspektiv er den vigtigste del af et produkt ofte ikke dets individuelle funktioner, men snarere hvordan disse funktioner mødes for at skabe en problemfri og sammenhængende oplevelse.

Omfang, prioritering og udførelse af sådant arbejde involverer nødvendigvis en høj grad af koordinering mellem og på tværs af hold - og at koordination tager tid og kræfter. For organisationer, der måler hvert holds succes ud fra den operationelle hastighed i deres arbejde, kan dette skabe en blændende forbindelse mellem det arbejde, der er mest vigtigt for kunderne, og det arbejde, som hvert lille autonome team sandsynligvis vil prioritere. Dette rejser i sidste ende spørgsmålet: er autonomi virkelig det mål, vi ønsker at arbejde hen imod?

At sætte det sammen igen

At opdele store produkter i små, håndterbare stykker er ingen let opgave - men det er meget vanskeligere at sætte disse stykker sammen igen. Mange skalerede agile rammer er delvis designet til at afbalancere småskala autonomi med koordinering i store billeder. Men det vigtigste skridt hen imod at holde små teams forbundet og koordineret, som jeg opdagede, mens jeg undersøgte min seneste bog Agile for Everybody, handler mindre om org-diagrammer og rammer end en af ​​samarbejde og kultur. Som Spotify VP for vækst og marketing fortalte Mayur Gupta mig:

Når folk refererer til Spotify-modellen, taler de normalt om laug, stammer og kapitler. Men det er bare ritualer. Jeg tror ikke, at du nedbryder barrierer ved at ændre rapporteringslinjer. Når du har et virkelig tværfunktionelt team, bliver rapporteringslinjer irrelevante…. Når du fortsætter gennem dit liv og din karriere, er du klar over, at det, der virkelig driver disse ændringer, er kulturen.

Med andre ord, blot at tegne dit org-diagram for at følge “The Spotify Model” (eller en hvilken som helst model for den sags skyld) genskaber ikke faktisk den kultur, der har ført til at Spotify - eller nogen af ​​disse “bedst i klassen” virksomheder - har opnået dets største gevinster. I stedet for at følge en enkelt klar til at vedtage operationel model fulgte næsten enhver succeshistorie, jeg hørte, når jeg forskede Agile for Everybody, på tre højt niveau vejledende principper:

  • Start med kunder og deres behov, ikke med et virksomhedsorienteret mål
  • Samarbejde tidligt og ofte på tværs af flere hold (uanset hvordan disse hold formelt er organiseret) for at identificere store muligheder såvel som taktiske afhængigheder
  • Planlægning af usikkerhed om faktisk at inkorporere ny information, efterhånden som et projekt skrider frem

Hold og organisationer, der virkelig havde omfavnet disse principper, var ikke kun i stand til at opdele store udfordringer i mindre stykker, men også dynamisk overveje, hvordan disse stykker passer sammen. Deres mål var ikke at opnå driftshastighed eller ren autonomi, men snarere at arbejde sammen om at løse de største og vigtigste problemer, som deres kunder står overfor.

En sti frem: Fra sølvkugler til elastiske organisationer

Titlen på denne artikel er beregnet til at være provokerende, men den taler også til en vigtig sandhed: enhver organisation, der er for fokuseret på operationelle, virksomhedsorienterede mål som hastighed, autonomi eller "at følge reglerne i en agile ramme", kører risikoen for at trække længere væk fra sine kunder. Mens stræben efter at fjerne intern friktion er værdig, skal vi starte med at forstå den eksterne friktion, som vores kunder oplever, og arbejde utrætteligt (og samarbejdsvilligt) for at minimere denne friktion.

Her er et par skridt, som din organisation kan tage for at undgå at forfølge hastighed og autonomi på bekostning af kundeoplevelse:

  • Modstå trangen til at måle fremskridt strengt med driftshastighed (dvs. frigivelsesfrekvens eller kodelinjer). Tænk i stedet på hastighed ud fra din kundes synspunkt - hjælper du dem med at nå deres mål hurtigt og nemt? Eller bremser du dem ned med komplekse, fragmenterede oplevelser?
  • Sørg for, at individuelle incitamenter og teamincitamenter ikke er så lokaliserede, at de implicit afskrækker at tage tid og kræfter på at arbejde på tværs af hold.
  • Adskiller klart "gode afhængigheder" (dvs. muligheder for at kombinere indsats eller funktioner i en problemfri oplevelse for kunderne) fra "dårlige afhængigheder" (dvs. afhængigheder, der unødigt bremser en organisations evne til at imødekomme kundernes behov). Vær særlig opmærksom på at søge situationer, hvor flere hold udfører dobbeltarbejde eller overflødigt arbejde, et almindeligt problem blandt organisationer, der har forsøgt at eliminere afhængigheder og fremme autonomi.
  • Vær opmærksom på opsamling af alle menuer og lister (som Facebook's "Udforsk"), der kan blive en dumpingplads for frakoblede funktioner. Husk, at hver nye vare, du lægger foran dine kunder, koster deres tid og opmærksomhed.
  • Ud over "Agility" er de mest succesrige organisationer virkelig elastiske; det vil sige, at de hurtigt kan spinde nye organisationsmønstre og strukturer uden en massiv, formel reorg. En øjeblikkelig måde at opbygge denne elasticitet er at danne midlertidige "SWAT Teams" med repræsentanter fra flere niveauer, funktioner og funktionsbaserede teams, der eksplicit har til opgave at se, hvordan arbejdet i disse individuelle teams kan kombineres for at skabe en bedre kundeoplevelse. Som en ekstra bonus, prøv at tildele et sådant team opgaven med at genopfinde hele produktet helt fra bunden uanset det eksisterende funktionssæt. (Jeg skriver mere om elastiske organisationer og "SWAT Team" -tilgangen i en fremtidig artikel.)

For mere information om dette emne håber jeg, at du tjekker min nye bog Agile for Everybody. Som altid, er du velkommen til at komme i kontakt med mig direkte på [email protected], hvis du har nogle tanker, tip eller forslag!