This is Lean – Modig & Åhlström

Swedish authors from the Stockholm School of Economics help to simply explain the essence of Lean. Perhaps the most easily accessible book on the subject, Modig and Åhlström have wonderful insights, especially regarding flow and resource efficiency. Read our review here.

Get the book at Adlibris.

The Five Dysfunctions of a Team – Lencioni

Author Patrick Lencioni’s classic came out in 2002 and remains one of the better stories and methodologies for building great teams.  Trust, Conflict, Commitment, Accountability and Results.  Simple and critical read regarding team dynamics.  And read more here about our team development based on this book.

Get the book at Adlibris.

Sooner Safer Happier – Smart

Auther Jonathan Smart introduces his change outcome idea for agile/iterative work. The real goal is BETTER VALUE SOONER SAFER HAPPIER. This is what we should focus on and our methods are simply means to achieving it.  Great read.

Get the book at Adlibris.

War and Peace and IT – Schwartz

Author Mark Schwartz brings interesting examples and inspiration to the idea that the business and IT MUST improve their relationship.  Each party needs to increase the dialog with and understanding of the other.

Get the book at Adlibris.

Project to Product – Kersten

Traditional project methodologies are struggling to maintain pace with change.  Author Mik Kersten presents his Flow Framework and exemplifies transitioning to more iterative change over time.

Get the book at Adlibris.

The Machine that Changed the World – Womack, Jones & Roos

One of the classic Lean books, this is the story of the automobile industry and the evolution of Lean within it.

Get the book at Amazon.

Get the book at Bokus.

Drive – The Surprising Truth About What Motivates Us – Pink

A fascinating study of motivation based on scientific and behavioral research. Pink challenges traditional thinking and gives us the three elements of true motivation. Wonderful input to our Lean teams.

Get the book at Amazon.

Get the book at Adlibris.

The Phoenix Project – Kim, Behr, Spafford

An interesting story which is non-technical and easy-to read, The Phoenix Project provides insights into the balance of IT and the business. First published in 2013, the book is considered an early and important book in the movements of DevOps and Lean IT. Here is our blog post about the book.

Get the book at Amazon.

Get the book at Adlibris.

The Unicorn Project – Kim

The Phoenix Project continues in this follow-up – this time the theme explores further the concepts of efficiency, flow and enjoying your work with IT. Here is more about the book.

Get the book at Amazon.

Get the book at Adlibris.

The DevOps Handbook – Kim, Humble, DeBois, Willis

As it’s titled, the handbook for the Dev + Ops movement. How do we get the two to work together and to what benefit?

Get the book at Amazon.

Get the book at Adlibris.

The Lean Startup: How Constant Innovation Creates Radically Successful Businesses – Eric Ries

An insightful book explaining one way of applying lean principles to a start-up of primarily an IT-based business. Shows critical steps for success with a sturdy platform in agile methodologies but applied on a business level. Excellent way of applying some of the Lean IT principles on a business matter.

Get the book at Amazon.

Respect for People – Kusén & Ljung

Swedish authors again, a book about lean leadership based on respect for people. Kusén and Ljung use examples from their Lean journey with Scania.

Get the book at Amazon.

Get the book at Adlibris.

The Lean IT Field Guide – Orzen & Paider

Field guide which pairs with the above textbook. Roadmap structure of lean info and actions to pursue.

Get the book at Amazon.

The Toyota Way – Liker

The definitive book about Toyotas Production System including history, examples, and an introduction to the 14 management principles of Toyota.

Get the book at Amazon.

Get the book at Bokus.

Making Work Visible – Degrandis

Degrandis reveals the real crime – TIME THEFT.  Read about how Kanban can help save you from the five thieves of time.

Get the book at Amazon.

Boken The Phoenix Project introducerar oss till DevOps och Lean IT

The Phoenix Project är boken om en utsatt IT-chef som blir inkastad i ett katastrofprojekt: The Phoenix Project. Boken är en intressant och icke-teknisk läsning för dagens ledare som vill få insikt i utmaningen med balansen IT och affärsverksamhet. Med första utgåva 2013 är boken en storsäljare och även erkänd som tidig och viktig litteratur i IT-rörelserna DevOps och Lean IT.

Skriven som en roman, återger The Phoenix Project klassiska problemställningar som de flesta verksamhets- och IT-ledare känner igen:

• Hur använder vi IT för att transformera vår affär?
• Hur kan jag som icke-tekniker förstå och kommunicera med vår IT-avdelning?
• Hur balanserar vi kritiska projekt med operativ IT och utveckling med drift?
• Vad har IT med människor och ledarskap att göra?
• I boken är Bill Palmer IT-chefen på Parts Unlimited, en leverantör av bildelar. Verksamheten är utsatt för hård konkurrens och har valt att satsa på sitt “Phoenix Project” som räddning. Ja, ni har hört det förr – “…med hjälp av projektet och ny teknik kommer Parts Unlimited återställa lönsamhet och hävda sin plats som världsetta…”.

I inledningen träffar vi Bill där projektet har försenats, vardags IT är dränkt i återkommande incidenter och ett flertal ledare har sagts upp på grund av styrelsens missnöje. Bill kastas motvilligt in som chefen som ska återskapa balans samt leda Phoenix i hamn.

Till skillnad från typisk managementlitteratur eller teknisk rådgivning ger berättelsen ett annat, mera realistiskt och mänskligt perspektiv. Vi träffar:

• Flaskhals Brent, den enda som kan strategiska kodförändringar i projektet och samtidigt den enda som kan hantera brinnande incidenter i drift.
• En flerårig teknikskuld som ledningsgruppen anar men inte kan greppa.
• En COO som upprepade gånger skriker sig till första plats i supportkön.
• Ett ITIL program som snurrar CAB-medlemmar in i en dimma av byråkrati.
• En låsning i kommunikation mellan IT och ledningsgruppen som tvingar Bill att säga upp sig.

Naturligtvis, och i enlighet med amerikanska hjältesagor, så har vi också besvärliga kollegor, konsulter som skurkar, känsloladdade scener och ett lyckligt slut.

Tema

Bokens tema av DevOps och Lean IT ger också nyttiga tips och kontext. IT:s arbete planeras med hjälp av synliga Kanban-tavlor och Change Walls vilket därmed ger kontroll över reaktiva och proaktiva förändringar. Flaskhalsar som Brent skyddas först och sedan därefter manageras medvetet för att sprida hans kunskap och eliminera begränsningen. Bill och hans IT-grupp får sakteligen rätsida på sin dialog med verksamheten med hjälp av synliggjorda Value Streams. Och självklart (spoiler alert!) blir Phoenix-projektet till slut en framgång för IT och Parts Unlimited.

Trots ovanstående utveckling av tips gör boken egentligen inget försök till att vara en instruktionsmanual. Författarna har dock följt upp The Phoenix Project med ett flertal praktiska böcker i ämnet, bland dem The Visible Ops Handbook, The DevOps Cookbook samt The DevOps Handbook.

Tankeväckande och underhållande, The Phoenix Project är rekommenderad läsning för dagens ledare. För den som vill fördjupa sig inom IT-förändring, DevOps och Lean IT är den också en bra startpunkt.

Länkar

Bli en projektmedlem av The Phoenix Project för några timmar i vår affärssimulering.

The Phoenix Project som del av DevOps utbildning, DevOps in2Days.

Boken The Phoenix Project hos Adlibris.

Boken The Phoenix Projekt hos Bokus.

The Phoenix Project är utgiven på engelska av IT Revolution Press. Författarna är Gene Kim, Kevin Behr och George Spafford.

Alltså glöm alla protester. Lägg ner de defensiva anklagelserna om ”för mycket byråkrati” och ”det fungerar inte här”. IT Service Management och ITIL är mer relevanta än någonsin för dagens IT. För att klargöra redovisar vi fem snabba skäl till varför:

Ett bibliotek med kunskap och stöd

Sammanfattningsvis  har vi ett ITIL-bibliotek med dokumentation av bästa praxis, kursutbud och stödmetoder som ger hjälp på både en praktisk och mer detaljerad teoretisk nivå. Och ja – det har också varit källan till mycket debatt, många onödiga processdiagram och mycket huvudvärk. (Medan det förra kan och bör förbättras, är det senare att förvänta sig med storskaliga kunskapsramar?) Låt inte detta deprimera dig – ta det i lagom stora bitar och fortsätt. IT i världsklass är inte tänkt att vara lätt, men det är möjligt med konsekvent och medveten ansträngning över tid.

Nu när dagens IT är affärskritisk och surr om digitalisering finns överallt måste vi som arbetar med IT bli ännu tydligare en källa till transformation och förbättring. Det är på många sätt enkelt men inte lätt, och vårt jobb är att ständigt lära oss. Av detta skäl kan och skall ITILs ramverk tjäna som en kunskapskälla, med stöd och relevans för alla moderna IT-verksamheter.

ITIL^® is a registered trade mark of AXELOS Limited. All rights reserved.

Då det (o)lyckligtvis finns en hel del incidenter och problem i vår IT-värld ser vi på Onbird att det idag finns en relativt hög kännedom till Incident Management– och Problem Management-processer.  Och ändå finns såååå mycket utrymme kvar för förbättring.

Ok då, vad är problemet (eller incident)?

Då processerna är så centrala och väsentliga är det förstås viktigt att de fungerar väl.  Får vi snurr på dessa två processer får vi därmed snurr på tjänsteleveransens tillgänglighet.  M.a.o., vi minimerar nertid.

Problemet vi oftast ser är att dessa processer missförstås, får för lite resursfokus och tillämpas felaktigt.  Nedan följer våra fem tips för att maximera effekt av dessa processer i er organisation.

1.  Förstå skillnaden Incident-Problem och bete dig därefter

Incidenter är inte problem och problem är inte incidenter. Incidenter blir inte problem över tid. De blir inte heller problem via eskaleringsmetoder eller annat vis över tid. Ändå vet vi att incidenter och problem har såklart en stark relation som är viktig att både förstå OCH bearbeta parallellt och medvetet.

Återkommande demonstrerar organisationer att de inte förstår skillnaden ovan och då beter de sig fel i hantering. Det är vanligt att man blandar ihop incidenter och problem och godtyckligt väljer hur de skall hanteras. Det innebär ibland att vi tar fram incidenthantering för problem (tänk den frustrationen när teknikern bara lappar ihop med workarounds när användaren söker en fullständig lösning).  Ibland blir det tvärtom, man kör problemhantering för incidenter (igen så frustrerande – användaren behöver en ”quick fix” och teknikern vill borra ner till detaljernas botten).  Denna felaktiga mix i tillämpning gör att det slutliga resultatet blir mindre bra.

”Who cares, låt mig få jobba?!” får jag ofta höra när jag kommit så här långt i dialogen. ”Är det inte bättre att vi bara kommer i gång och löser saken?”

Ja tack, jag älskar angelägenheten. Och min önskan är att vi angeläget tillämpar både Problem- och Incidentprocesserna – parallellt och medvetet – för att maximera våra resultat.

2. Köp mycket silvertejp för Incident Management

Incident Management älskar workarounds (tänk silvertejp ).  Med silvertejp kan vi lösa det mesta snabbt och kortsiktigt. Avseende incidenter är snabbt och kortsiktigt bra – workarounds är BRA. Detta eftersom syftet är att så snabbt som möjligt hjälpa användaren att vara produktiv. Se till att utskriften funkar genom att silvertejpa det till en annan skrivare. Kör ctrl-alt-delete silvertejp för att starta om en klient eller tjänst. Tejpa ihop trasigt data genom att administrera direkt i databasen.

Vår främsta önskan här är att användaren kan vara produktiv – NU! Därmed menar jag att workarounds skall vara en top-of-mind-instinkt när vi arbetar med incidenter. Var kvick, oroa dig inte för grundorsaker och lägg inte för mycket tid på att hitta en perfekt, långsiktig lösning. Ta för all del fram silvertejpen och få i gång din användare.***

3. Dedikera resurser för Problem Management

Välfungerande Incident Management är fantastiskt, men räcker inte.  Vi har alla varit med om frustrationen när workarounds blir för långlivade (permarounds?).  Det kan inte vara meningen?  Vi skall inte leva med en ständig respons av tejpade skrivare, ctrl-alt-deletande och admin-fixar bakom kulisserna.  Således behöver vi OCKSÅ bygga bort dessa fel.

Där kommer Problem Management in i bilden.  I syfte att gå till botten arbetar vi i denna process på ett annat sätt – beteendet är annorlunda.

Tyvärr är det svårt att skapa rätt fokus och rätt mix av dessa två beteenden.  Många organisationer kämpar för att hålla takt med Incident Management och hinner aldrig riktigt med problemlösningar. Ytterligare premierar de att vara ”snabb” med ”mycket på gång” och därmed hinns det inte med de nödvändiga beteendena i Problem Management.

Därför rekommenderar jag separation av dessa processer samt medveten och dedikerad resurs för Problem Management (tänk time-boxing). För att inte slukas av incidentbruset måste vi sätta av explicit tid och resurs för endast problem. Boxa ett antal timmar/personer för Problem Management och ge dem ansvar och rätt att stadigt och envist identifiera grundorsaker och bearbeta problem.

4. Ständig kommunikation mellan Incident och Problem

Då dessa processer har så starka beroenden till varandra är det avgörande att information flödar fritt dem emellan. Följaktligen vill vi säkerställa att maximal medvetenhet om Problemarbete finns i Incident-teamet. Och tvärtom.

Då och då ser jag självständiga Incidentteam som blir lite väl kära i sina workarounds. Silvertejp i all ära, men dessa team lägger ofta för lite tid på samspel med långsiktiga lösningar och problemteamet.

Likaså har vi kaxiga Problemteam som betraktar workarounds som mindre värda. ”Riktiga tekniker går till botten med problemen,” säger de. Varpå de lägger alltför lång tid gömda i sin problemgrotta. Denna grott-tid kanske behövs, men medför samtidigt onödigt mycket incident-downtime och många missnöjda användare.

Låt inte detta uppstå i din organisation. Dela samma ärendehanteringssystem för dessa incidentärenden och problemärenden. Dokumentera lagom med länkar mellan incident- och problemärenden.  Se till att Incidentteamet inte bara stänger incidenter, men också skapar problemärenden när de behövs. Vidare, se till att Problemteamet kommunicerar grundorsaker och tänkbara workarounds till Incidentteamet INNAN de går på den fullständiga lösningen. Inför frekventa ståupp-möten för snabb, muntlig uppdatering mellan teamen och kräv en ständig och öppen kommunikation.

5. Mäta för flöde

När definitioner för distinkta, parallella och medvetna beteenden är aktiverade samt kommunikationen är etablerad skall vi kunna följa och utvärdera vårt arbete genom mätning.  Börja enkelt och hitta ert eget ”lagom” här.

Vanliga mätetal är såklart orienterade mot volym (t.ex. hur många incidenter per vecka?), lösningsgrad (t.ex. hur många problem löser vi per månad?), och tidslängder (t.ex. hur lång genomsnittstid är en incident öppen?). Dessa och många mätetal kan vara intressanta.

Jag har inte för avsikt att lista alla tänkbara mätetal (kontakta mig gärna om du söker input) men att i stället uppmuntra till ett mera generellt syfte med mätning. Oavsett exakta mätetal, se till att ni använder mätning för att demonstrera ett hanterat in- och utflöde av incidenter och problem.  Och vad menar jag med det? Kortfattat behöver vi se till att inflöde inte överstiger utflöde.  Vi behöver hålla takten, dvs lösa ärenden i en takt som gör att vi inte halkar efter. Backloggen av incidenter och problem skall vi hantera så att den inte växer över tid.

Sammanfattning

För att sammanfatta våra fem tips för Incident och Problem Management:

1. Förstå skillnaden och bete dig därefter
2. Köp mycket silvertejp för incidenter
3. Dedikera resurser för Problem Management
4. Ständig kommunikation mellan Incident- och Problem management
5. Mäta för flöde

Kontakta mig och oss på Onbird om vi kan hjälpa till med ytterligare information i detta.

___________________________________________________________________________________________________

OBS – ovanstående förenklar vissa definitioner och syften i viss mån. Det är jag medveten om – min strävan i denna skrift är att enkelt hålla mig till essensen.

*** Tillämpning av workarounds får naturligtvis inte bortse ifrån andra viktiga policybeslut, säkerhetsrutiner, kostnader, andra viktiga beroenden, m.m.  DVS vi ska inte tejpa på ett vilt, farligt eller icke-genomtänkt sätt. 😊 Och om vi har en riktig lösning som är smidig skall vi naturligtvis tillämpa den.

Quickly lovar jag att komma till quick wins. Men först ett aber. Det riktiga målet med förändringsledning är bestående, positiv effekt – inte kortsiktig aktivering. (Det är inte för inte att vi hittar ”generate short-term wins” som steg 6 i Kotters 8-stegsprocess.) I denna blogg adresserar jag quick wins som ett viktigt element i förändring.  Quick wins ger snabbt resultat och rörelsekraft.  De kan ofta vara förlösande för en individ eller organisation. På samma sätt som att det första fem kilometersloppet kan möjliggöra målet av ett helt maraton, så kan vi nyttja quick wins för att etablera bestående förändring.

Definition quick win

En quick win är en förbättring som är synlig, kännbar på kort sikt och som kan levereras snabbt och enkelt. Tiden är alltid relativ, dock upplever vi på Onbird att effektiva quick wins bör ge påtagligt resultat inom loppet av 5-45 dagar. Ytterligare bör de upplevas ha låga kostnader och hög relevans till viktiga intressenter.

Varför quick wins?

Quick wins är effektiva för att de har en nästan oproportionerligt positiv kraft. De ger kredibilitet till förändringsinitiativet och individerna som leder det. Dessutom skapar de en chans för utvärdering och bevis. Följaktligen tjänar de som exempel som kan kommuniceras till förmån för det stora initiativet. Och de ger en psykologisk rörelsekraft till förändringsteamet som vi på Onbird ofta observerar.  En kraft av att förändringen plötsligt känns möjlig, samt en chans att fira och en anledning till att fortsätta.

Fem tips för quick wins

1. Identifiera och bestäm er

Brainstorming och planering för förändring är viktig… men får inte fastna. I syfte att identifiera snabba framgångar som möter ovanstående definition, agera kvickt. När ni har identifierat en mängd relevanta quick wins, bestäm er för en. Överväg framför allt förbättringens svårighetsgrad och effekt (se vår fyrfältare och planeringsmall nedan för hjälp). Därefter: gör ert val, fatta ett tydligt och offentligt beslut och…

2. Sätt igång, NU

Inga ”kom-i-form” artiklar förespråkar att du ska börja nästa vecka (kör bara kör!)  Och ni kan det kinesiska ordspråket om bästa tillfället att plantera ett träd? Således gäller samma här. Om det ska vara quick, sätt igång NU.

3. Minimera WIP (work-in-progress)

Collins har konstaterat att ”the enemy of great is not bad – the enemy is good”. På ett likartat sätt vill jag hävda att ”the enemy of quick is not slow – the enemy is WIP”. För mycket work-in-progress omöjliggör fokus. För mycket work-in-progress skapar seghet. Tillåt er själva därför att avgränsa scope, att avgränsa mängden arbete och möjliggör ett explicit fokus som gör er win quick.

4. Kommunicera framgången synligt

Syn är vårt främsta sinne för att förstå vår omvärld i förändring. Nyttja därmed sinnet genom att kommunicera resultat visuellt via Kanban-tavlor, termometer-diagram eller annan synlig och tangibel metod. Placera det visuella beviset ”mitt-i-rummet” där framsteg kan beskådas löpande av team och intressenter.

5. Kom ihåg kunskap och inlärning

Missa inte chansen att utöka kunskap och förbättra förmågor via quick wins. Börja med ny kunskap om en process, metod eller teknik. Prova något nytt. Och passa på att öka kunskap och förmågor genom att samla feedback från en quick win. (Även om det är en quick loss!?)  Är förändringen möjlig?  Vad ska startas/stoppas/utökas?  Hur maximerar vi effekten av det långsiktiga förändringsinitiativet?

Ett verktyg i förbättring

Sammanfattningsvis tillbaka till mitt aber. Det riktiga målet med förändringsledning är bestående, positiv effekt – inte kortsiktig aktivering. Quick wins bevisar snabbt att förändring är möjlig. De ger kredibilitet och skapar stöd bland intressenter. De frigör förändringskraft och skapar motivation. Identifiera dem och nyttja dem som ett kraftfullt verktyg för att stödja er förändringsledning.

Om Onbird

På Onbird tror vi på några enkla saker. Vi tror att organisationer idag sitter på en mängd outnyttjade förmågor. Vi tror också på att alltid sträva mot enkelhet. Vidare tror vi på att man först måste definiera vilket problem som man vill lösa innan man definerar lösningen. Slutligen tror vi att vi skapar mest värde åt våra kunder när vi hjälper dem att själva utvecklas och hitta lösningen.

Utifrån det har vi utvecklat en portfölj av tjänster, produkter och utbildningar som vi använder för att hjälpa våra kunder. I portföljen finns kunskap, produkter och lösningar baserade på kända ramverk. Men ramverken kan aldrig vara lösningen eller målet. De kan bäst användas som ett medel för att nå målet. Ibland kallar vi detta för ett ”agnostiskt perspektiv eller förhållningssätt” till ramverk.

Bland våra kunskapsområden erbjuder vi kompetens inom Agile, DevOps, Lean IT och ITSM och ingen av dessa är alltså slutmålet.

Vår webinarserie ”Vi blev agila, men inte bättre” fortsätter – vi droppar en ny episod i maj! 

Save the date!

25 maj klockan 08:15 – 09:00 

Teamen blev agila, men vad hände med dem runt teamen? Den här gången kommer vi titta närmare på hur ledare (både inom verksamhet och IT) lätt kan bli en bromskloss för teamens utveckling när de inte utvecklas i samma takt och riktning som teamen utan istället sitter kvar i gamla idiom och metoder/strukturer.

3 tips för dig som är ny som produktägare – direkt från vårt PO-forum!

Daniel från Onbird är facilitator för vårt PO-forum och sammanfattade lite från en träff nyligen. Mötets frågeställning – Hur får man som PO ett förtroende när man är ny på jobbet och inte ännu har den auktoriteten?

Gruppens svar:

• Skaffa kunskap i produkten!
  Det finns inga genvägar när det gäller ens egen produkt. Ska du kunna ta vettiga beslut kring produkten behöver du kunna produkten. Använd den själv. Boka in sittningar med experter. Läs dokumentation. Ställ frågor.
• Bilda förtroendekapital
  Som Produktägare handlar mycket om att balansera olika viljor och att få folk med sig – teamet, business owners, verksamheten, kunder, etc. Se till att bygga förtroende hos formella och informella ledare. Ställ frågor om deras förhoppningar och förväntningar. Rikta ditt budskap utifrån mottagare, en systemarkitekt och en säljchef vill antagligen höra lite olika saker. Jobba för att skapa förtroende så du sen får uppbackning för ditt arbete.
• Bli den agila experten
  Du kanske inte är bäst på produkten och du kanske inte har upparbetade relationer ännu, men du kan antagligen ganska lätt bli experten på själva metoden. Ta stöd av olika teorier, ramverk och best practices så som SAFe, Agile eller DevOps och luta dig mot allmänna ”sanningar” kring hur man jobbar med IT-förädling. Se dock till att du förstår principerna bakom så det inte bara blir agila floskler.

Känns ovan svårt så fanns ett överenskommet svar till – muta alla med fika! 😊

PO-forum träffas frivilligt, kostnadsfritt, online, och med en agenda som bildas av deltagarna. Övergripande syfte är att utveckla sig själv och rollen Produktägare genom ett utbyte med andra kunniga. Läs mer och häng på?

https://onbird.se/po-forum

Varför inte certifiera din PO-kunskap?

Vår tvådagarsutbildning Certifierad Produktägare är populär och rustar dig med praktisk kunskap och en certifiering i rollen.

Ett fåtal platser kvar för 18-19 maj – läs mer, se ytterligare datum och anmäl dig här!

Att mäta vår framgång är ibland svårt…

OKR, KPI, ABC och XYZ. Scorecards och datakuber och rapporter. Ibland blir det mycket. Och många mätningar. Det riskerar att bli mätning för att leverera siffror, som kanske inte ens läses utan som finns mer för rapportens egen skull.

Martin har skrivit 7 smarta tips för bra mätning – ta del av dem här.

Vi onbirds läser, lär oss och streamar…

Glad vår!

Årstiden är så välkommen – njut och skicka in era bästa tulpan- och vitsippefoton!

/Jeffrey, Martin, Daniel, Nathalie, Torbjörn och Karin

Covid-19-pandemin har för evigt förändrat vårt sätt att leva och arbeta. Maj-juni 2021 blickade Onbird framåt med hjälp av sina kunder.  Pandemin är inte över, och deltavarianten skapar ny osäkerhet.  Samtidigt syns fler och fler positiva tecken på en ny verklighet, nu till hösten 2021 samt framöver.

*** Uppdatering
Som bekant har Folkhälsomyndigheten beslutat för att ta bort de flesta restriktioner per den 29/9.
Enkätresultat nedan blir mer intressanta med hänsyn till det.  Låt oss nu vara glada och smarta tillsammans när vi återvänder till våra nya arbetsförhållanden!

Fler än 100 personer har besvarat fem frågor via en online–enkät och gett oss lite insikter i hur de ser på (arbets)livet efter lockdown.  Tack till alla som svarade!  Nedan sammanfattar vi och kommenterar deras svar.

Pandemi och effektivitet

Första frågan tar temperaturen på effektivitet.  Hur har den påverkats av pandemins arbetsförhållanden?

Generellt har svaren bekräftat en effektivitetshöjning – ett fåtal svarade mindre än tre-stjärnor, och 20% gav maximalt betyg: fem stjärnor. 

Mix av arbete hemma och på jobbet

Andra frågan riktades mot fördelning av tid hemma och kontoret när vi väl är åter till ”normala arbetsförhållanden”.

Framtidens mix är intressant.  Nästan 60% räknar med att arbeta 2-3 d/v hemifrån.  Knappt 80% säger samtidigt att de vill jobba 2d/v på kontoret.  Dessa beteenden kommer att påverka trafikmönster, efterfrågan på kontorsyta samt våra kommunikationsmönster (bl.a. del av gruppen i och del utanför rummet).  Med andra ord kommer vi fortsätta anpassa oss med nya mötesformer, samverkansmodeller och hur vi kommunicerar med varandra.

Bästa utbildningsmix – online eller IRL?

Tredje frågan handlade om mixen för optimal utbildning och inlärning.

Här ser vi också online-inflytandet.  Endast klassrums-utbildning (5%) verkar vara oss förbi, men endast online (9%) verkar inte heller vara grejen.  Så kallad ”blended learning” verkar vara framtiden. Nästan 50% ser gärna en 50-50 mix och hela 82% ser en mix av online-IRL som optimal.

Bästa tips/upplevelse av online-möten

Frågorna fyra och fem var fritextfrågor som har fått många roliga och intressanta svar.  Vi har grupperat sammanhängande svar för att kunna presentera helheten.

Mötesordning och reda bildas av svar såsom ”tydlig agenda/kallelse”, “håll tiderna” och “dokumentera beslut”.  Sådant gäller IRL också, intressant att det förblir viktigt online.

En Onbird-favorit, “kamera på” tar andra plats.  Några motiverar det med ”solidaritet”, andra vill säkerställa fokus (ej multitasking) och en påminde oss att ha ögon i kameran/på rätt skärm.  ”Enkelt men viktigt – resten funkar oftast bra då 😊”

Effektiv användning av tid är en hyllning till enklare att hitta tid med alla, inga restider och även möjligheten att kunna göra korta inspel i längre möten.  En programmerare  kommenterar ”…jag kan bara slå på mikrofonen och säga NU behöver jag hjälp!” 

Bra utrustning och bruk var en intressant samling av hur viktigt det är att mötestekniken fungerar. Kommentarerna hyllar bra headsets, kameror och här finns även en generell uppskattning för de många olika plattformarna för onlinesamarbete som existerar därute.  ”Att det utan tidigare erfarenhet har gått så bra som det gjort!” Det räcker inte dock bara att ha utrustning – flera har kommenterat att bra användning spelar roll – ”blurra bakgrunden”, ”använd handuppräckning”, ”stäng av stökigt bakgrundsljud” och såklart ”mute/unmute mikrofonen” har fått kommentarer.

Breakout sessions uppskattades av ett flertal, och såklart uppskattade folk ett geografiskt oberoende där alla kunde vara med. Slutligen uppskattades check-in och engagemangsövningar.  Det föreslogs quizzes, socialt snack och även aktivitetspauser för att röra sig (”Varför inte ha fem minuters gruppdiskussioner där alla måste gå runt bordet samtidigt som de pratar; eller hoppa jämfota eller vad det nu kan tänkas…”)

Det första jag kommer göra på arbetsplatsen är…

Fråga fem bekräftar arbetskulturens viktigaste ord och beteende…

Var skulle våra svenska arbetsplatser vara utan fika?  Utan tvekan totalt dominerande, nästan hälften av alla såg fram emot fika tillsammans.  Flera kommenterade hur de skulle parkera sig vid kaffeautomaten och prata med alla.  Och en saknade kvalitetskaffe från kontoret – ”Jag ska ta en myndighetskaffe från automaten!  Mmmmm!”

Övriga sociala uttryck tippar fika-kram-lunch-aw till nästan två-tredjedelar av vårt fokus efter lockdown.  Hinner vi jobba i höst?

Överraskande nog var många fokuserade på möblering (”se över planlösningen”) och flera verkade sakna sina skrivbord.  ”Jag ska pynta mitt skrivbord och höja det så jag kan stå igen.”

Anpassning till new normal finns framöver för många av oss.  Några insåg att online-möten ersätts med IRL-möten igen.  Några var lite krassare – ”Jag säger upp mig om arbetsgivaren inte är flexibel”.  Och några uttryckte en viss längtan och melankoli samtidigt – ”Jag kommer antagligen glömma bort vilket privilegium det är att träffa människor igen…”

Fortsättning följer?

Som bekant intar Folkhälsomyndigheten fortsatt aktsamhet i sitt råd till oss nu när hösten bringar skolstart och återkomst till vårt arbete.  Från våra kunder upplever vi en positiv försiktighet OCH ett behov av att arbeta vidare.  Efterfrågan på IT-tjänster och -kunskap förblir mycket hög, så vi på Onbird kavlar upp våra skjortärmar som före sommaren och levererar majoriteten av våra tjänster online.  Online kaffe har också sin charm (kontakta mig gärna, jag bjuder? 😊) och vi ser fram emot en närtid där IRL doseras in i högre grad.

Under tiden så väntar vi inte!  Vi har ett flertal online-specifika workshops som passar denna unika tid extra bra, och arbetar ständigt med er för att säkra bättre och bättre IT.  Kontakta oss gärna så berätta vi mera.

Tack igen till alla som bidrog till denna enkät!

Jag brukar konstatera att min hjärna klarar endast av att räkna till 1-2-3 och därefter blir det bara många.  På något sätt tyder det säkert på bristande fokus, begränsat tålamod, eller kanske svag utveckling av min temporallob.  Men så funkar jag… och enligt erfarenhet så fungerar många andra.  1-2-3-många…

Refinement av user stories (eller features/epics/krav…) är en konst och en viktig sådan i agilt arbete.   Syftet med refinement är ”finare user stories”, någon form av bearbetning där man filtrerar tills bara de tydligaste, mest konkreta, viktigaste och mest managerbara user stories trillar ut.

Vad har detta med 1-2-3-många att göra?  Jo, jag tänker 1-2- 3 filtren i refinement såklart.  Vilka filter skall vi nyttja när vi bedriver refinement?  Låt oss börja…

1 – ett FÖRSTÅ-filter

Kravbildens första form är ofta rätt grov. Man har en idé eller aning om förbättring. Eller kanske inte ens förbättring – det kan hända att allt man har är en problembild. Här krävs refinement och filterarbete.

FÖRSTÅ-filtret applicerar vi här för att bättre greppa vad saken handlar om. Här ställs många frågor mot kravet för att bättre förstå:

• Vad är problemet/möjligheten?
• Vem/vilka ska använda detta?
• Varför blir detta en förbättring? Vilket värde skapas om vi lyckas?
• Vilken nivå av prestandaförbättring krävs? Hur mycket mer?  Hur mycket snabbare?
• Vad är kontexten eller miljön för detta?
• Finns det garanti- eller icke-funktionella-krav som måste uppnås?
• Kan vi uttrycka detta som en user story eller value statement?

Filtrerar vi effektivt så trillar det ut svar från ovanstående, svar som syftar till att såklart förklara kravet och hjälpa oss att begripa dess syfte, kontext, och slutligen värde. Refinement helt enkelt. Utan ökad förståelse blir nästan all vidarebearbetning en gissningslek. Och med ökad förståelse, kan vi arbeta vidare och ta fram nästa filter…

3 – ett SIZING-filter

Det tredje filtret i refinement är sizing, det vill säga minimering eller slicing. Detta filter tvingar oss till att bryta ned kraven i ”bite size pieces”. Här styckar vi helt enkelt upp elefanten i bitar. Vi letar efter logiska gränser där vi kan dela upp kraven och det arbetet som krävs för att möta kravet. Helst vill vi att sizing resulterar i kravdelar som är små nog för att planeras in och levereras klart i EN leveranscykel (sprint).

Här kan man även slå ett slag för slicing techniques, där vi inte bara styckar upp i små delar, men i möjligaste mån försöker bryta ner så att resultatet är små delar som ändå står för sig själv och ger konkret värde. Slicing är en bloggpost i sig, men några typiska metoder att utgå ifrån är:

• Workflow – först utvecklar vi beställningsfunktion, senare kommer betalning
• Roll/användartyp – först fixar vi för kundtjänst, därefter för sälj, sedan finans
• Teknik eller device – först ordnar vi för PC, sedan för Mac
• Happy/unhappy path – låt oss utveckla en transaktion som är happy (inga avvikelser) innan vi hanterar unhappy paths (med avvikelser)

Refinements resultat av sizing-aktivitet ger oss hanterbara krav och därmed enklare planering och produktion.

1-2-3 refinement bringar klarhet

Kom ihåg nu att refinement-arbete med dessa 3 filter mot vår backlogg är inte en linjär process, men såsom allt annat agilt, cykliskt. Ökad förståelse skapar bättre prioritering som i sin tur möjliggör sizing. Eller var det så att sizing skapar förståelse som i sin tur möjliggör prioritering?  Eller prioritering till förståelse till sizing?  Svaret är ja, ja, ja – filtren samspelar, och filtrering på förstå-prioritera-sizing hoppar fram och tillbaka sinsemellan för att skapa bättre och bättre krav (refined user stories).

Refinement bringar klarhet och 1-2-3 filter klarar även min hjärna av. Filtreringsresultat syns konkret i form av tydlighet och ordning. User stories fylls på med innehåll, inklusive svar på förstå-frågorna. Vässad och dokumenterad prioritet läggs till, samt slicing där stora kort fördelas till hanterbara små. Det blir ännu bättre och bättre när de samspelar, dessa filtren 1-2-3.  Ta fram dem och testa själv att filtrera dig fram till en bättre backlogg!

Idag växer rollen produktägare i många organisationer, både i betydelse och komplexitet. Det agila ramverket har ett tydligt fotfäste som arbetsmetod för förändring, och därmed blir rollens utövning avgörande. Hantering av krav, produktförståelse och kommunikation är affärskritisk och produktägaren får lov att vara skicklig och aktiv. Saknas detta ser vi en försämrad värdehemtagning av agilt arbete. Verksamheten får helt enkelt inte ut så mycket som den förtjänar.

Under åren har vi på Onbird vandrat med hundratals produktägare och deras kollegor kring det som fungerar bra och mindre bra. Vi har besökt produktägarens fallgropar, samt hur en kan vända dessa till framgångsfaktorer. Inför denna sammanställning intervjuade vi ett antal produktägare om vilka deras största utmaningar är för att lyckas. Utifrån det samlade materialet kunde vi identifiera fem punkter där förbättringsarbete skulle ge tydliga effekter – våra ”Fem vanliga fallgropar för en produktägare”:

1. En otydlig produkt.
2. Produktägare är inte (delaktig) i teamet.
3. Produktägare drunknar i dev/teamet.
4. Oklarhet gällande produktens intressenter.
5. En okontrollerad backlog.

Vi vet att avsikterna är goda, men stigen är snårig. Trampa försiktigt!

Fallgrop nummer 1 – En otydlig produkt

Produkten är samlingspunkten för det agila teamet och en skicklig produktägares ögonsten. Hela poängen med teamets arbete är produktens förädling. Därför bör vi inte tåla en vag samling av system eller ett ständigt skiftande funktionsomfång som produktdefinition. Det är vitalt att produkten är tydlig och avgränsad. Kravställare från verksamheten skall kunna veta vart de kan rikta sina krav om förädling, och teamet skall veta vart de ska rikta energi och fokus.

Hur tydliggör vi produkten? Onekligen är detta en konst. Syftet med produkten är värde till verksamhet, så produktens värde måste framgå så tydligt som möjligt. Praktiska produktdefinitioner består också av ett produktnamn, system och konstruktionselement, samt funktioner som utförs. Lyfter man blicken skall även produktvision och roadmap formuleras som en riktning.

Få hjälp att definiera produkten med hjälp av vår produktcanvas-mall

Fallgrop nummer 2 – Produktägare är inte (delaktig) i teamet

Ett av agilitetens stora bidrag är att explicit identifiera rollen produktägare som en kritisk aktör i förändring. Teamet skall inte agera på egen hand, men i stället med en tydlig koppling till verksamheten. Produktägaren förkroppsligar denna roll och agerar som prioriterad representant av produkten i verksamheten och verksamheten i produkten.

Därför ÄR produktägaren en medlem i det agila teamet. Därför finns inte ett agilt team utan produktägare. Och därför skall produktägaren vara en aktiv deltagare i teamets agila arbete.

Här kommer vi inte med explicita mått eller moment, såsom t.ex. måste vara med minst 12h/v, måste vara med på alla ceremonier, måste godkänna varenda user story… Låt det dock räcka med ”mycket”. Produktägare skall vara ”mycket” med, och genomgående ”mycket” aktiv i den agila cykeln samt produktens framfart. Arbetet sköts inte med vänster hand här – teamet skall uppleva otvivelaktig närvaro och delaktighet från produktägaren. (Här kommer även frågan om var produktägarens lojalitet ligger när det uppstår konflikt mellan team och omvärld. Naturligtvis hos teamet säger vi, men det får lov att vara foder för ett annat blogginlägg 😊.)

Fallgrop nummer 3 – Produktägare drunknar i dev/teamet

Livet är en balansgång, och visst gäller det för produktägare också. Enligt ovan skall produktägare vara delaktig och aktiv i teamet… Samtidigt vill vi inte se en produktägare som drunknar kravdetaljer, teknik eller utvecklingsuppgifter. När backlog är väl förmedlad och en sprintplan har lagts, skall då utvecklingsteamet ta vid i produktion. Produktionsfasen är utvecklarens ”sweet spot” och här skall produktägare inte tassa för mycket. Återigen balansgång här – vi litar på utvecklingsteamets arbete – ingen detaljstyrning och vidta försiktighet med att komma med ständig förändring (ja, jag vet att vi är flexibla men …)

Under tiden utvecklingsteamet är i gång med sina underverk har produktägaren en chans att lyfta blicken till framtiden – refinement i backlog, förändringshorisonten och intressenterna.

Fallgrop nummer 4 – Oklarhet gällande produktens intressenter

Produkter finns inte till för teamets skull, men i stället för produktägare och verksamhet. I ovanliga fall kan produktägaren vara den enda primärintressenten, dock vanligast är att produktägare företräder en eller fler intressenter (eng. stakeholders) i verksamheten. Dessa intressenter är mottagare av produkten och dess värde och därför är det kritiskt att produktägaren upprättar kommunikation med dem.

Det här kan dock vara knepigt, särskilt i större organisationer och inom skalad agilitet. Vissa produkter kan få ett existensberättigande som liknar gamla möbler – de ska finnas där de står, men det är oklart varför. Därmed kan det lätt bli att det fortgår allt dyrare förvaltning och förädling, dock utan förankring i verksamheten. Andra produkter representeras lite slentrianmässigt av en verksamhetsledare här, en annan där och i sommarmånader av en tredje. Ytterligare kan en produkt helt sakna aktiv koppling till verksamheten. Alla vet att det är viktigt, men ingen vill ta i det.

I sådana fall blir det svårt för produktägaren. Förankringen som produkten kräver skall ha tydlig, namngiven representation i verksamheten. Annars riskerar produktägaren och teamet att börja skapa förädling utan mottagare, och då kan det bli tokigt med prioritering, funktionella features, värdedefinition, m.m.

Fallgrop nummer 5 – En okontrollerad produkt-backlog

Produktens backlog är verksamhetens och teamets samlingspunkt där produktens förändringskurs beskrivs. Här samlar vi idéer, stora som små, som tjänar som påståenden om värdeutveckling av vår produkt.

Vi på Onbird får ibland höra att ”det inte finns en backlog” men vi tror att situationen är lite annorlunda än så. Många krav på produkten brukar finnas. De är dock skrivna på post-its här, i ett Excel-blad där och förresten glöm inte ticketdatabasen där det också finns en massa kort. I andra fall kännetecknas idéer och visioner av oändligt prat, utan dokumentation, som aldrig riktigt blir någonting.

Produktägarens ansvar är att bringa ordning här. Samlingspunkten får skapas och samling får ske. När väl kraven är kända och samlade skall de helst uttryckas som user stories där värdet blir tydligt. Refinement drivs på här också, där kravet utvecklas med detalj, prioritering och värdet blir tydligare, och storleken på krav sätts på rimlig nivå.

Har du snubblat in på en av våra fallgropar?  Berätta mer på kommande webinar (se nedan) och/eller kontakta oss med feedback!

As a central figure in DevOps and IT improvement, Gene Kim has been involved in studying high-performing technology organizations during the past two decades.  His book “The Phoenix Project” (2013) is a fictional account of an IT organization struggling to survive the everyday challenges so many of us recognize.  And now in “The Unicorn Project”, Parts Unlimited is back and dealing with new and familiar challenges.

I had the pleasure of meeting Gene during the summer of 2019 at the DevOps Enterprise Summit London.  He describes his intent with the Unicorn Project to be re-confirming the importance of the DevOps movement to achieve better value from our IT investment.  Especially he wanted to focus in this book on the importance of the foot soldiers driving the important work – the developers and engineers at the heart of IT productivity.

Onbird’s Martin and Jeff with the author of The Unicorn Project, Gene Kim, at the DevOps Enterprise Summit in London 2019.

The Five Ideals

Central to the learning communicated by the book are the Five Ideals.  (Gene has even recently started the Idealcast, his podcast of discussions with other experts regarding how organizations compete and win.)  What follows is a summary of the Five Ideals.

The First Ideal: Locality and Simplicity

From the start of the book, the protagonist Maxine is confronted by a Parts Unlimited that does not display the First Ideal.  Instead answers and assistance are hard-fought, and Maxine is forced to book meeting after meeting, seek out vendors and colleagues, and wait in queue after queue to make any progress.  Possessing knowledge and the eagerness to produce IT improvement, her ability to create value for customer is severely limited by a number of internal hinders and bureaucracies.

Creating this difficulty is never an organizational intent yet happens so easily.  And these situations are often a result of scale.  The small gang of startup wizkids in the IT garage enabled speed and simplicity. The corporate IT department and band of outsourcing vendors seems to slow things way down with:

• Environments not allowing single/simple sign-on
• Architectural dependencies and incompatibilities between data and technology platforms
• Escalation procedures which force us to seek/await approval
• Technical- and/or skill-based bottlenecks
• Release schedules which force delays in deploying new value

How do we achieve/retain Locality and Simplicity?  Here I think of a lot of the lessons learned from Lean thinking.  We need to be diligent in not allowing the above bullet points to creep in.  Instead we need to lock arms and wills to ensure:

• Teams with cross-functional skills
• Local (easily accessed) resources with the mandate to create change
• Simplicity of architecture, including the allusive “highly cohesive, loosely coupled” services
• Automated change pipelines for test, integration and deploy
• Continual feedback loops and improvement in trimming the processes and eliminating waste

The Second Ideal: Focus, Flow and Joy

“Joy?” you ask.  “What does that have to do with efficient IT?”

Loads says the research.  In one of my other favorite IT books (from 1975?!), “The Mythical Man-Month”, author Fredrick Brooks reminds us of how technology is a creative, problem-solving medium.  And that the people that work with technology love to solve problems.  I.e., it brings them joy!

Similarly, Kim reminds us in the Unicorn Project that we need to set up work environments and processes which enable focus and flow, thereby making problem-solving and joy possible. And what are the hinders to this?

• Technical debt
• Interruptions, bottlenecks, incidents…
• Complexity (see the First Ideal)
• Wait times for funding, assistance, approval…

Many of us recognize the frustration associated with the bullets above – the Second Ideal reminds us of the importance of removing these points of frustration.  Much like the Scrummaster’s list of impediments, much (most?) of our work should be spent upon reducing impediments, thereby improving our production focus and flow.  And when we achieve this flow, joy is often the inevitable product.

The Third Ideal: Improvement of Daily Work

Here again we hear the lessons of Agile and Lean – feedback, retrospectives, Kaizen and continuous improvement.  All this is critical to maintaining speed and competitiveness.

Erik, the Sensei of the Phoenix and Unicorn books, even reminds us of the opposite of the Third Ideal, TWWADI – “The Way We’ve Always Done It”.  TWWADI is symbolized with rules and regulations, processes and procedures, rigid project plans, approval processes, strict separation of duties and more.  Each of the above adds to the coordination cost of work, drives delay and even conflicts with the First Ideal.

How do we fight TWWADI and support the Third Ideal?

• Increase feedback loops
• Give teams the resources to fix problems
• Prioritize solving technical debt
• Establish team authority and responsibility for improvement

Most of all, we need to lead our teams and organizations to make improvement in small steps an obvious, daily part of our work.  We need to establish that pursuit of perfection in order to create long-term, continuous value to our customers.

The Fourth Ideal: Psychological Safety

Much like joy, psychological safety might sound as if it has little to do with world class IT.  But if we  consider the opposite – what are the results of people that work in insecure, untrusting, unsafe work environments?  Perhaps we’ve seen it first-hand, but certainly it isn’t hard to envision that such an environment would adversely affect innovation, discourage exploration and risk-taking, and create a culture of blame and negativity.

Google’s Project Oxygen is referenced as a positive example here.  Launched over ten years ago, Google has monitored and measured how managers and leaders can create the work culture and environment that supports psychological safety.  Primarily they have set guidelines that teams:

• Do not embarrass, reject or punish someone for speaking up
• Address problems with “what is the cause?”, not “who”
• Commit to daily improvement (see the Third Ideal)
• Identify incidents as learning opportunities
• Teach each other continually

Much like productivity focus and flow, the Third Ideal reminds us that the right work environment is critical.  And if we create this psychological safety?  Sensei Erik sums it up – “You are in an organization where everyone is making decisions, solving important problems every day, and teaching others whay they’ve learned…  Your victory is inevitable.”

The Fifth Ideal: Customer Focus

One of my standing bad jokes during training sessions, is that the correct answer to certification questions is “Value to Customer”.  When in doubt, “Value to Customer”.  Therefore, it rhymes well for me that the Fifth Ideal is Customer Focus.

This ideal can easily become a bad joke in the wrong context.  We’ve all been hammered with customer value and IT-business alignment and customer first and digitalization and more and more…  At the same time, we see repeated examples of a gap between IT and the customer.

The Unicorn Project’s biggest challenges and most difficult decisions arise when addressing the Fifth Ideal. Primarily, Maxine and her IT colleagues must consider all the work and value they are providing, and then prioritize between core customer value and many other nice-to-haves.  True customer focus means prioritizing the machines, people, skills, softwares, projects, vendors and other components that provide ultimate value to the customer.  And like all prioritization, the real challenge is not adding prioritized items, but removing them.

Rather than summarize the complexity of the Fifth Ideal in a few more sentences, I’ll let it be a cliff-hanger incentive to read the book.  Suffice it to say that my bad joke is repeated.  Value to customer is certainly the correct answer.