Når man kommer sydpå ad motorvejen gennem Gudenådalen ved Randers, så møder man på vej op ad den sydlige skrænt et ekstra spor med en usædvanligt "80 km/t"-angivelse. Jeg har oplevet at køre med folk, som har spurgt, hvad det nu var for noget, og som har kigget lettere uforstående på mig, når jeg har sagt, at det er da et krybespor - eller mao. et vigespor til trafik, som ikke har kræfterne til at holde farten op ad bakken. Og jeg kan sådan set godt forstå denne undren, for det er godt nok lang tid siden, at jeg sidst har oplevet, at det er blevet benyttet - men det var rigtigt godt at have tilbage i de tider, hvor jeg var en lille knægt.
Nu skal dette indlæg ikke være en tur ad barndommens gade; den første del-pointe, som jeg vil hen til er, at der er sket meget med biler og motorer siden dengang: i min fornuftigt prissatte lille Skoda stationcar har jeg nok mere overskud op ad den bakke nu, end min bedstefar dengang havde i sin Ford Escort sportsmodel med registerkarburator! Der er tale om to vidt forskellige biler - min er fremstillet med langt højere præcision, og har derfor en langt højere effektivitet. Faktisk tror jeg slet ikke, at min bil ville kunne klare at køre særligt længe på det brændstof, som man kunne få dengang, hvis den overhovedet ville køre ... og det er i virkeligheden min egentlige pointe: når "maskinen" bliver høj-effektiv, så skal "brændstoffet" være i topkvalitet.
Nu skal dette indlæg heller ikke handle om biler, men derimod om scrum, product owners og backlogs. Det er bare en observation, som er så intuitivt rigtig, at jeg lige ville gå omvejen, inden jeg kommer til den (hold godt fast, nu kommer der et par sætninger med langt imellem punktummerne): hvis man tager et led i den værdikæde, som udgår softwareudvikling ud, nemlig implementationsdelen, og man toptuner den til at blive en højtydende kodeskrivningsmaskine ved at f.eks. bruge scrum (og hvis man virkelig får scrum til at fungere), så bliver det pludseligt tydeligt, at maskinens effektivitet afhænger af, og er begrænset af, kvaliteten af det input, som den bliver givet. Hvis opgaven med at levere klare opgaver (som man i scrum-regi uddelegerer ansvaret for til product owner - uden at han dermed behøver at være udførende) fejler, så man kun får halvgåede eller middelmådig opgaver ind, så vil resultatet af at køre dem igennem en højeffektiv maskine, justeret over tid til med hårfin tolerance at eliminere ethvert spild, i bedste fald være halvgået eller middelmådigt ... og på længere sigt slide maskinen ned.
Jeg ville her gerne kunne sige, at det er noget, som jeg selv har fundet på, men det er det ikke helt - hvis jeg kan læse indenad, så er det faktisk en af pointerne i, hvad Carsten Jakobsen og Jeff Sutherland siger i et paper kaldet "Scrum and CMMI – Going from Good to Great: are you ready-ready to be done-done?", som de vil præsentere på Agile2009 konferencen. Hvor jeg kun har min mavefornemmelse at have synspunktet i, så henviser de til en lang række praktiske observationer - og i øvrigt har de også andre gode pointer undervejs.
Så hvis du, kære proces-ejer, står med en lyst til at køre hele skidtet en tur til mekanikeren, så tag lige at overvej, om det måske i stedet for kunne være kvaliteten af inputtet, der har et (ahem!) "forbedringspotentiale"? I så fald, så få en god snak med den, som er indsat som product owner, om hvor vigtig en rolle han spiller, og om ikke det kunne gøres bare lidt bedre? Det er både billigere, og det virker bedre. Du er, hvad du spiser...!
Ingen kommentarer:
Send en kommentar