tirsdag den 17. marts 2009

Hvor Scrum fejler

Når Scrum fejler, får man tit at vide at det er da fordi man ikke kører rigtigt Scrum. Det er mig en gåde at så mange højt uddannede mennesker kan fejle med noget alle siger er så let. Det skulle være så let, men er så svært i praksis - det siger alle. Men i stedet for at gøre noget ved det, siger man blot, du kører ikke Scrum rigtigt. Jeg ikke det er mig der kører det forkert, jeg tror det er Scrum der er noget galt med, og jeg siger det højt.

Flere software folk er begyndt at forstå at din software komponent arkitektur faktisk afspejler din organisation. En klog man sagde engang til mig at hvis man sætter 5 software udviklere til en opgave, så vil man højst sandsynlig opdage at man ender op med en arkitektur med lige så mange komponenter, filer, moduler, classer etc. Grunden kommer faktisk helt fra vores ide om ansvar, og i en optimering af at det er dumt at 2 laver det samme - især hvis de ikke ved det selv. Software versions styring er et grundlæggende værktøj, og langt de fleste værktøjer kommer da også med en advarsel hvis man checker en fil ud som en anden også har checket ud. Og hvorfor? - fordi der så er to mennesker der er ved at lave det samme, hvis ellers ens software arkitektur har uddelegeret ansvaret ud i klasser, en mini Saas som jo er et moderne begreb, men samtidig altid har været grundstenen i software arkitektur på alle niveauer. Det giver mange fordele, man ved hvor tingene er, hvem der laver det, hvor ny funktionalitet skal være i arkitekturen, hvor fejl kilden er når en usecase ikke virker som tiltænkt. Det er et helt fundamentalt og sundt princip i software og i organisation.

Men virker det mon også sådan med Scrum. Mit svar er nej, for Scrum tvinger os til at fravige dette fundamentale princip. Alle ved det, og det burde være nemt at rette op på, men ingen gør det, for så kører man ikke Scrum rigtigt mere. Scrum er selvorganiserende. Men det er software arkitektur ikke. Men kan sagtens lave software hvor det er, men det svarer til at køre SOA uden governance, og alt erfaringer viser at det som regel ender i kaos. Du får en arkitektur alligevel, men det er bestemt ikke sikkert det er en du kan lide eller at den er egnet til det du havde tænkt den til.

Ingen kommentarer:

Send en kommentar