Jo, jag vet. I agila sammanhang vill man såklart inte planera sitt arbete på det sätt som
Gantt-scheman är byggda för. Man vill helt enkelt inte detaljplanera långt i förväg; det går
rakt emot det agila manifestet. Jag vet det och jag förespråkar agilt arbete och agil planering.
Men…
Om ett företag försöker införa agilt arbete på riktigt och verkligen vill ställa om från klassiska metoder, så är det vettigt att förstå historiken och var oro och problem kan uppstå. Dessutom är det viktigt att kunna förklara varför vissa klassiska metoder och verktyg (som Gantt-scheman) kanske inte fungerar så bra som förespråkarna tror. Att bara förkasta saker utan djupare förklaringar brukar inte vara en bra väg.
Det är inte ovanligt att anställda som arbetat med klassiska metoder och verktyg uttrycker
tvivel över hur arbetet ska kunna fungera utan det de ser som bra planering, t ex med Gantt-scheman. Då räcker det oftast inte att bara förklara behovet av agilt arbete med att ”vi varken vill eller kan planera vårt arbete så långt i förväg”.
Ibland behöver man prata om saker så att alla förstår och börjar arbeta med varandra istället för att debattera med varandra, men hur ska vi kunna diskutera Gantt-scheman utan att fastna i närmast religiösa synpunkter och samtal av typen ”Joho”, ”Nähä”?
Här kan det agila Gant-schemat vara till hjälp – alltså för att underlätta diskussioner kring varför detaljplanering och Gant-scheman inte fungerar så bra i en modern utvecklingsmiljö.
Problemet med vanliga Gantt-scheman
Gantt-scheman är utmärkta verktyg om de används med rätt förutsättningar, i rätt sammanhang och med rätt mental inställning.
Det är framförallt två saker Gantt-scheman brukar användas till:
Det ena är visualisera en ögonblicksbild av planeringen såvitt vi vet just nu.
Det andra (och inte så lyckade) är att visualisera ett kommande tillvägagångssätt och en kommande prioritering, trots att det bara är önskade, fiktiva saker som då visualiseras.
Ändå ser det så exakt ut, saker ligger i prydliga rutor och följer raka linjer.
Den som är insatt på riktigt i klassiska metoder vet att de absolut inte bara tillåter utan även förespråkar iterativt arbete, dvs omplanering vartefter verkligheten förändras.
Problemet med Gantt-scheman beror istället på mänskliga brister. Vi drar oss för att planera om, eftersom den första planeringen tog så mycket tid och ser så bra ut. Vi vill helt enkelt inte göra jobbet fler gånger än nödvändigt. Därför skyller vi på annat om planen inte verkar hålla; diskussionerna börjar ha dolt innehåll som prestige och den egna arbetsbelastningen.
Om vi hade arbetat agilt hade vi alltså sluppit planera i detalj från början och därför inte heller behövt göra om en hel planering för att verkligheten tränger sig på.
Så, hur kan vi visa i ett Gantt-schema, att klassiska Gantt-scheman inte riktigt fungerar i sammanhang som har med modern systemutveckling att göra?
Lösningen på spåren?
Något som skulle vara bra är om Gantt-schemat kan fås att visa att bedömningar (estimat) av allt som ligger i absolut närtid har högre grad av träffsäkerhet och korrekthet än det som ligger i framtiden.
Visualisera det då!
I det här exemplet används enkla färgkoder för att symbolisera kvalitet (se kommande bloggpost om kvalitetsbarometern) på kunskap, stories och estimat och därmed på träffsäkerheten i planeringen:
- Rött = Oestimerat eller mycket osäkra estimat
Endast en liten del av symbolen är fylld, vilket visar att det säkra innehållet är mycket litet. Ändarna är närmast omöjliga att se, vilket visar på mycket osäkerhet i mängden tid som behövs och dessutom att det både kan vara svårt att veta när vi kan komma igång och hur slutet ser ut. - Orage = Osäkra estimat
En mindre del av symbolen är fylld, vilket visar att det säkra innehållet är litet. Ändarna är suddinga, vilket visar på osäkerhet i tid. - Grönt = Välestimerade saker
Lika grönt i nästan hela symbolen visar på stor grad av säkerhet i innehållet. Ändarna har bara mycket lite suddighet, dvs bedömningen av mängden tid som behövs är relativt säker. För saker som visualiseras med gröna rutor håller estimaten alltså sådan kvalitet att vi kan känna oss rätt trygga med dem och vågar använda dem.
Kan färgerna ändras?
Javisst! Om teamet får tid att diskutera, testa och fundera så kan både orange:a och röda rutor fås att bli gröna. Mest sannolikt blr det då flera gröna rutor av varje orange ruta och ännu flera gröna av varje röd ruta. Det kan dessutom vara så att ett antal saker i närtid måste avverkas innan man ens har förutsättningar att förbättra estimat i rutor av annan färg.
Så vad blir kontentan?
Säkra estimat kräver investering i tid! Om teamet inte kan/får lägga tid på det så tro inte att estimaten är värda att användas i en planering. Så enkelt är det.
Nu när vi ser hur mycket osäkerhet som döljer sig i planeringen så blir det alltså desto tydligare att den långsiktiga planeringen inte kan göras i detalj eller med någon grad av säkerhet.
Det blir också tydligt att saker som inte diskuterats, testats och estimerats i sina beståndsdelar genom olika iterationer har så stor innbyggd osäkerhet att det är bortkastad tid att planera när, hur, eller av vem de sakerna ska utföras.
Så där ja.
Jag hoppas att du som driver på för agilt arbete och agil planering på din arbetsplats har fått ett användbart argument som lättare kan förstås av de som är vana att jobba med klassiska metoder och verktyg.
Lycka till!
/Björn