I våras byggde vi trall och terrass här hemma. Under arbetes gång blev det uppenbart för mig hur mycket likhet detta bygge hade med agil mjukvaruutveckling. Flera koncept som jag precis läst om under min SAFe-certifiering tillämpades i praktiken.

Portföljnivå (enligt SAFe)

Vi bestämde oss tidigt för en implementationsstrategi med tydligt mål, och vår vision var tydlig.

• Strategic Themes / Vision - Vi hade tydligt klart för oss vad vi ville åstadkomma och vilka behov som vi ville fylla - en fin, mysig och funktionell utemiljö.
• Backloggen - Allt hade en direkt koppling till vår vision - en trall på kortsidan, en terrass på baksidan, pergola, lite odlingslådor, förvaring under terrassen, eventuell stenläggning och staket. El och vatten skulle också dras ut via ett fönster som skulle pluggas igen. Prioritet och en tågordning på vad som skulle göras lades också ut. Vi hade en grov estimering - estimeringen gjordes av utvecklingsteamet (hantverkarna) för att få en uppskattning när vissa saker behövde beställas eller göras (av andra) och om scopet var rimligt eller om vi redan nu behövde omprioritera.
• Guardrails - Tidshorisont - klart före semestern.
• Guardrails - Budget - Eftersom vi inte visste exakt vad vi ville få gjort och hur mycket jobb det innebar (för många okända variabler) så körde vi på löpande räkning. Team 1 bestod av mig (produktägare) och två hantverkare. Team 2 bestod av familjen - två vuxna och tre barn. För el och VVS tog vi in specialistkunskap (shared services).

Lessons learned - Revidera arbetssätt (ännu tidigare och oftare)

Diskussion kring leverans av material kontra egen transport och inköp kom tidigt på tal. Vi bestämde då att hantverkarna skulle köpa in och själva transportera materialet. Detta motiverades med att man då skulle minska svinnet - dåliga brädor och dylikt. I teorin var ju detta helt rätt men eftersom hantverkarna inte hade de rätta förutsättningarna för att transportera de stora mängder som behövdes så blev kostnaden ganska snabbt oproportionerligt stor då kostnaden för släp och timmar översteg en potentiell risk för större svinn (och kostnad associerad till det). 

Vi anpassade vårt arbetssätt till detta faktum och överlät ansvaret för materialinköp och transporter till mig. Resultatet blev:

• Hantverkarna kunde koncentrera sig på det de borde
• Kostnaden för materialtransporterna belastade min fritid och visade sig inte explicit på fakturor
• Större åtgång av material pga svinn då inköparen inte var lika kompetent (dock kunde stor del av resterna återanvändas till mindre viktiga små byggen).

Skulle jag göra om det så skulle jag säkert försöka mig på ännu en annan modell som inte krävde vare sig min eller hantverkarnas tid.

Grundarbetet

 Urgrävning, plintar, bärlinor et cetera byggdes allteftersom de olika delarna var klara - trall, terrass och marksten. Denna del av arbetet visade sig vara mycket tidskrävande, något som varit svårt att förutsäga då varken berg eller mängden jord som behövde tas bort vad känt i början av projektet.

Ha också förståelse för att det finns behov av att bygga och köpa in saker som möjliggör och förenklar det övriga arbetet (enablers). Exempel på detta var inköp ”Big bag-påsar”, sågställning, mallar och byggställningar.

Lessons learned - tänk till och gör även grundarbetet på ett transparent sätt

• Odlingslådor var planerade från början, men trots det blev slutförandet och dessa "detaljer" onödigt svåra pga att man inte tänkt till kring detta vid grundarbetet.
• Höjden på terrassen utformades utefter trallen på kortsidan och inte förvaring, trappor eller placering av den tidigare nedtagna terrassen. Resultatet blev trots allt bra, men det hade kunnat bli bättre.

Se till att grundarbetet och arkitekturen inte görs i en blackbox - det är inte bara en domän för specialister. Låt dem förklara sina beslut och se till att detta jobb görs lika transparent som allt annat.

Implementationsstrategi

• Inkrementell leverans med värde (lean-agile mindset ”optimize sustainable value delivery”) - backloggen var prioriterad utefter att vi kunde börja nyttja saker efterhand de var klara - trall, terrass, pergola, staket.
• Experimentera (spike) - vi gjorde prototyper och testade oss fram med bl a ljussättning, pergolan, staketet och odlingslådor.
• Lämna beslut öppna så länge det går (preserve options) - vilket möjliggjordes av en tät dialog.
• En levande backlogg- vi prioriterade om, tog bort saker och lade till saker till backloggen.
• Mer eller mindre dagliga genomgångar och synkronisering (daily scrum/reviews) - detta arbetssätt underlättade experimenterandet, beslut och kommunikation.
• Synkronisering och genomgång av leverabler över team-gränser (scrum of scrum, system demo’s och continuous integration) – till exempel vatten, el och byggbitar som krävde planering samt synkronisering och som föll på plats tillsammans för att skapa den efterfrågade leverabeln (feature)
• Jobbet var fokuserat (WIP limit) – få saker gjordes parallellt inom ett team. Istället skapades en tydlig prioritet och man försökte hålla sig till den och avsluta en sak innan nästa påbörjades.
• Reflektera och tolka behoven (PI objectives) – när teamen tog sig an ett nytt område och inkrement så blev det naturligt att de berättade hur det såg på det som skulle åstadkommas. Detaljerna var inte så viktiga (de kom mer upp under eventuell nedbrytning och planering). Istället var syftet och slutresultatet den viktiga handskakningen.

Lessons learned - backloggen ska leva

• Vi strök ganska mycket av vårt ursprungliga scope till fördel för nya krav som dök upp under arbetet som hade högre prioritet, annat förenklades eller sköts på framtiden. Några exempel - igensättning av ett fönster hoppade vi över och det som gjordes snyggades bara till utifrån, luckan till förvaringsutrymmet under terrassen gjordes väldigt enkel samt bortforsling och i ordningsställning av mark runt om bygget fick bli Team Familjs jobb under sommaren. Istället byggde vi till exempel en extra odlingslåda och olika terrassnivåer.
• Förutsättningarna för staketbygget var annorlunda än resterande scope - det var två beställarorganisationer (vi och grannarna) och förutsättningarna var tydliga och kända. Därför kunde det hanteras annorlunda och jobbet gjordes därför enligt ett fast pris.

Var inte trogen den ursprungliga backloggen (gäller både beställare och utförare).

Lessons learned – Håll kravställningen på rätt nivå & kommunicera 

• Var tydlig med vad som är viktigt och vad som är mindre viktigt - detaljer som kan verka obetydliga kan faktiskt vara av vikt. Till exempel skulle vi (senare) bygga en kajakförvaring på trallen vilket innebar att trallen behövde komma ner till en viss nivå för att kajakförvaringen skulle komma in under ett fönster i vardagsrummet. Eftersom kajakförvaringen inte var en del av scopet var detta inte helt självklart.
• Fostra teamen i att ge feedback till beställaren - saker som man ogenomtänkt kastar ur sig kan visa sig vara betydligt dyrare än vad man förstått som beställare. Till exempel så kunde vissa saker säkert gjorts snabbare och enklare om inte vi gått ner på obetydliga detaljer.
• Fostra teamen i transparens - att återkoppla om vad som händer, gör att man som beställare blir mer trygg även om det inte alltid är goda nyheter. Till exempel så kan en beställning eller hämtning av material inte alls vara så bråttom längre, pga förseningar i resterande arbete. Likaså är en snabb förklaring om varför det går långsamt eller man inte är på plats något som mildrar eventuell frustration.

Att kommunicera och skapa transparens kan inte nog betonas, och det är viktigt att inse att även detta är något man lär sig och övar sig på.

Lessons learned – stop starting, start finishing

Under en period under arbetet hade Team Familj alldeles för mycket puckar i luften samtidigt. Ganska kort in i arbetet så gjorde vi halt och diskuterade situationen (retrospektiv). Det visade sig att det fanns en frustration kring otydlighet och att saker sköts in i backloggen utan en vettig detaljering, nedbrytning, tanke på prioritet eller beroende analys. Så vi skapade tydlighet i backlogg där framförallt prioritet och beroendena adresserades vilket gjorde att Team Familj kunde jobba mer strukturerat och genomtänkt och inte göra allt samtidigt. Nya saker fortsatte förstås poppa upp under arbetets gång men nu var processen tydlig och vi undvek lätt att hamna i samma fälla.

Se till att inte ha för många bollar i luften samtidigt – lär dig avsluta saker innan nya påbörjas.

Så vad säger SAFe om vår metodik och mognad?

Jag tyckte själv att jag varit bra på att följa det agila manifestets värden och principer och till viss del även House of Lean. Så efter att ha skrivit ovanstående blev jag ju nästan tvungen att göra en Business Agility Self-Assessment för att se hur jag ”objektivt” stod mig jämfört med det ramverk jag tyckte jag såg stora likheter med. Nedan kan ni se min assessment.

I kommande projekt kommer det nog vara mer uttalat och transparent hur jobbet kommer bedrivas och hur teamen ska agera och inte att det bara ”råkade” bli så. På det sättet kanske jag kan förbättra mig på kompentensområden så som Continuous Learning Culture och Organizational Agility. Vad tror ni?