“But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.”~Frederick P. Brooks, Jr
Vandfald, XP, Crystal Clear, Scrum, Lean, Kanban, Lean Startup, RUP, PRINCE2, SAFe, DAD, LeSS… “Vores egen virksomheds-globale metode, som er en vandfalds-agtig udgave af Scrum”.
Jeg bliver bekymret, når jeg hører folk som vil indføre en ny måde at arbejde på eller organisere os på, som skal løse alle vores problemer. Ikke fordi jeg synes det er forkert at ønske at forbedre os og finde “best fit” (tværtimod), men fordi det er en risikofyldt situation og jeg i praksis ser skuffelse, når en metode ikke er det endelige svar på alle vores problemer. Retorikken giver problemer med forventningsafstemningen. Skuffelsen avler mistro til at metoder kan løse nogen problemer overhovet… og det giver problemer med demotiverede folk og lyst til at lede videre efter den næste metode, som kan være svaret på alle vores problemer.
Vi flakker fra metode til metode og lader aldrig teamet få ro til at bygge gode vaner og få tilpasset den valgte metode til deres og organisationens behov. Man kan jo ikke gå ind i en organisation og siger “nu har vi indført Scrum” og så forvente forbedring fra dag 1 – med mindre ens tidligere situation var meget slem og al forandring dermed er af det gode.
Udviklere er som regel pragmatiske og fornuftige omkring dette, mens man andre steder i organisationen længere væk fra hverdagen falder for “silver bullet”-retorikken, som mange metode-guruer benytter sig af.
Derfor bliver jeg også så glad for at læse Daniels blog om hvordan KMD har et team til at hjælpe med “Agile Excellence” – et team som kan sætte sig ind i hvad der sker på området og kan gå ud og hjælpe hvert team med deres specifikke behov. Et team som hjælper med forbedring også selv om det modtagende team ikke lige arbejder med den metode, som de først blev vejledt til.
Desuden minder det mig om et foredrag Jesper Boeg holdt på GOTO for nogle år siden om hans personlige rejse igennem de forskellige metoder… og tilbage igen.
Du kan se videoen fra Jespers foredrag her:
Især Jespers pointe om ikke at se metodevalget som en religion kan jeg fuldt ud tilslutte mig. Fanatikere er svære at arbejde sammen med – når man putter tro ind i ligningen, så ryger de logiske argumenter og den sunde skepsis. Man kan få samme gode resultat med forskellige metoder, hvis man konstant har fokus på forbedring – metoden er startpunktet (alle begyndere har brug for regler), men uanset hvilken metode du vælger, så skal der arbejdes med tilgangen til og tilpasningen af metoden. Den ene metode kan ikke siges at være absolut bedre end den anden – men den kan være bedre til formålet.
Vi skal huske at give hver metode tid til at “bundfælde sig” efter indførsel. Vi skal lære at bruge metoden – starte med reglerne og ende med at se det store billede.
En god måde at tænke på det er Dreyfus-modellen for læring (som Jesper Boeg også nævner i sit foredrag):
1. Novice
non-situational recollection, decomposed recognition, analytical decision, monitoring awareness
2. Competence
situational recollection, decomposed recognition, analytical decision, monitoring awareness
3. Proficiency
situational recollection, holistic recognition, analytical decision, monitoring awareness
4. Expertise
situational recollection, holistic recognition, intuitive decision, monitoring awareness
5. Mastery
situational recollection, holistic recognition, intuitive decision, absorbed awareness
Hvordan har din personlige rejse igennem metoderne været?
Tak for et godt blogindlæg.
I mit virke som konsulent arbejder jeg ofte med rådgivning om metode- og værktøjsunderstøttelse af udviklingsprocesser, og som konsulentvirksomhed forsøger vi at hjælpe vores kunder med at finde en pragmatisk og praktisk udførlig vinkel på disse emner.
Vi oplever ofte, at vores kunder har “ondt i metoderne”, i den forstand, at især projekt- og udviklingsmodellerne ofte er såvel meget bureaukratiske i deres designs som meget pedantiske i deres forankring i projektværktøjerne.
Der er mange gode årsager til, at udviklings- og projektmodeller bør være specifikke og entydige, men at de tillige skal være komplekse, er bestemt ikke givet – og ofte en stor misforståelse.
For visse brancher, og i visse projekter, er eksempelvis compliance med forskellige standarder etc. af ekstrem stor vigtighed for produkt- og slutbrugersikkerheden, hvorfor komplekse modeller i sådanne brancher naturligvis er et imperativt vilkår.
Men vi møder mange virksomheder, hvori sådanne faktorer ikke kan være hovedårsagerne til de komplekse projektmodeller, som i årenes løb er blevet opbygget. Tværtimod lader initielt overdesign (ofte “by committee”), langsomt akkumulerende kompleksitet (complexity creep), manglende fleksibilitet i tooling (ofte stadig som centraliseret Excel-projektledelse) samt manglende, løbende refaktorering af modellerne oftest til at være udtalte årsager til pinen.
Der er mange gode bud på projekt- og udviklingsmodeller, hvoraf flere modeller også ligefrem har en god track record mhp. at give såvel mere forudsigelighed, effektivitet og kvalitet som glæde iblandt medarbejderne, men det er uhyre vigtigt, at man som ledelse og organisation er åben overfor, at modellerne til dels indføres og evalueres organisk og iterativt, at dette gøres i øjenhøjde med medarbejderne, og at det derfor vil være et helt acceptabelt resultat for organisationen (og for metodefolkene), hvis man i praksis vil komme til at se sig selv anvende en dialekt/variant af en eller flere projektmodeller.
Vi ser eksempelvis en del “Scrum-but”, hvor vi færdes, og det er mit personlige indtryk, at de organisationer, som har et betydeligt fokus på at anvende – men især også på løbende at tilpasse – stærke projektmodeller et i tæt samarbejde med deres medarbejdere, i højere grad lykkes med at få positive projektmæssige, økonomiske og organisatoriske resultater.
Endelig mener jeg, at “No Silver Bullet”, “The Mythical Man Month”, “The Design of Design” og ikke mindst “The Leprechauns of Software Engineering” – foruden metodespecifikke bøger – bør være en del af et vidensmæssigt baggrundstapet, hvormed man bedre kan forstå de menneskelige og organisatoriske kompleksiteter, der er forbundet med indførelsen af projekt- og udviklingsmetoder – uanset metodernes indre kompleksitet.
Tak for kommentaren Thomas. Det lyder som om du har materiale nok til et helt blogindlæg.
Jeg genkender dine erfaringer med unødig kompleksitet og især din pointe om at være i øjenhøjde med medarbejderne nikker jeg voldsomt til. Alle organisationer er forskellige og det bør vi som metodefolk huske. Min favoritbog i den forbindelse er Linda Risings “Fearless Change”.
Gode boganbefalinger du kommer med – dem jeg kender i hvert fald :). Jeg har stadig meget læsning til gode og f.eks. har jeg ikke læst “The Leprechauns of Software Engineering”, men den er kommet på min liste.
Godt indspark!