Agile Bullshit

av | okt 8, 2019 | AGILE

Varför är det amerikanska försvarsdepartementet på krigsstigen mot vad de kallar Agile Bullshit? Och hur ska de bekämpa det? Häng med och gräv i det hela!

Under hösten 2018 släppte en kommitté under det amerikanska försvarsdepartementet ett dokument med den talande rubriken ”Detecting Agile BS”. Dokumentets syfte är att belysa och hjälpa till att minimera det som börjar bli ganska vanligt: mjukvaruutveckling som påstår sig vara agil, men som inte är det.

Dokumentet tar förstås sitt avstamp i mjukvaruutveckling inom det egna departementet och därmed pratar man en del om projekt och program, men innehållet är förstås relevant även om man inte byggt upp sin utveckling runt dessa begrepp. Större delen av innehållet är egentligen bara ett frågebatteri med relevanta frågor att ställa till både utvecklingsorganisationen och till deras kunder. Liknande frågesamlingar går att hitta lite varstans på internet, men det som gör att vi tar upp just detta dokument just här är att det dels är roligt att det är en så bitsk text i ett ämne vi älskar, men också för att frågorna som definieras är väldigt konkreta och bra.

Även om dokumentet inte är särskilt långt, kommer här en sammanfattning på svenska. Håll i dig, för nu tar vi av silkesvantarna.

Sammanfattning – vad är Agile Bullshit?

”Agile” är, enligt författarna, ett buzzword inom dagens mjukvaruutveckling, där många hävdar sig arbeta agilt utan att ha implementerat de centrala delarna i ett agilt arbetssätt. Syftet med dokumentet är att ge chefer och förvärvsexperter handfasta verktyg och vägledning till att tidigt kunna avgöra om utvecklingsprojekt faktiskt arbetar agilt eller om det egentligen bara är vattenfallsprocesser med trendiga namn på sina möten, s.k. ”agile-scrum-fall” (det vill säga Agile Bullshit).

Redan tidigt i dokumentet definieras några bra och mer generella varningsflaggor som signalerar om ett team inte är så agilt som man tror:

  • Ingen i utvecklingsteamet interagerar med användarna när systemet används.
    • Här menas de faktiska användarna av den faktiska koden, skriven av den faktiska utvecklaren
  • Utvecklingsteamet har inte tillgång till kontinuerlig feedback (t ex buggrapporter eller åsikter) från användarna. Att prata med en användare en gång i början av utvecklingen räknas inte.
  • Att möta kraven räknas som viktigare än att få ut något till marknaden så fort som möjligt.

Nu kommer vi till själva kärnan. För att kunna göra ett utlåtande om graden av agilitet, definierar man nämligen ett antal konkreta kontrollfrågor att ställa till de olika delarna av organisationen, här grupperat på funktion:

Frågor att ställa till utvecklingsteamet

  • Hur testar ni er kod?
    • Fel svar: ”vi har en testorganisation”.
    • Fördjupande fråga: vilka verktyg använder ni för enhetstester, regressionstester, funktionstester och säkerhets-scanning?
  • Hur automatiserade är era utvecklings-, test-, säkerhets- och deployment-pipelines?
    • Fördjupande fråga: Vilka verktyg använder ni för Continuous Integration (CI), Continuous Deployment (CD), regressionstester, dokumentation; är er infrastruktur definierad genom kod?
  • Vilka är era användare och hur interagerar ni med dem?
    • Fördjupande frågor: Vilka mekanismer använder ni för att få direkt feedback från era användare? Vilka verktyg använder ni för att rapportera och hålla reda på buggar? Hur informerar ni användare att ni ser över deras rapporterade problem eller att de blivit lösta
  • Hur långa är era releasecykler (nu och framåt)?
    • Fördjupande frågor: Vilka mjukvaruplattformar stödjer ni? Använder ni containerteknologi? Vilka configuration management-verktyg använder ni?

Frågor att ställa till ledare

  • Vilka mätetal finns på chefsnivå för utveckling och drift?
    • Hur används de för att informera om prioriteringar och att upptäcka problem? Hur ofta tittar ni på och agerar på dessa mätetal?
  • Vad har ni lärt de senaste tre sprintcyklerna och vad har ni gjort åt det?
    • Fel svar: ”Vad är en sprintcykel?”, ”Vi väntar på att få godkännande på förändringarna från ledningen”.
  • Vilka är användarna som ni levererar värde till varje sprintcykel? Kan vi få prata med dem?

Frågor att ställa till kunder och användare

  • Hur kommunicerar ni med utvecklarna?
    • Har de observerat ert arbete och ställt frågor kring det för att få en djup förståelse om era behov?
    • När satt ni senast ned tillsammans med utvecklarna och diskuterade framtida utvecklingsbehov?
  • Hur går det till om ni vill skicka in förfrågningar eller förslag på nya funktioner?
    • Hur går det till om ni vill rapportera en bugg?
    • Vilken typ av feedback får ni från sådana förfrågningar eller rapporter?
    • Får ni någonsin förfrågningar om att testa prototyper av nya funktioner?
  • Hur lång tid tar det för en efterfrågad funktion att dyka upp i applikationen?

Frågor att ställa till programledarna

(Här bör alla svar vara “ja”)

  • Levererar teamen fungerande mjukvara till åtminstone en del av de riktiga användarna i varje iteration (inklusive den första) för att sedan ta emot feedback från dem?
  • Finns produktens syfte och strategiska mål nedtecknade?
    • Är alla teammedlemmar införstådda med dessa?
    • Kan var och en se hur deras individuella insats bidrar till syftet och målet?
  • Används feedback från användarna till att skapa faktiska arbetsuppgifter inom ramen för sprintarna?
    • Görs detta inom en månads tid?
  • Har teamen mandat att ändra på kraven baserat på feedback från användarna?
  • Har teamen mandat att ändra på sina processer baserat på vad de lär sig över tid?
  • Är projektets hela ekosystem att betrakta som agilt?
    • (Agila utvecklingsteam följt av linjära och byråkratiska releaseprocesser räknas inte)

Kommentar

Det är ganska svårt att kunna svara rätt på alla de här frågorna och relativt få organisationer skulle passera genom nålsögat. Men – utifrån våra egna förutsättningar – det kanske är OK ändå? Dokumentet vill snarast få de som envist och missvisande hävdar att man jobbar agilt fullt ut, att inse att ett visst mått av ödmjukhet inte nödvändigtvis behöver vara dåligt. Nej, vi kan inte svara rätt på alla frågor, men vi är medvetna om vad vi behöver utveckla och vi gör det!

Här handlar det om att göra avvägningar och prioriteringar; vilka av dessa områden är viktiga för oss att förbättra i första hand och vilka kan vänta lite?

Även om frågorna är tuffa, så hjälper de till att konkretisera mycket av det som (trots t ex Scrum och DevOps tydlighet) fortfarande inte är helt självklara vardagsbeteenden för de flesta av oss. Men vi kommer inte att kunna åtgärda alla på en gång. Välj tre stycken och börja där.

Vi på Onbird kan förstås hjälpa till, om du kört fast och behöver komma vidare i dina Agila- eller DevOps-processer, Agile Bullshit eller ej. Välkommen att höra av dig på hello@onbird.se!

Dokumentet som denna post bygger på hittar du i sin helhet här.

Intro till agila arbetssätt

Endagskurs för alla verksamhetsroller. Kursen Intro till agila arbetssätt kombinerar hälften teori och hälften simuleringspraktik för att ge en kunskapsgrund som du nyttjar och repeterar praktiskt redan samma dag.

Författare
Martin Comstedt

Allt för ofta gör vi saker utan att vara hela säkra på varför. Den magiska frågan är: "vilket problem löser vi genom att göra den här förändringen?". Genom att faktiskt svara på den så tvingas vi tänka igenom massor av saker som annars tenderar att komma tillbaka som oklarheter senare. Min starkaste drivkraft är att lösa utmaningar inom organisationer, men jag ser agnostiskt på vägen dit. Ramverk och definierade synsätt är ofta bra vägledning, men får inte bli målet. Läs mer om Martin

Kostnadsfri rådgivning

Vill du prata med oss för en kostnadsfri rådgivningssession kring era behov/utmaningar? Kontakta oss genom formuläret nedan!

Share This