Inledning

När vi på Onbird ombeds hjälpa en kund med struktur för planeringsarbete, så är det ofta i själva verket steget innan – nedbrytningen av arbetet – som är utmaningen. Ett otydligt underlag att planera efter ger också en otydlig planering.

I en värld som ständigt förändras, kräver framgångsrik produktutveckling flexibilitet och anpassningsförmåga. Så långt är nog de flesta överens. Agila eller på annat sätt lättrörliga metoder har blivit lösningen för många team som strävar efter effektivitet och kontinuerlig förbättring. En central aspekt av (och en förutsättning för) detta är nedbrytning av arbete. Nedbrytning av arbete är en teknik som gör stora uppgifter mer hanterbara och ökar teamets förmåga att leverera värde snabbt och frekvent.

Vad är nedbrytning av arbete och varför vill vi göra det?

Nedbrytning av arbete innebär att dela upp ett stort projekt eller större arbetsinsats i mindre, mer hanterbara delar. I särskilt ett agilt sammanhang, möjliggör detta snabbare anpassning till förändringar, lättare prioritering och mer fokuserad insats från teamets sida. Detta eftersom den agila metodikens själva natur, med korta cykler/sprintar, kräver att en arbetsenhet inte är större än sprintlängden. Vidare bör, redan nu, påpekas att nedbrytning av arbete inte är något som görs av en person. Domänkunskap i kombination med en gemensam förståelse kräver oftast flera inblandade.

Faktiska fördelar med att bryta ned arbete

Snabbare förändring

Väl nedbrutna arbetsuppgifter har i (agila) team flera tydliga fördelar som direkt påverkar teamets prestanda och produktens framgång. Först och främst möjliggör det snabbare respons på förändring. Genom att arbeta med mindre, hanterbara uppgifter kan teamet lättare omfördela resurser och justera fokus baserat på nya krav eller insikter. Detta är särskilt värdefullt i en agil miljö där flexibilitet och anpassningsförmåga står i centrum.

Bättre tidsuppskattningar

En annan betydande fördel är förbättringen av precisionen i tidsuppskattningar. Mindre arbetsenheter gör det enklare för teamet att göra realistiska tidsbedömningar, vilket i sin tur leder till mer tillförlitlig planering och förutsägbar leverans. Denna noggrannhet är avgörande för att bygga förtroende hos intressenter, något vi pratar mycket om i vår kurs Certifierad Produktägare.

Tydligare vad som ska göras, av vem – och när

Nedbrytning av arbetet leder också till en ökad transparens. När uppgifter är tydligt definierade och tilldelade blir det lättare för alla inblandade att förstå vad som görs, av vem och varför. Detta underlättar öppen kommunikation och gör det enklare att identifiera och adressera problem tidigt i processen. Dessutom kan förväntansbilden på leveransen hanteras lättare, eftersom det blir tydligare vad som kommer att levereras och när det kommer att levereras.

Stärkt samarbete

Slutligen främjar nedbrytningen av arbete samarbete och kommunikation inom teamet. När arbete delas upp och distribueras tydligt, uppstår naturliga tillfällen för medlemmarna att samarbeta och hjälpa varandra. Detta stärker inte bara teamkänslan utan bidrar även till kunskapsdelning och kollektiv problemlösning.

Sammanfattningsvis är nedbrytning av arbete en kärnstrategi inom agila metoder som direkt bidrar till ökad anpassningsförmåga, noggrannhet i planering, transparens och samarbete. Tillsammans skapar dessa faktorer en stabil grund för effektiv produktledning och bättre leveranser.

Hur gör vi då?

Nedbrytning av arbete i mindre delar är något vi alla gör dagligen. Saker som, i sig, inte är så komplicerade behöver ändå delas upp i delsteg och i vissa fall göras i en särskild ordning. Detta gör våra hjärnor automatiskt åt oss, särskilt när det är något vi gjort många gånger förr. När det gäller vårt arbete så behöver vi ställa och och fundera aktivt lite grann.

Generell algoritm för nedbrytning av arbete

Ur ett utvecklingsperspektiv kan algoritmen för att bryta ned arbete se ut så här:

Alternativa sätt att bryta ned arbete

Förutom att enbart bryta ned arbetet i de steg man själv ser så kan vi förstås använda andra attackvinklar. Ett vanligt angreppssätt är att utgå ifrån den s.k. kundresan och titta på de steg som kunden behöver ta för att uppnå målet. Om det känns knepigt kan du titta vidare på andra faktorer, t.ex. genom SPIDR.

Det viktigaste att ta med är att våga spendera tid med att bryta ned och att tydligheten kring nedbrytningen finns där.

För fler tips och ett smidigare format, ladda gärna hem vår lathund för nedbrytning av arbete.

Lycka till!

Något som ständigt återkommer i diskussionerna med våra kunder är det här med projekt och agila metoder. Här vore det ibland skönt att kunna ha något att luta sig mot. Som till exempel en lathund för projektledare i en agil värld! Vi på Onbird har förstås mängder av tankar i ämnet, men de kan sammanfattas så här:

Vi kommer inte att kunna göra oss av med vare sig agila metoder eller projekt. Båda har sina fördelar och behöver kunna samexistera. Vårt fokus ska ligga på framgång och resultat och samexistensen behöver dialog.

I denna artikel kan du först läsa kort om vad du, som projektledare eller ledare i en agil kontext, ska tänka på för att göra samexistensen lättare.

I slutet av artikeln finns det möjlighet att ladda hem en lathund för projektledare, med lämpliga frågor att ställa. Dessa frågor är relevanta från både projektledarens, såväl som ett agilt teams, perspektiv för att förenkla samarbetet.

Ny kurs inom Agile

Att kombinera agilt och projekt

I kursen ”Kombinera agilt och projekt” får du en förståelse för drivkrafterna bakom båda sidorna och dessutom kunskap i hur de kan kombineras.

Pris: 11 000 SEK exkl. moms
Datum: 18 jan 2024, 11 april 2024, 22 maj 2024

Ny kurs inom Agile

Att kombinera agilt och projekt

I kursen ”Kombinera agilt och projekt” får du en förståelse för drivkrafterna bakom båda sidorna och dessutom kunskap i hur de kan kombineras.

Erbjudande!
Pris: 11 000 SEK  8 800 kr (20% rabatt)
Datum: 11 okt 2023, 5 dec 2023

Ny kurs inom Agile

Att kombinera agilt och projekt

I kursen ”Kombinera agilt och projekt” får du en förståelse för drivkrafterna bakom båda sidorna och dessutom kunskap i hur de kan kombineras.

Erbjudande!
Pris: 11 000 SEK  8 800 kr (20% rabatt)
Datum: 11 okt 2023, 5 dec 2023

Gemensamma, men skiljande områden inom agilt och projekt

För att sätta alltihop i en kontext, kommer först en genomgång av olika delar av projekt- respektive agil metodik, baserat på deras beståndsdelar och med fokus framför allt på hur de skiljer sig åt. För det gör de. Genomgången nedan tar avstamp i att du förmodligen vet en del om den ena eller båda metodikerna och syftar mest till att belysa några av de större skillnaderna mellan dem.

Styrmedel

I ett projekt brukar de huvudsakliga styrmedlen vara de tre parametrarna kvalitet (även kallat ”funktionalitet”), tid och resurser. Även om alla tre kan vara variabla, är det ofta tid- och resursparametrarna som man väljer att ändra på om scope eller något annat förändras.

I den agila världen är ju både tid och resurser fixerade och knutna till en produkt, så det är funktionalitetslistan som får ses som dynamisk. Detta är en viktig och grundläggande faktor i den agila metodiken.

Planering

En av grunderna inom all projektmetodik är detaljerad planering. En god projektplan är specificerad mot både kostnader, leverabler och tid. Detta ger en tydlig möjlighet för den beställande verksamheten att avgöra när de kan räkna med att en viss effekt uppstår och till vilken kostnad.

En agil approach mäter istället konstant hur en produkt presterar. Dessa mätningar och kundinteraktion hjälper till att avgöra vad som är det steg som ger mest kundvärde i den närmaste sprinten. Man vill därmed inte säga exakt vilka insatser som kommer att kunna göras när. Detta, eftersom det hämmar oss från att kunna förändra planen. Däremot har man ett intensivt fokus på att tillfredsställa kunden, oavsett om hen ändrar sig eller ej.

Känner du igen dig? Grattis! Har du titeln Produktägare men känner inte alls igen dig? Du är inte ensam. Produktägarrollen är en nyckelroll inom den Agila organisationen, men många organisationer förbiser eller missuppfattar den.

Både personer såväl som organisationer gör det vanliga misstaget att inte helt ha förstått produktägarens roll och vilka kompetenser som är viktiga. Här kommer därför en genomgång av vad en produktägare gör. Vi går också igenom Produktägarens ansvar och varför det är viktigt att den omgivande organisationen också förstår detta. En väl anpassad produktägarroll är nämligen en av de viktigaste nycklarna för att få den Agila processen att fungera.

Rollen Produktägare

Produktägaren (också känd som ”Product Owner” eller ”PO”) är en vital del av det Agila teamet. Rollen är en sammanslagning av ett flertal ansvar och befogenheter. Dessa har, traditionellt, ofta varit utspridda på flera andra personer och delar av organisationen. PO placerar sig, naturligt, på en organisationskarta någonstans mellan affär och teknik. Detta, eftersom hon har ett affärsmässigt ansvar för produkten. Samtidigt måste hon ha ett väldigt nära samarbete med utvecklingen och utförandet.

Produktägaren ser helt enkelt till att värdet av det som utvecklingsteamet producerar under en iteration är så högt som möjligt. Hur vet man då vad som ger ”värde”? Att ta reda på det kräver en tydlig vision om hur produkten skall utvecklas samt ständig kommunikation med användare, ledningsgruppen, kundsupporten, administratörer… helt enkelt alla som har intresse i produkten.

I praktiken ser produktägaren till att prioritera det arbete som utvecklingsteamet ska göra genom sin Product Backlog. Sedan planerar vi in det som ger mest värde för kunden och/eller produkten i teamets Sprint Planning.

8 enkla tips hur du kommer igång med ditt agila arbete.

Produktägarens ansvar

Arbetet som utförs under en iteration hämtas från en produktbacklog och läggs – vid planering – i en iterationsbacklog. (Eller en ”sprint backlog”, om ni är scrumifierade). Den tidigare innehåller all utveckling som skall göras i framtiden på produkten och den senare gäller enbart det som vi gör i aktuell iteration. Se ”Grunderna i Scrum” för mer detaljer kring dessa begrepp.

Glöm inte att kolla in vår certifierande utbildning i produktägarskap!

En produktägare kan när som helst prioritera om produktbacklogen. Det gör hon för att på bästa sätt matcha det som kommer att ge mest pang för pengarna. Och vi mäter förstås pang för pengarna i valutan kundvärde. Vad som ger mest värde kan förändras över tid, så nya ärenden kan läggas till i produktbacklogen och gamla kan tas bort eller prioriteras om. Här är det också viktigt att poängtera att det enbart är produktbacklogen som PO stuvar runt i – iterationsbacklogen lämnas ifred efter iterationsplaneringen!

Personen Produktägare

Den som ska jobba som PO behöver vara en ”people’s person” – någon som kan hantera många olika typer av människor, allt från utvecklare till användare till finanschefer. Det är lika viktigt att kunna prata som lyssna. Vi säger ofta att PO marknadsför och säljer in sin produkt, det handlar till stor del om att skapa förtroende och få med alla på den roadmap man satt upp. Men lika viktigt är det att lyssna och förstå behoven från vitt skilda intressenter och kombinera ihop dessa till en översiktlig plan för produkten.

Då PO är en typisk ”spindel i nätet”-roll finns det stor risk att man i rollen blir involverad i en massa saker som inte har direkt med produkten att göra. Då gäller det att påminna sig själv och andra att ens lojalitet är till produkten i första hand. Ingen kan allt och har du inte alla dessa egenskaper så kan du omge dig med personer som kompletterar dig.

Vem bestämmer då?

Produktägaren har, i de flesta fall, någon form av utvecklings- eller utförandeteam runt omkring sig. Detta/dessa team har – i en Agil värld – också stora mandat i frågan om hur man utvecklar produkten framåt. För produktägaren ligger intresset i vad som görs när, och inte hur, men hon har alltid sista ordet. Det är nämligen så att produktägarens ord gäller, och det oavsett vem som kan tänkas ha åsikter i frågan. Att produktägaren har nära kontakt med teamet är av yttersta vikt – gärna fysiskt, för möjlighet och tid till frågor och svar on-the-fly.

Det är produktägaren som står som ytterst ansvarig inför omvärlden gällande produkten, dess utveckling, livscykel och värdeskapande. Därför måste mandatet också vara utformat därefter. En produktägare har nämligen inte möjlighet att ta sitt fullständiga ansvar om hon inte samtidigt får mandatet att ta alla beslut rörande produkten.

(För att läsa mer, hämta hem hela vår guide via knappen nedan)

Året 2022 har inte varit ett helt vanligt år. Både i omvärlden och i vårt eget land har det skett mycket som påverkar oss, i såväl de privata som professionella delarna av våra liv. Inte heller hos Onbird ser det ut som det gjorde för ett år sedan. Dessbättre är förändringarna hos oss nästan uteslutande på den positiva sidan när vi räknar ihop året. Vi har blivit betydligt fler och har i och med det även kunnat hjälpa betydligt fler kunder och organisationer i deras förändring/utveckling.  

Vi är förstås stolta över ett bra år hos oss och med ett stort tack till våra kunder tänker vi – som brukligt – tillsammans ge lite tillbaka genom en julklapp till dem som verkligen behöver det.  

I år har diskussionen om vart vårt bidrag skall gå varit kort. Läget i Ukraina är fortsatt kritiskt, men världen är stor och det finns många som lider även utanför Europa. Därmed kommer vi att ge vårt julbidrag till UNICEFs globala insatser med fokus på barns utsatthet. 

Än en gång: ett stort tack till alla våra kunder som gjort detta möjligt genom att visa oss förtroendet att få vara med och hjälpa er i er verksamhetsutveckling under 2022.

God jul och gott nytt år från oss på Onbird,

Jeff, Martin, Tobbe, Nathalie, Daniel, Aida, Linda och Karin

Produktägarens kompetenser

En av de första frågor vi på Onbird ställer när vi ska hjälpa en organisation i en agil förändringsresa är ”Och hur ser produktägarrollen ut hos er?”. Svarets art brukar vara ganska talande för hur arbetet ska börja. Ofta är det dessutom en av underliggande anledningar till att vi över huvud taget är där.

Typiska svar på frågan brukar vara något i stil med följande:

• ”Produktägaren är den som ska se till att IT utför det som verksamheten beställer.”
• ”Produktägare? De ser till att tidrapporterna går till rätt projekt och att IT följer projektplan och budget.”
• ”Produktägaren har full koll på sin produkt och sitt team. Däremot är det inte alla i organisationen som respekterar sprintarna.”
• ”Våra produktägare är ansvariga för systemen och så svarar de mot projektledaren för respektive projekt.”
• ”Vi har en produktägare för verksamheten och en för tekniken, det är bättre att man får ansvara för en grej bara..”

Sammanfattningsvis: det är ofta tydligt att rollen inte är solklar. Dessutom skiljer sig svaren och definitionerna ibland åt beroende på vilken del av organisationen vi frågar. Summa summarum, behöver vi helt enkelt bli tydligare i vad rollen innebär och vilka produktägarens kompetenser behöver vara. Fortsätt läsa för att nå ”Produktägarens 7 budord”, som sammanfattar både produktägarens kompetenser och inom vilka områden hen ska verka.

Crowdsourcade budord

Produktägarforumet som nämns ovan har hjälpt till sina deltagare i det dagliga och gjort rollen lite bättre. Dessutom sammanställdes för några år sedan världens första (tror vi) crowdsourcade checklista för produktägare i just detta PO-forum!

Det är i denna crowdsourcade checklista vi finner våra budord. Dessa är ett resultat av en hel drös produktägare från många olika branscher och organisationer, som tillsammans stött och blött innehållet. Det som tagit mest tid är troligtvis att minska mängden ord, för att göra den enkel och snabbläst. Sammantaget blir det en listning över de kompetenser och drivkrafter produktägaren bör ha.

Innehållet

Checklistan består av dels en generell definition och dels sju fördjupningar på detaljnivå.

Den generella definitionen lyder som följer.

”Som produktägare är jag ansvarig för att maximera utkomsten från min produkt. Jag säkerställer detta genom att ständigt underhålla och prioritera mitt primära verktyg: produktbackloggen.”

Denna ”trossats” (eller vad det ska kallas) ger oss mycket foder för diskussion och inlärning om vi bara kikar lite närmare på den. Exempelvis nämner vi ordet ”utkomsten”. Här åsyftas alltså att det man levererar inte är det viktiga utan den effekt som uppstår av leveransen. För att uppnå detta krävs förstås att produktägaren har koll på både intressenter, användning, kommunikation och affärsmodeller. Och vad syftar ”mitt primära verktyg: produktbackloggen” på? Är en produktbackloggen verkligen ett verktyg?

Om du vill fortsätta djupdyka i ovanstående, tveka inte att höra av dig, så kan vi räta ut frågetecken över en kopp kaffe!

Produktägarens 7 budord (nåja – områden i alla fall)

Det finns många olika aspekter som en produktägare behöver ha i åtanke i sitt arbete med en produkt. Dels ska hen förstås veta hur produkten levererar värde till sina kunder just nu. Men det ingår också att skapa möjlighet att snabbt kunna leverera värde även i framtiden. I diskussionerna som föranledde detta dokument blev det tydligt att områden skiljer sig åt i viktighet och lättillgänglighet mellan olika organisationer. Detta gäller både produktägarens önskade kompetenser och faktiska mandat. I konklusion sammanställde vi sju områden. Bland dessa finns säkert aspekter och detaljer som motiverar fler områden, så tveka inte att återkomma med feedback om du upplever att dessa områden inte stämmer!

De sju områden vi fokuserar på i vår sammanställning är följande:

• Produktvision (mall för produktvision)
• Kommunikation
• Intressenter (mall för intressentanalys)
• Produktbacklog
• Teamet
• Ceremonier
• Organisation

Avslutningsvis

Läs mer om vad inom varje område som en produktägare bör bemästra genom att ladda ned Produktägarens 7 budord nedan.

Sist men inte minst: samtliga dessa områden (och förstås ännu mer verktyg, tips och tricks) är del av kursen ”Certifierad Produktägare”. Läs mer om den kursen och kurstillfällen här.

Mätvärden och KPI:er. I vissa kontexter ord som sänder en omedelbar känsla av uttråkning eller i värsta fall stress. Vore det inte bättre om orden framkallade en känsla av nyfikenhet istället? Mycket hänger faktiskt ihop med hur du skapar mätvärden.

Inom (särskilt) den agila förändringsvärlden är vi besatta av mätningar. Dels för att det ökar transparensen – vi kan lova färre detaljer från början om vi regelbundet kan visa att vårt arbete ger positiv effekt. Dels för att det ger oss snabb återkoppling på om vi prioriterar rätt saker. Sist men inte minst är det vårt bevis för att förbättringsarbetet faktiskt fungerar. En känsla av att allt är som det ska är bra på många sätt, men datadriven förbättring är bättre!

Hur fungerar mätvärden?

De flesta av oss kommer dagligen i kontakt med mätvärden på ett eller annat sätt. Om det inte är i vårt jobb, så är det i stället när vi bara befinner oss någonstans i livet. Mätvärden är helt enkelt avläsningar av ett nuläge.

Vad är klockan just nu? Hur fort kör jag? Hur kallt är det ute?

Varför ens mäta?

Tid, hastighet och temperatur är exempel på mätvärden som kan få oss att reagera på ett eller annat sätt för att maximera det som är värdefullast. Om vi är sena skyndar vi på, har vi gott om tid kan vi läsa vidare på favoritbloggen. För att autopiloten i en bil av nyare snitt ska kunna framföra bilen någorlunda säkert finns en stor mängd olika sensorer till dess hjälp. Dessa sensorer läser dessutom av omvärlden häpnadsväckande många gånger per sekund. Allt för att bilen ska kunna veta hur omvärlden ser ut och för att kunna reagera snabbt om det dykt upp något som hindrar oss från att komma fram.

Kort sagt: för att kunna reagera, behöver vi hela tiden veta var vi befinner oss just nu och vart vi är på väg. Har vi för mycket fokus på målet, finns risken att vi krockar på väg dit.

Sju tips för att skapa mätvärden

Trots sin viktighet, upplever många att mätande är svårt. Bra mätvärden är lätta att förstå och att validera och det kanske är här man fastnar. För att skingra dimman lite, kommer här våra sju bästa tips för bra mätvärden:

Varför är det här viktigt? Och för vem?

Ju mer vi arbetar med mål och mätningar, desto mer upptäcker vi. Syftet med våra mätningar är att hela tiden jämföra med tidigare resultat. Det innebär att vi ser till förändringen (trenden) i resultatet snarare än resultatet i sig. Mätningar kan inte omedelbart säga åt oss att vi är eller när vi blir ”klara” med något, men däremot är de utmärkta för att se att vi är på väg åt rätt håll. Ett fåtal mätvärden räcker ofta för att veta att helheten trendar rätt. Det betyder att vi ofta inte behöver några jättemängder med mätetal, utan ett fåtal räcker långt.

Beroende på vilken roll du har och i vilket sammanhang, så kan fokuset vara olika. Om du som läser det här har  en roll nära ett teams leverans är det förmodligen förbättring av att arbetet du vill mäta. Om du däremot har eller är nära produktägarrollen, är det förmodligen din produkt du vill validera ur synvinkeln affärsvärde.

Vill vässa din produktägarroll, både ur mätsynvinkel och många andra viktiga områden? Läs mer om vår populära och certifierande produktägarutbildning här!

Lycka till!

Ladda ner vår populära e-bok

7 faktorer för att organisera ett väl fungerande agilt team

Ladda ner vår guide för att bygga effektiva agila team! Upptäck sju viktiga faktorer, praktiska verktyg och beprövade metoder som hjälper dig att optimera ditt teams prestation och samarbete. Börja din resa mot agil framgång idag!

Ladda ner vår populära e-bok

7 faktorer för att organisera ett väl fungerande agilt team

Ladda ner vår guide för att bygga effektiva agila team! Upptäck sju viktiga faktorer, praktiska verktyg och beprövade metoder som hjälper dig att optimera ditt teams prestation och samarbete. Börja din resa mot agil framgång idag!

De Agila grundvärderingarna

Vad innebär värderingarna i praktiskt Agilt arbete?

Det Agila tänkesättet handlar bland annat om att:

• Främja regelbunden kommunikation på alla nivåer.
• Flytta beslutsmandat längre ut i organisationen.
• Inse att det är oerhört svårt att förutsäga vad som gör en framgångsrik slutprodukt innan arbetet ens är påbörjat.
• Inkluderande och iterativt arbete med utvärdering i varje steg är nödvändigt för en bra slutprodukt.
• Förändringar i grundidén är välkommet genom hela arbetsprocessen och stöds av principerna.

Det Agila tankesättet följer inte processen kring deadlines på samma sätt som traditionella processer. Samtidigt strävar det efter att minimera risk samt producera en bättre anpassad slutprodukt så snabbt som möjligt.

Ett Agilt förhållningssätt påverkar inte bara själva arbetsgruppen utan också alla intressenter, exempelvis ledare och kunder. Därmed är det av stor vikt att även dessa grupper har en klar bild av vad det innebär att arbeta Agilt.

För att införa dessa principer i praktiken finns flera metodologier och ramverk som implementerar de Agila principerna till din hjälp. Några exempel på sådana ramverk är Scrum, Kanban, eXtreme Programming (XP) och DevOps. Vidare finns det även tydliga beröringspunkter och arv från andra ramverk och tankesätt, såsom Lean och ITIL (där den senaste versionen av ITIL faktiskt i sin tur har kikat en hel del på de Agila principerna).

När och varför ska jag jobba Agilt?

Inom komplexitetsteorin skiljer man på om en aktivitet är komplex eller komplicerad. En komplicerad uppgift kan förvisso vara svår att analysera, men utfallet är förutsägbart. Befinner du dig i en komplex värld kan utfallet variera, även om man gör samma sak igen.

I en projektorienterad värld sätter vi en projektbudget och en deadline. Dessutom sätter vi oss även och försöker att analysera hur lång tid arbetet kommer att ta, hur många människor som behövs för att utföra det samt hur utfallet kommer att bli. Det enda vi egentligen med säkerhet kan veta i det läget är att inget kommer att bli exakt som vi tror, oavsett hur noga vi beräknar. Det är här Agila tankesätt kommer in.

Agila tankesätt tar den här ovissheten som huvudtes och bygger istället på tanken att börja utifrån den hypotes och kunskap vi har nu och så jobbar vi bara en liten, liten bit (exempelvis ett fåtal veckor) innan vi utvärderar. Om vi konstaterar att vi är på rätt spår, så fortsätter vi med samma cykel igen. Detta istället för att hugga allt i sten från början, vilket binder oss till en lösning som kan bli svår att ändra under resans gång.

För att kunna mäta de små förändringar som sker i varje iteration måste vi redan från början veta vilket värde det är vi förväntar oss att leverera och så mäter vi förändringen av det i varje cykel.

”Så, är min organisation lämplig att tänka Agilt?”

Förmodligen. Särskilt om ni jobbar mycket med IT. Kort sagt, befinner ni er i en värld som är snabbrörlig och där utfallet av er utveckling inte alltid är solklar (om ni har fler än 2 användare, till exempel) så är Agilitet något ni vill veta mer om.

Därmed inte sagt att Agilitet faktiskt är en silver bullet. Men det är en bra anpassning till den värld som IT och den omgivande organisationen faktiskt måste kunna hantera.

De tolv principerna för Agilt arbete

För att utveckla hur grundvärderingarna ska tolkas i det dagliga arbetet innehåller Det Agila Manifestet även 12 principer. Här följer de i enlighet med sin ursprungsdefinition med en tilläggskommentar från mig:

6. Kommunikation ansikte mot ansikte är det bästa och effektivaste sättet att förmedla information, både till och inom utvecklingsteamet.

Feedback går fortast när man pratar direkt till varandra. Detta behöver inte förtydligas. Men det är viktigt nog att ha som princip.

10. Enkelhet – konsten att maximera mängden arbete som inte görs – är grundläggande.

Genom att hela tiden prioritera vad som är viktigast för just denna iteration, kommer teamet enbart att leverera värde för produkten. Detta fokus hjälper till att eliminera mycket övrigt onödigt arbete runtomkring. Här kommer även automatisering av repeterade uppgifter in naturligt.

12. Med jämna mellanrum reflekterar teamet hur det kan bli mer effektivt och justerar sitt beteende därefter.

Den bästa utkomsten kommer från självorganiserande team. För att ständigt utvecklas har teamet regelbundet sina egna utvärderingar, helst inom ramen för varje iteration. Detta leder till att förbättringar sker ofta och i små steg. Små irritationsmoment kan tas ’på bar gärning’ och undvikas i framtiden.

Ovan nämnda principer och värderingar är i sig självt inte en konkretiserad process, utan pekar mot att Agilt arbete är en filosofi. Att arbeta Agilt är inte målet. Ett företags mål kvarstår, om det så handlar om att skapa produkter eller tjänster. Vi ser allt för ofta hur man hamnar i ett dogmatiskt förhållningssätt gällande Agilitet och det faller på sitt eget grepp. Det Agila tankesättet är inte tänkt att vara ett regelverk som har svar på alla frågor, eftersom det skulle förhindra det som är huvudsyftet: lättrörlighet och kundvärde. Det man vill undvika är ett ”one size – fits no-one”-scenario, vilket leder till att vissa delar behöver funderas ut och skapas av organisationen självt.

Däremot ger ett Agilt tankesätt möjligheterna att lättare följa (eller leda) i en föränderlig värld utan att falla i fällan av för mycket dokumentation och byråkrati. Lättrörligt, helt enkelt.

Nu har du fått en snabb genomgång av hur det Agila arbetet skall se ut i teorin. Dock krävs det lite tankekraft för att omsätta det i praktiken. Varför inte öva praktisk omsättning i det Agila spelet Birdville eller i vår tidseffektiva övning 1, 2, 3 – SPRINT?

Om du inte riktigt fått nog av läsande än, läs mer om det vanligaste sättet att implementera agila förhållningssätt genom att grotta ned dig i Scrum.

Ny kurs inom Agile

Att kombinera agilt och projekt

I kursen ”Kombinera agilt och projekt” får du en förståelse för drivkrafterna bakom båda sidorna och dessutom kunskap i hur de kan kombineras.

Pris: 11 000 SEK
Datum: 26 sep 2024, 10 okt 2024, 21 nov 2024

Ny kurs inom Agile

Att kombinera agilt och projekt

I kursen ”Kombinera agilt och projekt” får du en förståelse för drivkrafterna bakom båda sidorna och dessutom kunskap i hur de kan kombineras.

Pris: 11 000 SEK
Nästa datum: 26 sep 2024, 10 okt 2024, 21 nov 2024

På Onbird har vi gedigen erfarenhet av att arbeta Agilt, att coacha samt att medverka i både helheten i en Agil transformation, men även i detaljkunskaper om de praktiska delarna, såsom Scrum, SAFe, Kanban och DevOps. 

Behöver er Agila process hjälp att komma igång eller behöver ni en push för att få till den där hävstången som alla snackar om? Tveka inte att höra av dig till oss för att höra hur vi kan hjälpa dig komma igång på riktigt eller bara prata agilitet i allmänhet!

Gymnastik med coachen

När nu distansarbete blivit ett vanligt inslag för många är det inte alltid helt lätt att hålla ångan uppe hela dagarna. Hos en av våra kunder har filmer med pausgympa blivit ett etablerat begrepp och särskilt under längre sessioner, som exempelvis PI-planeringar eller långa workshops.

Självklart ska även vi som externa konsulter i en organisation vara med och bidra till hälsa och friskhet. Vi gjorde en träningsvideo för stillasittande arbete redan 2020. Den blev snabbt populär, dock behöver även sådana uppdateras. Så vi gjorde en uppdatering 2023. 

Populariteten har fortsatt, så vi fortsätter uppdateringarna!

Gymnastik med coachen, version ”sommar 2025” ser ni nedan. Och glöm inte att stretcha efteråt!

2023 års version

Originalet från 2020

Skulle det vara så att ni hellre vill använda originalversionen från 2020, så hittar du den här nedanför.

Förutom att vi på Onbird gärna ser att man skrattar mycket på jobbet (exempelvis genom pausgympa), kan vi förstås hjälpa dig inom områden vi faktiskt är bra på. Kika gärna vidare på vad vi gör, vilka utbildningar vi håller eller vad vi skrivit om i vårt kunskapcenter.

Om du har några frågor är du mer än välkommen att kontakta oss, till exempel genom kontaktformuläret nedan.

Kontakta oss

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!

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:

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.

You know it just a bit too well – working in infrastructure (or anywhere else considered ”non-dev”) is spending a lot of your time handling incidents and putting out small fires here and there. In between that, you need to update and upgrade both software and hardware, and maybe some work with new technology finds its way in there every once in a while.

Since a lot of what you do is about handling the situation right here and right now, deadlines become quite hard to both promise and honor, unless they’re burning as bad as the incidents coming in. This is where the concept of iterative work comes in for non-dev teams.

The need for prioritizing

But if everything is on fire and everything is important, how do we manage our priorities? Do we choose to work with whatever we enjoy the most or with the client who shouts the loudest? Or do we simply make our priorities based on what we find first in our inbox since I, as the expert, is as suited as anyone else to make that decision in my part of the environment? Without a fixed scope with a clear time frame, it’s hard to predict our work for even rough estimates. There are quite a few different factors in the paragraph above that will be (if, at all) considered very hard, if not impossible to solve. I’ll go out on the limb and dare to say that we have plenty of options. In a few blog posts we will cover some simple mechanisms to structure your work in a way to make it more predictable and making it easier on your conscience to talk about deadlines. In the long run, we’ll also be looking at lowered numbers of incidents and problems.

Why iterations?

Within the Agile philosophy, we talk a lot about iterations. In combination with a close communication with the customer, it has proved itself as working very well in areas such as product development. Over time, it produces a better suited product, while minimizing the risk. Within infrastructure, a common concept is big monolith projects where the delivery cycles are long and different projects running at different speeds must coexist within the same pool of resources. When the same resources are working in multiple projects at the same time, large piles of post-its tend to become the number one information collections. In these conditions, both prioritization and project synchronization tend to lose precedence to simply just ”doing things”. Any things.

Iterations for non-dev teams

By splitting our long delivery cycles into smaller pieces, creating a shorter time horizon, we can focus on what is the most important (and right) thing to do right here and right now. Instead of having the ever-present tension of an enormous to-do-list towards some deadline months away, we simply narrow our scope to what we should be doing the next few weeks. Nothing more. To be able to frame in how much work we actually can accomplish and finalize within e.g. two weeks, we need to peel off and clearly define smaller bites of the total amount of work. This helps us to get a graspable overview of what actually will be done over the next weeks and when the scope is that small, prioritization becomes a lot easier, since you simply cannot choose to do everything at once. If you only have a few weeks worth of time, you are forced to really choose what is most important right now.

It is not incidents vs. iterations

”But, what about incidents?”, you say. We make time for those as well when we plan the iteration. Working in iterations is no silver bullet to making them go away, but with a fixed cycle we will also be able to get a more detailed overview on how many incidents we have and how much time they steal from our planned work, as we are now able to also see how much of the planned work we didn’t do.

The easiest way to get this going this is to start cutting the huge projects into smaller pieces. Try making them small enough to fit into just one iteration. It’s a great start. I think you’ll see that both estimates and prioritization for the smaller bites will become a lot more handy. Also, adding up the estimates for the smaller pieces is probably going to give you a better hint on the total time the project is going to consume, rather than estimating the whole enchilada at once.

Predictability is key in keeping a good track record and a healthy relation to our customer. When being able to plan in short iterations, we become more reliable, as our estimates (and promises) to the customer become more accurate.

Wouldn’t it be nice to practice this in a safe environment before going all-in on iterations with your organization?

This can be arranged! Join us in the brand new Agile Service Management simulation MarsLander (link to swedish page – contact us for more information in English).