Mer ljus på pipelinen ger bättre fart i växthuset

Din konkurrensfördel är inte dina idéer eller dina produkter. Din konkurrensfördel är kvalitén på din kod och hur snabbt du kan få ut den till användarna. Idéer är lätt att kopiera. Antingen är man först ut på marknaden och drar nytta av det eller så är man tvåa och surfar på ettans lärdomar och misstag. Vinnaren är per automatik ingen av dem. Vinnaren är den som snabbats kan iterera sina idéer i en föränderlig värld. Inte nödvändigtvis vare sig den som är först ut eller tvåa.

Det är när vi integrerar vi lär oss. Både hur systemet fungerar och vad kunderna tycker om vår produkt. Att snabba på lärandet är att ta ett aktivt beslut kring överlevnad i en värld som ständigt förändras.

The Continuous Delivery Pipeline i SAFe representerar förmågan att leverera ny funktionalitet till användaren ofta. Det vill säga att lära sig snabbare. I SAFe är den själva ryggraden i tågets värdeström. Den har nu blivit så pass central att den ses som en av fem nyckelkompetenser för Lean Enterprises.

DevOps, som är en del av pipelinen, har sedan tidigare i SAFe fått ett eget team i System teamet som ska driva upp den förmågan. Ett smart sätt att utveckla den IT-och kulturförmågan.

Men hur får vi hela pipelinen att snurra? Ett knep kan vara att använda ett Strategiskt tema för att höja upp (affärs)värdet av The Continuous Delivery Pipeline. I stor sätt alla företag oavsett inriktning och produkter skulle kunna sätta ett strategiskt tema kopplat till att utveckla pipelinen.

  • Default strategiskt tema för random tåg/portfölj: Develop The Continuous Delivery Pipeline
  • Alla team i tåget behöver bidra till utvecklingen av pipelinen
  • Continuous Delivery Pipeline = affärsvärde
    • Börja resonera kring Cost of delay. Vad kostar det oss om vi inte gör det? Vad kostar det oss om vi inte har förmågan att göra det?
    • Visualisera och attackera flaskhalsarna som uppehåller sig i pipelinen. De hindrar effektivt affärsvärde att nå marknaden. Klockan tickar …
  • Använd DevOps Health Radar för att identifiera organisationens förmåga och för att identifiera epics, features och enablers
  • Se Continuous Delivery Pipeline som IT-förmåga, metod (hypotesdriven utveckling) och förmåga till monitorering
    • Bygg kompetens och förmåga kring det

Idéer blir till hypoteser, blir till kod, blir till affärsvärde, blir till kunskap. Hur snabbt kan du iterera den processen? 

Risken med en riskworkshop är överhängande

När en anledning till att vi gör något är just att det ska göras är risken stor att resultatet inte leder oss framåt.

Så har jag flera gånger upplevt att riskworkshops initieras och genomförs, framförallt i vattenfallprojekt. Som en punkt i projektledarens checklista ligger att genomföra en riskworkshop. Den genomförs och resultatet hamnar i en Excel-fil.  Kort därefter ”arkiveras” riskerna och de aktiviteter som skulle mitigera eller förhindra riskerna likaså.  Och när projektet kör i diket (väldigt många IT-projekt kör i diket) är orörda gamla och nya risker en del av orsaken.

Det svåra behöver inte vara att se risker utan att leva med dem och agera på dem.

Med agila metoder med Lean UX och Lean-agile-principer finns bättre förutsättningar att kontinuerligt hantera risk. Genom att validera med användare tidigt, visualisera i hela utvecklingsprocessen inte bara som metod utan också som ett sätt att kommunicera och att styra om snabbt (pivot to change) visualiseras och hanteras risker löpande. ”Validate the innovation with customers, then pivot without mercy or guilt when the hypothesis needs to change.” 

Utifrånperspektivet som användarcentrerad utveckling hjälper oss att ha är också en nyckel till att se och agera på risk. Vi har en förkärlek för inifrånperspektivet något som suboptimerande vattenfallprojekt inte automatiskt utmanar oss att hantera.

Om vi har problem att identifiera risker finns alternativa metoder till den traditionella riskworkshopen.

Daniel Kahneman beskriver en metod i hans bok ”Tänka snabbt och långsamt” som kan hjälpa oss att tidigt se och agera på risker. Han refererar till en metod som heter ”Pre mortem”. Den går ut på att samla sakkunniga (ta teamet och stakeholders) och be dem att utföra följande ”Tänk er att det har gått ett år. Vi genomför den plan som nu föreligger. Utfallet blev katastrofalt. Ta nu fem-tio minuter på er att skriva en kort berättelse om katastrofen.”

Pre mortem övningen har två fördelar skriver Kahneman: den motverkar det grupptänkande som drabbar många team när ett beslut verkar vara taget och den ger fantasin hos sakkunniga personer en skjuts i rätt riktning.

Övningen gör det enklare för de som har tvivel att komma till tals. Och de som inte ser några risker utmanas att undersöka om det finns möjliga hot som de kanske har förbisett. Formatet berättelse passar också bättre att sprida och kommunicera än risker i en excel-fil.

Att utveckla är en hypotesdriven process och i sakens natur ligger det att komma upp med “fel” svar. ”Fail fast and learn” är ett viktigt mantra. Demo varannan vecka, skissa som kommunikation, uppmuntra initiativ och beslut på golvet och validering med användare tidigt hjälper oss att se och hantera risker nu, inte vid nästa beslutspunkt som i vattenfallsprojekt.

En bock i en checklistan ”vi har haft en riskworkshop” är en risk i sig. Undvik den med motiverade team, modernt ledarskap, agila-principer och Lean UX.

Ständigt lärande på bredden skapar djup

SVT-play kan man ett tag till se Bruce Springsteen berätta om inspelningen av The River.

I dokumentären berättar Bruce Springsteen att han ”plöjde historieböcker för att kontextualisera sig själv, sätta sig själv i ett sammanhang”. Något som även Jan Gradvall uppmärksammade i en artikel.

För att skapa berättelserna som ”The River” innehåller läste alltså Bruce Springsteen historieböcker. Det visar på hur vi kan ta del av en berättelse för att berätta en annan. Hur vår plats i livet hör ihop med tidigare och framtida berättelser. Ordet genom berättandet är lika gammal som människan. I berättelsen gömmer sig kunskapen och lärandet. Berättandet har alltid varit med oss – från mimande och dans till dagens multimediala berättelser. För att utveckla berättelsen behöver vi ta del av mer berättelse. Och det är när vi läser, lär och berättar vi utvecklar oss.

det är när vi läser, lär och berättar vi utvecklar oss

Vikten av bildning och det livslånga lärandet är centralt i ramverket för Lean-Agile och i Daniel H Pinks teorier kring drivkraft och motivation. Och inte minst betydelsen av att lära på bredden. Redan under antiken talades det om den breda utbildningen, de fria konsterna (Liberal arts education) i motsats till yrkesinriktade ämnen. Facebookgrundaren Mark Zuckerberg är exempel på en klassisk liberal arts-student, där utbildning inom datakunskap och psykologi har varit bidragande till hans verk. Bruce Springsteen anammar också liberal art i sitt arbete med The River.

Björn Wiman skriver en krönika i DN på ämnet  och refererar till Fareed Zakaria bok ”In defence of a liberal eduaction”. I den boken argumenterar Zakaria för den breda utbildningen. ”Liberal arts-studenter kan sätta samman kurser i historia och fysik; målet är inte att uppnå en specifik yrkesutbildning, utan att möblera medvetandet; att lära sig att tänka.”

Poängen med Liberal arts education är att den breda humanistisk utbildningen är ett bra upplägg för framtidens alltmer automatiserade och ombytliga arbetsmarknad, där skräddarsydda färdigheter snart riskerar att bli obsoleta.

Ständigt lärande på bredden ger generella kunskaper på djupet.

The kids are agile

När vi föds är vi av naturen nyfikna och självstyrande. Vi föds med egenskaper som passar bättre i en agila processer och Lean UX än i hierarkiska strukturer och vattenfallprojekt.

Sen händer något när vi blir vuxna som kväver många av de drivkrafter som är synonyma med innovation och kreativt arbete. När vi kommer ut i arbetslivet riskerar vi att falla in i passivitet och tröghet. Men det är inte vår naturliga läggning som speglas i det beteendet. Passivitet och tröghet kommer inte från den enskilda människan de kommer från strukturer och gamla sanningar i organisationer och i samhället som hackar vår naturliga approach av nyfikenhet och drivkraft.

Därför finns det mycket att lära av barnen. Men även att tänka på kring hur barnen bör få fortsätta att lära. Detta handlar inte om analogt eller digitalt. Det är inte kanalen som är utmaningen eller lösningen. Det handlar om hur vi förhåller oss till problemlösning, nyfikenhet och motivation. Hur vi förhåller oss till barnen och till barnet inom oss.

Barnens sätt att se på världen passar väldigt bra in i Lean UX och i agila metoder. Inom Lean UX uppmuntrar vi tex en kontinuerlig loop av att bygga – mäta – lära. Processen i Lean UX prioriterar byggande av en testbar iteration av produkten (en MVP) så snabbt som möjligt för att testa antaganden och hypoteser. Lean UX förespråkar också att komma bort från leverabler och detaljerad information som inte leder arbetet med produkten framåt. I Lean UX ersätter snabba metoder som skisser och visualisering i grupp, detaljerade skisser och teoretiska användarfall.

Ett barn arbetar redan så. Ett barn som bygger ett sandslott itererar ständigt sin ”produkt”. Det är en kontinuerlig bygga – mäta – lära – process. Barnet arbetar naturligt och omedvetet enligt principen: ”Det jag lärde mig i första iterationen tar jag med mig in i nästa iteration”. Bygga sandslottet – betrakta det – riva det. Bygga sandslottet – betrakta det – riva det … Osv.

Färdigpaketerade upplevelser som till exempel teve, många spel, byggsatser med detaljerade instruktioner och pussel är i sitt fundament byggda för att passa in i en styrd projektmodell där leverabler styr över experimenterade och lärande. Det är egentligen inte artefaktens fel, tex pusslet, utan hur vi förhåller oss till det (eller låter barnet förhålla sig till det). Uppmuntra inte resultatet att pusslet är lagt – uppmuntra strategin som ledde fram till ett resultat (inte nödvändigtvis att pusslet är färglagt). Ett pussel bygger på att resultera i målet färdiglagt – inte till något resultat. Lean UX premierar outcome före output. Dvs inte antal lagda pussel eller hur snabbt det gick utan vad vi lärde oss och vilket resultat det fick. Alltså själva resultatet av att interagera med pussel.

Den acceptans vi har kring att våra barn får göra fel i lärandet måste finnas även i organisationen. Att utveckla är en hypotesdriven process och i sakens natur ligger det att komma upp med “fel” svar. ”Fail fast”. Uppmuntra därför kommunikation och resonemang. Att ställa frågan varför i grupp är något av det viktigaste vi kan lära oss av barnen och ständigt påminna oss själva om att fortsätta göra.

”Den avgörande friheten för kreativa grupper är friheten att experimentera med nya idéer. Vissa skeptiker hävdar att innovation är dyrt. I långa loppet är innovation billigt. Medelmåttighet är dyrt – och självstyrning kan vara motgiftet.” Tom Kelley, Ideo

Tyvärr uppmuntrar sällan traditionella organisationsstrukturer en lärandeprocess. I de miljöerna bygger chefskap på att kontrollera medarbetarna. Chefen agerar i tron att medarbetaren behöver en knuff för att komma igång och att vi utan en morot skulle stå kvar utan att vilja leverera.

Ett barn behöver inte en chef. Ett barn har större nytta av en coach och en facilitator. Precis som vi i agila metoder hellre pratar om coachning och facilitering före chefer och projektledare. Genom att flytta ner beslut på golvet har hierarkier spelat ut sin roll.  Beslut på golvet kräver mod, transparens och förtroende i organisationen. I en föränderlig värld och i en agil process som uppmuntrar snabba iterationer behöver ledaren kunna improvisera. Och inte minst därför behöver ledarskapet vara på plats i teamen. Chefen bestämmer på håll. Ledaren faciliterar på plats och tillsammans bestämmer vi vägen framåt.

Det finns mycket att lära av hur barnen tar sig an ett problem. Genom att visualisera, kommunicera och facilitera i leken kan vi tillsammans med barnen lära. Följande experiment gjorda med en 3-åring och en 5-åring bygger på att på barnens villkor i en lärande process utveckla en ”produkt” och samtidigt se hur likt det sättet som barnen tänker och agerar passar in i en Lean UX-process.

Experiment – The kids are agile

Initiativ: Bygga en landningsbana.

Features:

  • tydligt markerad landningsbana
  • lampor drivna av batteri
  • en taxi-bana
  • en helikopterplatta
  • stretch-goal: ett flygledartorn

FullSizeRender1

Iteration 1: Visualisera vad vi vill göra i en första skiss (till vänster i bild). Lärdom: Skissa tidigt!

Iteration 2: Bygg en MVP. Vi börjar med att dra elen medvetna om att vi gör det innan vi målar. Vi vill testa vår hypotes: kommer lamporna att lysa och i så fall i olika färger? MVP:en bevisade vår hypotes! Och eftersom vi bland annat använder oss av en LED-list med RGB-lampor lär vi oss färglära på köpet.
Lärdom: En MVP leder oss framåt.

FullSizeRender4

FullSizeRender13 FullSizeRender14

Itererar själva skissen. Skissa, skissa om. Visualisera och kommunicera med hjälp av skissen. “En lampa kräver att elen snurrar runt utan att brytas – det ser vi i skissen – det visar verkligheten baserat på skissen.”
Lärdom: Kommunicera med skisser. Alla kan skissa.

 FullSizeRender2

Redo för nästa iteration: måla. Hur ser en landningsbana ut egentligen? Kan de se olika ut? Introducera omvärldsanalys. Ipaden är ett perfekt verktyg för det.
Lärdom: Omvärldsanalys och ständigt lärande är kul!

FullSizeRender3

Utgå från skisser och verkligheten (bilder i iPaden). Att maska med tejp blir lättare att förstå då.
Lärdom: Kravspeca med bilder.

FullSizeRender5

Det vi maskar målar vi inte …

FullSizeRender6

Ta bort masken.

FullSizeRender7

Hur målar vi “H” på helikopterplattan? Genom att inte måla det. Dags för nästa iteration.
Lärdom: Iterationer tar oss framåt.

FullSizeRender8

FullSizeRender9

Det vi maskade är nu våra streck och bokstäver på landningsbanan.

FullSizeRender10

GOOB – get out of the building. När vi besökte flygplatsen lärde vi oss att det är röda lampor högst upp i flygledartornet.
Lärdom: Ta dig ut i verkligheten! 

FullSizeRender12

Dags att dra elen igen. Nu går det fort eftersom vi har med oss det vi lärde oss i första iterationen i vår tidiga MVP.
Lärdom: Seeing is believing!

FullSizeRender11

Redo för takeoff. Grönt betyder starta, rött avvakta och blått tanka, har 3-åringen bestämt.
Lärdom: Att leka slår allt!


 

Böcker och länkar som har inspirerat bloggposten:

The kids are agile

When we are born, we are naturally curious and autonomous. We are born with characteristics that fit better in an Agile processes and Lean UX than in hierarchical structures and waterfall projects.

Then something happens when we become adults that stifles many of the drivers that are synonymous with innovation and creative work. When we begin our worklife, we risk falling into passivity and inertia. But it is not our natural disposition that is reflected in that behavior. Passivity and inertia does not come from the individual, it comes from structures and old truths in organizations and in society as a hack upon our natural approach of curiosity and drive.

Therefore, there is a hole lot to learn from the children. But also to think about when it comes to how the children should be allowed to continuously learn. This is not about analog or digital. It is not the channel that is the problem or solution. That is how we relate to problem solving, curiosity and motivation. How we relate to the children and the child within us.

The children’s way of viewing the world fits very well into Lean UX and agile methods. For example in Lean UX we encourage a continuous loop of building – measuring – learn. The process in Lean UX gives priority to the construction of a testable iteration of the product (an MVP) as quickly as possible to test assumptions and hypotheses. Lean UX advocates to get away from the deliverables and detailed information that is not leading the work with the product forward. In Lean UX rapid methods like sketches and visualization in a group replaces detailed sketches and theoretical use cases.

A child is already working in that way. A child that builds a sand castle iterates its “product” all the time. There is a continuous build – measuring – learning– process. The child works naturally and unconsciously according to the principle: “What I learned in the first iteration, I take with me into the next iteration.”

Packaged experiences such as TV, some games, construction kit with detailed instructions and puzzles is in its foundations built to fit into a managed project deliverables model where experimenting and learning is set aside. It’s not really the artifacts fault, such as the puzzle, more how we relate to it (or allows the child to relate to it). Do not encourage the result that the puzzle is done – encourage the strategy that led to a result (not necessarily that the puzzle is done). The goal with a puzzle is the result (=it is done) but the learning goal is any result and the way to it. Lean UX reward outcome before output. That is not the number of laid puzzle that we premier, but what we learned and what results it had. Thus the result of interacting with the puzzles.

The acceptance with making mistakes we have with our children in the learning process must we also have in in the organization. To develop is a hypothesis-driven process and in that nature we will come up with the wrong answer from time to time. “Fail fast”. Encourage therefore communication and reasoning. To ask the question why in the group is one of the most important things we can learn from children and to remind our self to continue to do.

Unfortunately, traditional organizational structures rarely encourages a learning process. In those environments the leadership is based on controlling employees. The boss act in the belief that employees need a push to get started, and that the employee need a carrot to move forward.

A child does not need an old school manager. A child has a greater benefit of a coach and a facilitator. Just as we in agile methods rather talk about coaching and facilitation instead of managers and project managers. By moving down decisions to the floor, hierarchies have played out their role. Decisions on the floor requires courage and trust in the teams from the organization. In a changing world, and in an agile process that encourages rapid iterations, the leader need to be able to improvise. And not least the leadership needs to be in place near the teams. An old school manager decides from a distance. The coach facilitates on the floor together with the team. And in the team we determine the way forward.

There is much to learn from how the children take on a problem. By visualizing, communicating and facilitating in the play, we can learn together with the children. The following experiments made with a 3 year old and a 5 year old is based from the children’s perspective with focus on the learning process with the goal to develop a “product” and at the same time see how similar the way children think and act is to the process of Lean UX.

Experiment – The kids are agile

Initiative: Building a runway.

Features:

  • An airstrip
  • lamps powered by battery
  • a taxi-runway
  • a helicopter landing area
  • stretch-goal: a air traffic control tower

FullSizeRender1

Iteration 1: Visualize what we want to do in a preliminary sketch (left in the picture). Lesson learned: Sketch early!

Iteration 2: Building a MVP. We start by drawing electricity aware that we do it before we paint. We want to test our hypothesis: the lights will shine and if so, in different colors? MVP: proved our hypothesis! And partly because we use a LED strip with RGB LEDs, we learn color theory.
Lesson learned: MVP leads us forward.

FullSizeRender4

FullSizeRender13 FullSizeRender14

Iterates the sketch. Visualizing and communicating with the help of sketching. A new day means a new sketch. “A lamp requires electricity that spinning around without being broken – that we see in the sketch – and the reality show the same.”
Lesson learned: Communicate with sketches. Everyone can sketch.

 FullSizeRender2

Ready for the next iteration: paint the airstrip. How does a runway look like? Can a runway look different? Introduce intelligence. The iPad is a perfect tool for that. Image google: airstrip.
Lesson learned: Use the iPad to seek more knowledge. Contextual analysis and continuous learning is fun! 

FullSizeRender3

Look at the sketches made and use inspirations from outside (images in the iPad). Lesson learned: Knowledge is everywhere.

FullSizeRender5

Where the tape is there will be no color …

FullSizeRender6

Remove the tape.

FullSizeRender7

How do we paint “H” on the helipad. By not painting it. Time for the next iteration. Lesson learned: Small iterations take us forward.

FullSizeRender8

FullSizeRender9

Where the tape was our lines and letters now are at the airstrip.

FullSizeRender10

GOOB – get out of the building. When we visited the airport we learned that there are red lights at the top of the control tower. That we dit not know before.
Lesson learned: Get out in the reality! GOOB!

FullSizeRender12

Time to install the electricity again. Now it is done fast and accurately because we have with us what we learned in the first iteration of our first MVP.
Lesson learned: Seeing is believing!

FullSizeRender11

Ready for takeoff. “Green means start, red means wait and blue means refueling”.
Lesson learned: Play and learn is fun!


Books and links that have inspired the blog post:

Ständig förbättring börjar med att lansera

En av hörnstenarna i LEAN är ständig förbättring. Kopplat till användarupplevelsen kräver ständig förbättring förstås att vi lanserar produkten eller tjänsten till användaren. En fälla många går i är att vilja bli “klar” innan man lanserar. Eller att fastna i viljan att realisera den absolut, på pappret, bästa idén.  Men om vi inte lanserar, finns det inget att förbättra. Det är först när användaren har börjat använda våra produkter och tjänster vi får riktig data att analyser och som gör att vi kan utvärdera och förbättra produkten. Utmaningen är alltså att våga lansera tidigt. Att inte se de digitala kanalerna som en trycksak som måste bli helt klar innan lansering.

Ett sätt att driva produkten mot lansering tidigt är att arbeta med MVP:er (minimum viable product). En MVP har bara de centrala funktioner som är absolut nödvändiga för att den ska fungera för användaren. Poängen är att en MVP snabbt kommer ut och snabbt kan testas på riktigt. En MVP fungerar end-to-end, dvs användaren kan interagera och slutför någon del i produkten tex köpa en vara men alla de funktioner som finns i backloggen är inte med.

Vi vet ju först när produkten är lanserad vilka funktioner användaren vill ha.

Jämför med när första versionen av iPhone kom och funktionen för att skicka MMS inte fanns med. För Apple var det viktigare att släppa produkten och få feedback tidigt än att släppa en bredd av funktioner.

När en MVP är släppt börjar den ständiga förbättringen. Då kan utvecklingen gå över mot MVF (minimum viable function). Att se sin produkt och tjänst som en uppsättning funktioner gör det enkelt att dela upp arbetet i sprintar, prioritera utvecklingen och testa och utvärdera de specifika funktionerna mot användaren. Oftast utspelar sig slaget om användarna och kunderna bland funktionerna Hur enkelt är det egentligen att fylla i kontokortsuppgifterna, går den funktionen att göras bättre? Hur enkelt är det att söka på sajten, kan den funktionen utvecklas?

Se dina digitala produkter och tjänster som uppbyggda av en mängd små funktioner. Släpp funktionerna tidigt och utvärdera dem tillsammans med dina användare. Före lansering i användartester och efter lansering med data analys.

Men lansera tidigt – för ständig förbättring börjar med att lansera.