I den här videon berättar Ken Schwaber om vad han menar med "Scrum But"-argument och vad han tycker de tyder på.
Scrum är ett enkelt ramverk. Några få regler bildar tillsammans ett system av aktiviteter som kan användas för att styra komplext arbete. Att ta bort en väsentlig del ur ett fungerande system påverkar alltid systemet som helhet. Tar man till exempel bort återblickarna ur Scrum minskar sannolikheten för framgång omedelbart. Man får lika stora problem, om inte större, om man försöker applicera Scrum dogmatiskt. Den som aldrig kan tänka sig att kompromissa kommer inte att ha någon framgång när det gäller att driva förändring. Har du själv jobbat med någon som aldrig kan kompromissa förstår du varför. Så hur ska man göra? Följa Scrum dogmatiskt för att inte förstöra arbetsmetodens effektivitet, eller vara pragmatisk för att inte alienera sig från andra människor? Jag föreslår en kompromiss. Låt oss kalla den en progmatisk hållning . Den progmatiska hållningen fungerar så här. Vi är å ena sidan aldrig rädda för att tänka själva och göra förändringar i Scrum, men å andra sidan gör...
Kommentarer
Tyvärr har jag märkt att det kan vara väldigt svårt att få till organisatoriska förändringar.
Jag vet inte hur det funkar i USA men i Sverige, i alla fall på de företag där jag arbetat med scrum, föredrar man att tycka att "Scrum är inget för oss" eller så tycker man att Scrum Master är "besvärlig" och åtgärdar det problemet istället.
När företagsledningen hävdat att Scrum ju är en lättrörlig metod, det är väl bara att justera som man vill - brukar jag svara att ja Scrum är en lättrörlig metod, men det är inte metoden man skall anpassa utan sättet man jobbar på.
Påståendet brukar bemötas med inledande tystnad för att sedan övergå i ett mumlande "jo i och för sig".
Tack för besöket på bloggen och för kommentaren! /Tobbe