Det agila staketet - Smart agile

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!

info StefanInnan du bygger det så måste du skapa tydlighet med vilket syfte som staketet har, så att alla involverade förstår vad du menar med "vi ska bygga ett staket". Är det till för att skydda mot insyn, stoppa husdjuren från att smita eller är det bara en markering av tomtgränsen?
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?

  • Vilka verktyg tror du att du kommer att behöva för att bygga staketet?
  • Och hur mycket material krävs?
  • Vet du hur högt och långt du har planerat att staketet ska vara?
  • Har du kollat att bygghandeln har denna mängd bräder och plintar etc.?
  • Behöver du ansöka om bygglov?
  • Har du koll på väderleken för när du planerat att utföra bygget?
  • Har du en snickare bokad eller får du hjälp av en kompis? Funkar tiderna med dem?
  • Hur ser marken ut, är det ojämnt och mycket sten som kräver andra typer av verktyg?
  • Hur lång tid brukar ett normalt staketbygge ta?
  • Hur många meter bygger man per timma?
  • Ska man måla planken innan de spikas upp?
  • Ska vi spika eller skruva? Har vi koll på vilken typ av skruv eller spik som används?
  • Hur länge har jag tänkt att staketet ska hålla sig? Är det ett tillfälligt staket som ska ersättas så småningom av en stenmur eller är det tänkt att det ska stå där för evigt?
  • Vilken budget har vi?
  • Vilken typ av trä ska vi köpa och vilken sortering?
  • Finns det alternativ till ett staket i trä?
  • Ska vi sätta en tät häck istället?
  • Är vi verkligen säkra på vad vi vill ha och hur världen ska se ut när staketet är klart?

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.

HUR SKAPAS DEN FÖRSTA VERSIONEN AV PRODUKTBACKLOGGEN?

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!

VILKA FRÅGOR BEHÖVER VI STÄLLA FÖR ATT SKAPA EN TILLRÄCKLIGT BRA FÖRSTA PRODUKTBACKLOGG?

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?

  • Var går tomtgränsen? Vilka verktyg kommer vi att behöva när vi förankrar stolparna? Vika lagar gäller med avseende på höjd och avstånd och material etc.. när man bygger ett staket? Vilken representation bör det identifierade kunskapsbehovet ha?

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!

  • På vilket format ska vi rita upp staketet på ritningen för att det ska godkännas av kommunen? Kan vi ta foton eller göra en ritning i ett 3D program?

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.

  • Tror vi att marken är likadan för hela sträckningen av staketet? Tror vi att kommunen accepterar att vi målar det i regnbågens färger för att hylla Pride året runt?

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.

  • Vilka grannar kommer att beröras av staketet? Hur ser flödet av gångtrafik, cyklar och bilar ut, kommer staketet påverka synen för trafikanterna och utgöra en trafikfara? Finns det vattenledningar precis där vi planerat att gräva? Kan vi kapa trädet som står i vägen för vårt staket där vi vill ha det?

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.

  • Vilka är intresserade av mitt projekt? Vilka får nytta av det? Vilka vill inte ha det alls? Vilka kommer kräva att jag har dokumenterat det eller byggt det enligt vissa regler? Vem har åsikt om färg- och materialval?

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!

  • Måste vi bygga staketet med virket från förra årets nedrivna fasad? Måste vi återvända det även om det ser ut som att det är ganska dåligt virke? Är det ett riktigt krav eller är det ett förslag? Vi måste veta för att kunna jobba smart!
Använd klassisk kravingenjörskap och verksamhetsanalys för att bygga den första versionen av produktbackloggen! Var smart agile helt enkelt!

 

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. 

11 punkter för bättre kommunikation - Mustasch och Hängslen

Alla blogginlägg

Vi rekommenderar också