
Et nuanceret billede af Scrum
Jeg ærgrer mig voldsomt over at jeg er nød til at melde fra til et rigtig spændende foredrag i aften "Scrum er ikke agilt". Et spændende emne og så ovenikøbet til et gratis foredrag.
Foredraget følger en trend som jeg ser mange steder og forsøger at give et lidt mere nuanceret billede af Scrum end den man hører fra diverse Scrum-eksperter. Scrum er ikke en silver bullet. Alle projekter bliver ikke automatiske succeser bare fordi man kører Scrum på dem. Scrum løser ikke alle problemer. Det er næsten åbenlyse sandheder, men ikke desto mindre har jeg ofte hørt diverse Scrum-fanboys sige noget andet.
Og på en måde forstår jeg dem der sætter Scrum op på en piedestal. Modstanden mod en metode som Scrum er ofte meget voldsom fordi Scrum indfører en grad af gennemsigtighed, som godt kan føles lidt farlig og derfor er der måske ikke altid plads til nuancerne i Scrum-diskussioner. Efterhånden er Scrum-erfaringer dog så udbredt blandt it-folk at det er blevet lidt mere "lovligt" at diskutere de knap så gode erfaringer med Scrum. Og det er jo et grundlæggende agilt princip "inspect and adapt". Alt kan blive bedre - også den måde Scrum-projekter køres på.
Meget spændende emne, men som sagt kan jeg altså ikke deltage i foredraget selv, da jeg var dum nok til at bevæge mig ud på glatis mandag morgen og endte med en mulig hjernerystelse, en brækket næse og et smadret knæ og derfor er bundet til min sofa i et par dage. Suk. Jeg ønsker foredragsdeltagerne et godt foredrag og håber de vil dele nogle af diskussionerne herunder. Det er vist forresten ikke for sent at melde sig til foredraget endnu, hvis man alligevel er i Århus i aften.
Therese Hansen er medstifter af it-firmaet Monzoom og blogger om softwareudvikling og startups. Hun bruger sin tid på at rejse og at arbejde på firmaets første produkt xiive.com - en social medie-filtreringsservice.
Follow @qedthereseKommentarer (7)
Det var da vidunderligt, og på tide at det er nu blevet "lovligt", for gu fanden fejler Scrum, så lad os da endelig komme igang med at gøre det bedre.
- og god bedring Therese.
Normalt er det mennesker der fejler. Scrum implementeres af mennesker og bruges af mennesker, så det må være måden hvorpå mennesker anvender principperne i Scrum, der gør at et projekt fejler.
Fejl kan jo komme fra mange ting:
- manglende tid
- manglende ressourcer
- manglende involvering fra kundens side
- manglende diciplin og dygtighed fra projektdeltagernes side
- mv...
Som Therese rigtigt skiver, er det også vigtigt at få de dårlige erfaringer frem i lyset, så man kan blive bedre til at gennemføre projekter.
Foredrags oplægget pointerer også at det største problem er at virksomheder tilpasser sig til Scrum og ikke omvendt.
Det har jo aldrig været meningen med de agile udviklingsprincipper at man skal vende organisationen på hovedet, men at man i stedet tilpasser metoden til de behov virksomheden har.
En interessant kombination er den Systematic er ude i:
Systematic er CCMI niveau 5 certificeret, men anvender en kombination af CMMI, Scrum og Lean til at gennemføre deres projekter.
Læs mere her: http://www.methodsandtools.com/archive/archive.php?id=95
Tak Michael - jeg heler så hurtigt jeg kan :-).
Jeg har lige skrevet et kort indlæg om en af de ting som jeg synes Scrum kunne gøre bedre - og der er plads til mange andre bud i kommentarfeltet :-).
http://www.version2.dk/artikel/13562-hvad-er-der-galt-med-scrum
Jep, Systematics proces med at kombinere CMMI niveau 5 og Scrum er interessant. Jeg hørte et foredrag om det på JAOO sidste år og det virkede ikke som om det er helt så umuligt som det lyder. Der er måske noget at lære - selv om jeg dog ikke er sikker på, at jeg nogensinde vil vælge frivilligt at arbejde under CMMI niveau 5 med de dokumenteringskrav der er.
Nej! det er ikke mig der er noget galt med det er virkelig Scrum. (Individuals and interactions over processes and tools)
Det er mig en gåde at så mange højt uddannede mennesker kan fejle med så simpel en metode.
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 tror 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.
Det er sjovt at problemet nu er at virksomhederne tilpasser sig Scrum og ikke tilpasser Scrum til virksomhederne. Jeg har hørt så Mange sige det modsatte, at Scrum netop ikke virkede fordi at virksomhederne ikke ville tilpasse sig.
Jeg er helt enig med Michael her - det er for nemt at sige at hvis mange Scrumprojekter fejler på et bestemt punkt, så er det fordi de ikke kører Scrum rigtigt.
Det er en halv sandhed.
Scrumprocessen fejler efter min mening hvis der er et punkt, hvor mange intelligente mennesker ikke kan finde ud af at følge processen eller hvor man ofte fejler selv om man følger processen. Det er et svagt punkt, som man skal sætte spotlyset på og se om vi ikke kan finde en måde at forbedre.
Hvor bliver der taget hånd om software designet i Scrum? Var det ikke bedre at lave en metode der begrænser antallet skiftene krav, så man kan lave noget ordenlig software. Det kan vel ikke være sådan at kundes reelle behov skifter så hurtigt? Min erfaring er også at det er ledere eller sælgere der opstiller kravene, men skulle der ikke være nogle design folk der gjorde det?
mvh
Udvikleren.
