Blogg

Konsten att fånga en fisk - eller gapa och bli matad

  • 18 april 2016
  • 0

Utgångspunkten för denna text var vikten av självstyre i ett team, individuellt eller i ett större sammanhang och varför det är bättre att ha ett fiskespö än att bli serverad fisk. 

Artikelverktyg:

Lite extra, massor med extra?

Vi lägger väl på lite extra? Det vore dumt om det inte fanns något att göra. Kanske planera in lite mer utifall att. Så är det lätt att tänka, jag har själv gjort det av olika anledningar. Har man mycket att göra kan tiden gå fort och man känner sig behövd. De i ens team efterfrågar en och ens kunskap och expertis vilket kan vara tillfredsställande. Så det finns många anledningar till att man faktiskt vill ha kalendern fullsmockad och fyller inte ett projekt upp tiden så lägger man på fler projekt. Sen åker man hem från jobbet och då kan det se ut så här: 

Det som nyss kändes så bra och positivt, en hög nyttjandegrad/beläggningsgrad med massor av extra känns med en gång som ett slöseri av tid. Mycket som händer men väldigt lite som rör på sig. 

Om man bortser från att man ofta planerar in för ett bästa utfall som aldrig inträffar. Och om man bortser från att man alltid kan göra lite mer (refaktorisera koden, göra de sista testerna med lite annan data, uppdatera dokumentationen, slipa på hur vi beskriver behov och constraints..). Och om man bortser från att det dyker upp några "det här tänkte vi inte på" och att folk blir sjuka eller vabbar. Ja om vi bortser från allt sånt utan det råkar vara en solig dag i Nangijala.. Tänk om det då uppstår lite slack?

Slack i vardagen

Slack kan vara ett negativt laddat ord, i stället kanske man borde säga kvalitetstid, tid för oförutsedda händelser eller för innovation.

Jag använder mig av slack i mitt system som består av saker som jobb, hus, barn och andra aktivteter. När man ska iväg på morgonen och ungarna gömmer sig i ett skåp eller inte vill ta på sig sin vinteroverall är det lätt att känna stress för att man borde sitta på sin kontorsstol vid det här laget. Barn känner av att man är stressad och sur och blir inte lättare att komma överens med vilket gör att det tar än längre tid att lämna dem. Då får man ta igen den tiden på kvällen, men då var det ju möte med styrelsen för föreningen? Och rapporten därifrån borde ju skrivas på kvällen sedan men om jag istället prioriterar bort träningen i morgon så kan jag jobba ett par timmar då. Så tid som kunde lagts på att få gjort något går åt till att planera om och saker med låg cost of delay skjuts på framtiden.

För att slippa hamna i sådana situationer har jag gått ner i arbetstid (något man kan göra när man har små barn) så jag jobbar 90% vilket ger 4h slack i veckan. Alltså jag tänker mig att jobba 100% vilket är det jag planerar efter, hade jag planerat efter 90% hade jag ju bara haft kortare arbetstid?! En solig dag i Nangijala jobbar jag därför 100% men när det regnar sill från himlen har jag utrymme att inte behöva stressa iväg ungarna eller kan hämta dem en timme tidigare. Det värsta som kan ske av lite slack i det här fallet är att barn får umgås lite mer med en förälder som inte är stressad. Och att jag kan göra det jag planerat på kvällen oavsett om det är träning eller att jobba lite extra.

Slack for innovation

Hur kan ett företag som utvecklar mjukvara använda sig av slack? Det finns flera exempel varav Google är väl det mest kända. Detta var förvisso innan de var 50.000 anställda och innan de splittade företaget i en alfabetssoppa.

Googles idé med 20% tid att göra "vad man vill" (med en nypa salt) är välkänd och Gmail är en produkt som brukar lyftas fram som något som tillkom under innovationstid. Försöker man vara för effektiv med sin beläggning så finns det inget utrymme för flexibilitet och innovation utan oftast bara tid för att vara väldigt upptagen. 

När huvudet är fullt av en lång rad uppgifter som måste göras (gärna igår) är det svårt att tänka mer kreativt. Det lättaste är att göra det som står på papperet, no more no less och sedan gå vidare till nästa uppgift. Det kan så klart bli bra resultat men det blir så mycket svårare att göra något bättre eller att göra något lite annorlunda (lite som beskrivs i Candle problem). Det är däremot på fritiden, i duschen, på väg till fjällen eller när man sover som hjärnan arbetar för att lösa saker och gör så att vi kan gå till jobbet med nya perspektiv.

"In the breaks, that’s where the ‘aha moment’ comes" - Brigid Schulte
Overwhelmed: Work, Love, And Play When No One Has The Time

Det är värt att tillägga att för mycket slack kan också vara negativt vilket gör att vi får en inverterad U-formad relation mellan slack och innovation - Is Slack Good or Bad for Innovation?, Nitin Nohria och Ranjay Gulati.

Slack - ekonomiskt värde

Det finns även ett ekonomiskt värde i att se på slack time som Pawel Brodzinski beskriver rätt bra i Economic Value of Slack Time. Att ha en lång ledtid kan vara bekymmersamt och dyrt i många fall. Tiden det tar att få igenom saker genom vårt system kan fördubblas när beläggningen går från 80% till 90% och fördubblas igen mellan 90% och 95% så det gäller att hitta den mest optimala nyttjandegraden.

                                                         Pawel Brodzinski on Software Project Management

I mitt pappa- och arbetsliv har jag funnit att 4h/vecka fungerar bra för oplanerade aktiviteter. För vissa organisationer och i vissa sammanhang är mer tid bättre, för andra mindre och det kan säkert skilja sig från tid till tid. 

När vi har väldigt mycket att göra måste vi dessutom snabbt skynda vidare till nästa sak. Risken att vi gör något fel och inte hinner tänka efter ökar när nyttjandegraden ökar och detta är att bita sig själv i svansen. Förmodligen kommer det vi gjorde igår tillbaka som ett brev på posten och vi måste trycka in saker som behöver rättas till och göras om.

Intressant i den här kontexten är även The Principles of Product Development FLOW av Donald Reinertsen, hur man optimerar för flow och inte för utilization.

Att servera en fisk

Kan man då be folk att göra vad de vill när som helst och då kommer kreativitet och innovation att frodas? Hur ska man veta vad som behöver göras och varför? Vissa förutsättningar kanske behöver finnas på plats för att man ska kunna göra bra saker som tillför värde under innovations- och kvalitetstimmar?!

Ibland får vi en mer eller mindre färdig och välformulerad kravspec att gå efter, en big design up front. Detta är vanligare i vattenfallsprojekt där någon tidigt har låst olika sorters krav vilka blir till en lång rad med uppgifter som ska utföras. Teamet blir serverade en hög med fisk, kanske till och med ett stort stim av fisk som påminner om den fullsmockade vägen ovan. I det här fallet är vi många som har svårt att tillföra innovation och kreativitet och att hantera förändingar/förbättringar som vi anser skulle tillföra mer av värde. Vi gör det som står i beskrivningen så gott vi kan men det är svårt att se vad som kan göras ännu bättre om vi inte förstår sammanhang, behov och kontext.

I agila metoder som kanban och scrum är självstyre en viktig del. Vårt tvärfunktionella team består av folk som har kompetens att fatta beslut hur vi bäst bygger mjukvara som tillför värde åt kunden. Produktägaren bör ha en vision för det vi bygger och vi ska förstår syftet och kundens domän. Detta gör det så mycket lättare för teamet att kunna bidra med sin kunskap och att komma på kreativa lösningar. Det är här heller ingen som blir tilldelad en hög med uppgifter som lägger sig på kö, vi använder oss av ett pull-system (till skillnad från ett push-system) och kanske även WIP limits så att vi inte skapar en igenkorkad motorväg. Förhoppningsvis får vi ett bra flöde av saker som går igenom vårt system utan att skapa proppar. Förhoppningsvis tilldelar vi inte varandra uppgifter och  krav som låser oss tidigt till något förutbestämt som någon mastermind klurat ut (Vi behöver skifta från kravställan till behovsställan - Mia Kolmodin).

Om vi dessutom använder oss av bra user stories, behov, constraints med mera för att förstå och kunna skapa värde så är det större chans att teamet självt kan hitta det bästa fiskevattnet och inte väntar på att få en BDUF i knäet.

"Many believe that user stories are the new requirements because there has to be requirements for a project, right? I give that a double “no”, they are not requirements and that is not anything we really need. User stories are about being able to explore options and seize opportunities. Requirements are about deciding up front and sticking with that." - User Stories are not requirements, Per Lundholm.

Att skaffa sig ett fiskespö

Ett team får inte förklarat för sig exakt vad de ska göra oavsett om det är ett projektteam, produktteam eller alla på ett helt kontor. Vad teamet i stället får förklarat för sig är i stil med följande: "Vi har för avsikt att nå detta mål, vår vision är den här, vi är lite för långt ifrån kontexten för att ha x,y och z som krav. Berätta för oss löpande hur det går så anpassar vi oss allt eftersom".

Vi kan inte ha som uppgift att göra vad vi vill och så händer det magiska saker utan att vi förstår de strategiska avsikterna med projektet/produkten, då är det stor risk att vi bara skapar kaos. 

Som Steven Bungay skriver i boken The art of action:

"In Order to Have High Autonomy, High Alignment is Needed. To have High Alignment, Strategic Clarity is Needed.

The Organization is Not a Machine, But an Organism, a Set of Human Relationships." - Steven Bungay

Så självstyre är ingenting som kommer av sig självt. Även det andra stycket är intressant, vi arbetar inte som vid ett löpande band eller är små kuggar som man kan flytta runt. Trots att vi jobbar med teknik så är mänskliga relationer och hur vi jobbar som ett bra team av största vikt. Och än så länge är det svårt för en maskin att göra något kreativt av ett fiskespö.

Vad Steven Bungay skriver stämmer även bra överrens med vad Dan Pink säger om motivation i sin bok Drive. Vi motivas av följande:

  • Autonomy
  • Mastery
  • Purpose

Så bortsett från att vi vet vad vi ska göra blir vi även med självstyre och syfte motiverade till att göra det. Två feta flugor i en smäll kan jag tycka.

The man in the middle

Så för att teamet/individen ska vara mätt för all framtid så behöver produktägare, ledning, chefer och andra ge teamet förutsättningar för att gå ut och tälja sig ett fiskespö så att de sedan själva kan dra upp sin böckling (eller torsk eller makrill, teamet har kompetens att besluta). 

Men det finns även andra som kan bidra till gynsamma förutsättningar, de med djup kunskap och expertis inom ett område eller de som sitter med viktig information som ingen annan har. De som ibland blir satta ostörda i ett rum långt bort för att skapa magi utav det de är bra på eller de som sitter som en spindel i väldigt många nät. Detta kan vara personer som många saker bör passera för att kvalitetssäkras eller för att det ska till någon trollkarlskonst som endast de behärskar. Det kan dock skapa en rejäl flaskhals i vårt system och då spelar det ingen roll hur bra flyt vi har innan och efter detta sker. Vi kan suboptimera ihjäl oss för att få en bra start eller ett bra avslut men systemet i stort kommer inte att påverkas.

Så istället kan dessa människor, som kan vara grymt duktiga på vad de gör, hjälpa andra att förstå och lära dem att bli lika duktiga. Det är ju denna del på vår motorväg som ibland bromsar in oss och blir det fler som kan hjälpa till att slussa vidare så får vi ett bättre system. Den som lär ut blir allt som oftast också då ännu bättre. Ett sätt att tänka hur vi lär oss saker är Shu-Ha-Ri som bland annat Martin Fowler beskriver. De som är helt nya på ett område behöver en "master" att lära sig av. Och en mästares uppgift är bland annat att lära ut kan jag tycka. Det kan dock finnas ovilja av att lära ut. En del har helt enkelt inget intresse av det. Andra kan även här känna sig behövda och viktiga så länge de är ensamma om sin kunskap. Detta är i så fall ett problem som vi bör bygga bort i första hand. Fungerar det bra finns det tekniker som parprogrammering eller mobprogramming som kan hjälpa oss att lära och sprida kunskap och lära de som är mer juniora. Fokuserar vi däremot på att folk ska se upptagna ut så är det svårare att få till.

Därför tycker jag att de som är "master" inte bör mätas på beläggning (utilization) utan på tillgänglighet i stället. Är de tillgängliga när de behövs så får vi förhoppningsvis ett bättre flow genom vårt system. Vi minskar väntetider och cost of delay. Den som däremot är väldigt upptagen men viktig för andra tenderar att bli väldigt kostsam.

"If we measure busyness, we'll create more busyness" - Adam Yuret

Tänker man efter så finns det olika roller i samhället där det viktigaste av allt är slack och där vi tar det för givet. Vi vill inte att de ska ha att göra 100% för då är det riktigt illa. Brandmännen i bilden nedan ser ut att ha det rätt lugnt och skönt men det är väl inte illa?

När det brinner i knutarna (på ditt hus, inte att du är försenad ;) så vill vi inte höra att brandkåren kommer nästa vecka när de har tid. De ska så klart komma nu omedelbums och genast med en gång. Det här är något vi är beredda att betala för så klart, vi ser tydligt värdet av detta.

Har man som fokus på att vi ska skapa värde på ett elegant sätt så är det viktigaste att få saker genom vårt system, inte att se till så folk sitter upptagna på sin stol. Har de dessutom ett fiskespö så kan de göra bra saker som tillför värde även när de inte jobbar mot en deadline.

Att inte använda sig av slack

Det finns så klart olika situationer där man inte kan eller vill använda sig av slack. Det finns tillfällen där command and control fungerar bra och där det till och med är önskvärt. Vi kanske inte alls är intresserade av innovation och kreativitet. En hög utilization-grad kanske är önskvärt av olika anledningar. I så fall kanske detta blogginlägg inte är av någon vikt.

Men vi kan även försöka få till ett bra flow-system som fylls på när det behövs utan att använda oss av slack. Där behöver vi det egentligen inte, se Mary Poppendiecks The Tyranny of "The Plan". Men förutsättningarna måste vara sådana att det fungerar också.

"One of the interesting things about flow systems is that they don’t need slack. They filled it in whenever they need it. They don’t have to have it planned in from the beginning." - Mary Poppendieck.

Så för den sakens skull behöver vi inte slack. Däremot är det viktigt med självstyre, motivation och att veta varför vi gör saker.

Men det kanske är så att vi har svårigheter att ge folk ett fiskespö, vi har inget uttalat mål och ingen strategi? Att vi är rädda för slack och att vi därför vill se till så att folk hela tiden blir tillsagda vad de ska göra? Har vi då dessutom några man in the middle som gör att vi inte kan lägga hela vår tid på det vi gör utan måste invänta saker så fylls det lätt på med annat (helt orelaterade saker). Vi får då mer context switching och jonglerar med olika uppgifter samtidigt. Det då att bli dyrare att göra färdigt saker när vi har sämre fokus, tar längre tid och kvalitén blir sämre. Se The Cost of Too Many Projects in Portfolio. Om man enbart ser innovation och kreativitet som en kostnad skulle man kanske kunna kvitta den mot kostnaden för att ha många projekt igång samtidigt? Det roliga är ju dessutom att det första projektet kanske blir klart jättetidigt (och det sista samtidigt som när vi körde dem parallellt).

Summering

Det här blev en lite längre text men jag tycker att många saker hänger ihop och bör förklaras. Jag tror även att det ofta finns väldigt många runt omkring oss som kan tillföra väldigt mycket av värde och att flera hjärnor tänker bättre än några få. Detta sker dock inte av sig själv utan det är något vi måste ha i vår kultur, hur vi ser på folk, kompetens och olika roller. Självstyre ser jag som en viktig del för att kunna hjälpa till att tillföra bra saker och så att varje persons potential kommer till sin rätt. Lyckas man med att ge personer ett fiskespö så är jag övertygad om att man når mycket bättre resultat av det man gör, motivationen ökar och vi får roligare tillsammans. 

Varmt välkommen att kontakta oss om du vill bolla mer om hur du kan nyttja slack för att ta dig an dina digitala utmaningar på bästa sätt.

0 kommentarer

Skriv kommentar