Det viktiga när man bygger ett staket är att det är oftast inte är själva staketet som ska vara agilt.
Staketet ska byggas med kvalitet. Det agila är att om ett träd är i vägen så kan man bygga runt det och anpassa det till hur det ser ut i verkligheten och få det att funka.
Tänk dig att du har som uppgift att bygga ett staket. Självklart måste du anpassa idéerna och ritningen (om det finns någon) till verkligheten och bygga smart!
Sen gäller det att ha kontroll på alla regler och lagar som gäller. Får du bygga ett 5 meter högt plank? Kan du bygga staketet utanför din tomtgräns? Eller kan du påbörja bygget utan att veta exakt var tomtgränsen går och utan att informera dina grannar?
Ni märker, det finns massor av synvinklar och synpunkter att ta ställning till även med detta lilla projekt!
Innan man kan påbörja en kontinuerlig och iterativ utveckling, så måste det finnas en initial backlog. Arbetet med att skapa den första versionen av produktbackloggen bör göras på ett mer klassiskt, organiserat och strukturerat sätt. Klassisk kravingenjörskap och verksamhetsanalys har ett stort antal verktyg och tekniker som hjälper till och gör arbetet med den initiala backloggen snabbare, smidigare, mer effektivt, mer organiserat och strukturerat. Smartare helt enkelt.
Syftet med Produktbackloggen (PB) är att beskriva ett framtida önskat läge för produkten och dess kontext. Syftet med produkten är att generera värde för ett antal identifierade och prioriterade intressenter, vilket oftast inte är alla de som initialt identifierats.
En PB utan ett tydligt och mätbart produktmål är inte OK. Med ett produktmål så vet man varför man gör det man gör och vart man är på väg, vilket innebär att chansen att man lyckas komma dit utan ett tydligt och mätbart produktmål är minimal! Varje item (PBI) på backloggen ska kunna relatera till och passa in i en konsekvenskedja och ett logiskt resonemang kring hur den gör att man genom att utföra denna PBI kommer närmare det definierade produktmålet.
Genom klassiskt Requirements Engineering/Business Analysis (RE/BA) kan vi lägga grunden för ett Smart Agile iterativt fortsatt arbete, kartlägga kontexten och genomföra en intressentanalys.
Genom analys och erfarenhet kan vi identifiera – eller åtminstone börja misstänka – att en del av kravmängden kan ha stor påverkan på projektet. Då bör vi agera för att upptäcka och provocera fram krav inom dessa områden för att kunna analysera dem, bryta ned dem och förfina dem redan innan det iterativa arbetet påbörjas. Exempel på stor påverkan är krav och förändringar som påverkar arkitekturen, infrastrukturella val, val av hårdvara eller helt enkelt möjligheten att skapa en smart lösning.
För att en lösning ska vara smart måste man lösa det riktiga problemet som var upphovet till projektet. Det problem som lyftes av de tongivande intressenterna med avsikt att förändra nuläget och har kapaciteten att betala för lösningen. Många vill ändra på verkligheten men utan pengar för att betala för kalaset kommer ingen utveckling och förändring att ske. Den eller de som betalar orkestern bestämmer vad som ska spelas. ("the person who pays the piper calls the tune").
"Smart Agile identifierar snabbt den del av kravmängden som har liten påverkan och som kan förfinas under ett senare skede av resans gång."
Denna typ av tydlighet och struktur mellan olika PBI:er på olika nivåer och grader av abstraktion, som är mer eller mindre nedbrutna men alltid specifika och tydliga på sin respektive abstraktionsnivå, är en RE/BA:s nationalsport! Det är viktigt att skilja på PBI:er med stor påverkan och de som kan lämnas till att upptäckas och förfinas iterativt under resans gång.
Precis som när vi väntar med att såga till alla staketbrädorna till vi behöver dem så att de kan anpassas perfekt till hur verkligheten verkligen är. Tomtgränsen ändras dock inte och den måste vi känna till från start, så att vi inte bygger staketet på fel plats!
1. Vad behöver vi VETA innan vi kan starta första sprinten?
Vad är Definition of Ready för backloggen som helhet?
Vilka kunskapsenheter måste vi ha kontroll över under de kommande sprintarna?
2. Vilken representation bör det identifierade kunskapsbehovet ha?
Hur ska vi representera och fånga kunskapen så att alla förstår men så att ett komplext problem verkligen kan beskrivas korrekt?
Här kan klassisk RE/BA tillföra enorma fördelar i form av tydliga artefakter som finns för att fånga just det man har identifierat är viktigt i projektet.
Om exempelvis vi ska påverka flödet för betalningar och hur fakturor kommer att hanteras är det lätt att identifiera behovet av både flera aktivitetsdiagram som fångar flödesbeskrivningar på olika nivåer och minst en tillståndmaskin för att fånga de olika tillstånden som fakturan kan ha och hur systemets tillstånd ändras som helhet av olika betalningsalternativ. Genom att skapa en första draft av de identifierade kunskapsrepresentationerna kan sedan varje sprint iterera kring denna första struktur och kunskapen förbättras och förfinas i varje sprint.
Att varje team ska försöka hitta på ett eget "språk" för att beskriva komplexa saker är ganska befängt! Att inte använda diagram och modeller som har en tydlig syntax och semantik (dvs ett visuellt språk!), är inte smart. Och är det inte smart, så är det inte Smart Agile!
3. Vilka förutfattade meningar (assumptions) har vi?
Vad är det vi tror är sant och som kan få oanade konsekvenser om det visar sig vara falskt?
Vi behöver analysera och validera assumptions eftersom de utgör risker för projektet. OM vi fortfarande inte vet säkert, är det OK att starta projektet trots att det kan leda till högre kostnad och kanske till och med ett misslyckat projekt?
Här kan klassisk RE/BA tillföra en översiktlig risklista med identifierade åtgärder som sedan iterativt hanteras i varje sprint.
4. Vad är kontexten och vad är omfattningen på projektet?
Om man inte initialt vet hur världen ska se ut när projektet är klart, är chansen stor att projektet aldrig går i hamn. Det är inte samma sak som att man låser sig fast vid den ursprungliga versionen av kontexten och scopet, men att man lägger till saker till, tar bort saker från eller ändrar saker mot en baseline!
Här kan klassisk RE/BA tillföra tydlighet genom kontextmodeller och översikter på rätt nivå. Tydlighet och detaljer endast på de områden som har stor risk eller farliga assumptions.
5. Vilka är de riktiga intressenterna?
Sträva efter att skapa en komplett karta över alla identifierade intressenterna. Denna kan användas för att planera och anpassa olika typer av möten och workshops för olika intressenter med olika behov och förutsättningar.
Här kan klassisk RE/BA tillföra tydlighet genom att skapa en intressentkarta och intressenttabell för att tydliggöra olika alternativa insamlingstekniker anpassade för respektive intressents behov och egenskaper. Vid varje sprint-genomgång har produktägaren ansvaret att involvera alla de intressenter som representerar de domänerna som påverkas av förändringen i sprinten. Om den agila utvecklingen ger inbrytningar i nya områden på ett smart agilt sätt för att maximera nyttan, så uppdateras givetvis intressentmatrisen och intressentkartan så att den återspeglar den verkliga representationen i projektet.
Att bara prata "kund" och "användare" är så generaliserat att det bara är dumhet.
Om man inte identifierat en intressent för ett område så kommer inte heller krav eller återkoppling ske från detta område och produkten löper stor risk att misslyckas att skapa nytta för de som borde representerats av denna intressent.
6. Vilka begränsningar finns det och är vi säkra på att de inte är falska?
Att utveckla en produkt och anpassa lösningen till gällande begränsningar som senare inte visar sig vara hårda begränsningar utan snarare "rekommendationer" från personer som försöker hjälpa till genom att ge förslag på lösningar, är WASTE! Det gäller att tidigt kartlägg alla begränsningar och syna dem så de inte är falska!
Att inte tillämpa den bästa möjliga lösningen är stupid agile! Och att inte kartlägga och analysera alla påstådda begränsningarna på projektet är bara dumt. Att utmana och ha fullständig kontroll på all ingående begränsningar är en förutsättning för smart agile!
Nedan hittar du min Pdf för bättre kommunikation inspirerad av e-sporten. Den innehåller 11 punkter som du kan ta med dig in i ditt projekt.