Marshmallowtestet var en studie i fördröjd tillfredsställelse som genomfördes 1972 av psykologen Walter Mischel vid Stanford University.  I studien hade man ett antal barn i fyraårsåldern som fick sitta i ett rum med en marshmallow på en tallrik framför sig. Instruktionen var att om barnet kunde motstå att direkt äta marshmallowen så skulle denne istället få två marshmallows.  I genomsnitt kunde ett fyraårigt barn motstå frestelsen i ungefär 3 minuter, vissa åt upp marshmallowen direkt när försöksledaren lämnade rummet och ungefär en tredjedel klarade att motstå frestelsen hela den utsatta tiden och fick därmed en extra marshmallow.

Det här är ett ganska illustrativt exempel på hur vi hanterar tålamod och uppskjuten belöning. Det visade sig när man följde upp barnen i vuxen ålder att de som hade förmåga att skjuta upp belöningen hade större förmåga till tålamod, större framgång i skolan och att hantera problem i hemmet, stress och relationer med andra människor.

När det gäller IT-kostnader verkar vi tänka precis tvärtom och tyvärr är nog dagens Agila arbetssätt i många fall en bidragande orsak till det, eller egentligen är det inte de agila metoderna som det är fel på utan snarare hur de används. Många förtrollas av enkelheten i det agila att man “bara” behöver skriva krav i userstory-format och att detta sedan resulterar i ungefär det som man har tänkt sig. Fokus ligger på att korta tiden från idé till leverans och allra helst ska man kunna driftsätta nya lösningar dagligen.

Många företag har dessutom outsourcat utveckling och test till en extern part och har bara själva beställarfunktionen  kvar inom företaget. Låt oss titta lite på vem som potentiellt kan förtjäna en framtida marshmallow i det här läget:

  • Affärsssidan som så gott som alltid kommer prioritera leverans av ny funktionalitet.
  • Utvecklingsavdelningen oavsett om den är intern eller extern kommer att leverera det som kunden prioriterar och man mäts på hur snabbt man kan få ny funktionalitet i produktion.

Jag har sett ett otal organisationer där man arbetat på det här sättet och alla får ryggdunkningar för att arbetet går så snabbt och nya lösningar levereras på löpande band. Det som inte är så tydligt är den tekniska skulden man skjuter framför sig men den brukar uppenbara sig förr eller senare.

Dessa scenarier är de absolut vanligaste jag stött på:

  • Man har implementerat så många “fixar” och snabba lösningar att IT-landskapet till slut koagulerar. Varje gång man driftsätter en ny lösning så går något annat sönder, merparten av utvecklingsbudgeten går åt till felsökning och att rätta buggar, och att rätta de nya buggar som uppstår när man fixar de gamla.
  • Man byter outsourcingpartner, antingen beroende på att organisationen förändras eller att man helt enkelt vill konkurrensutsätta sin nuvarande leverantör. Plötsligt upptäcker man att man inte har någon som helst kunskap om hur ens kritiska affärssystem fungerar, hur kunder är implementerade och hur gränssnitten i IT-landskapet ser ut. Den befintliga outsourcingpartnern har inget intresse av att förenkla migreringen till någon annan leverantör (oavsett vad som tidigare skrivits i samarbetsavtal).
  • En nyckelmedarbetare som alltid har löst alla problem bestämmer sig för att sluta eller gå i pension (detta är egentligen en variant av exemplet ovan men resultatet blir ofta detsamma).

Detta är precis motsatsen till en uppskjuten belöning, eller som en tidigare kollega till mig uttryckte det ett “Oh shit moment” där det plötsligt blir tydligt vad priset för omedelbar tillfredsställelse faktiskt är. Tyvärr är detta oftast “ingens” ansvar utan baserat på många års brister. Att ropa “varg” och påpeka det riskabla i detta brukar inte vara så populärt då den omedelbara tillfredsställelsen av ny funktionalitet är så stark.

Företag som inte äger och tar ansvar för hela sin utvecklings- och leveransprocess av IT-projekt kommer förr eller senare se sina omedelbara och framtida marshmallows  flamma upp och förkolna, frågan är hur länge du vågar vänta.