Er Scrum og spenst skadelig?
Fossefall er ut, Scrum og spenst er ‘in’. Fremskritt, nødvendig, muliggjørende. Men ingen metodikk er bedre enn sine utøvere.
På samme måte som at ingen religion er bedre enn sine prester/ledere. Analogien er ikke tilfeldig: Fora der Scrum’ene eller Agile’ne møtes, minner stadig mer om vekkelsesmøter. Skriften tolkes, guruene hylles, de riktige sangene ‘synges’ og den rette tro får manifestert seg. Tvilerne blir rettledet, de vantro hånet – og så videre. Kjent oppskrift med kjent resultat: Snevert, innadvendt, selvtilfreds. Slikt blir det verken produktivitet eller gode resultater av. Hvor ble det av pragmatisme, åpen diskusjon og fokus på mål, målestokk, leveranse og resultat?
Om vi overdriver? Nei, vi spissformulerer for å få fokus på det egentlige problemet: At programutviklere – også kalt ‘software-ingeniører’ – 50 år etter at håndverket ble til, fortsatt dyrker troen på at programvare er så spesielt. De tar feil. Om produktet er fysisk eller ikke, håndverk er håndverk, engineering er engineering.
Engineering-guru Tom Gilb er internasjonalt anerkjent for metodikk og ideer, bøker og seminarer innenfor og utenfor IT-bransjen. I fagbladet Agile Record (oktober 2011), under tittelen «‘Done’ should mean value delivered to stakeholders» fyrer han (blant annet) av følgende kraftsalve:
The agile programmers, the Scrum ‘Masters’ (LOL), and Product Owners are simply not trained, educated or managed to deliver serious stakeholder value. So agile methods, as they stand, must die or change. We suspect Agile Culture is suicidal and would prefer to die out rather than mature, to meet real world challenges.
Iteration, feedback and change (fundamental agile ideas) are powerful concepts for managing software and systems, but right now they are flying blind regarding systematic delivery of software value, which drives systems and stakeholder values. The change is not going to happen through intelligent leadership from programmers. We need intelligent technical management to step up and demand far more from software development.
Den satt. Ikke minst fordi mange av oss har erfart symptomene – at dagens regimer ikke leverer. Fine på papiret, skuffende i praksis. Nye verktøy er vel og bra, men kombinert med gammel tankegang eller innstilling, blir fremskrittet beskjedent og hastigheten fremover lav. Bedre ledelse, klarere krav er Gilbs anbefaling. Lett å tiltre, krevende å iverksette.
En annen referanse som bidrar til å henge bjella på katten, er bloggen On the Manufacture of Intellectual Property fra utvikler-nettstedet Netkernel.Her tar Peter Rodgers et tankevekkende oppgjør med den antikvariske klan-modellen som preger mange utviklingsmiljøer (Java-klanen, Ruby-klanen, .Net-klanen etc.), og med selve livsløgnen for utviklere: Software er så spesielt. Han skriver avslutningsvis:
The truth is that software is not materially special. Nor are software projects particularly complex when measured against the production of physical products – for example, a car or a house or an aircraft, or even something as ubiquitous as woven cloth and clothing.
Even when measured against the production of other intellectual property products, software is not especially complex.
I would argue that a movie, a TV series or a children’s book are of equivalent or much much greater complexity than the typical software project.
Den satt – igjen. Alle er tjent med å la livsløgnen fare – med ett mulig unntak: Advokatene som forfatter uleselige lisensbetingelser.
Vårt poeng er ikke å redusere betydningen av nye verktøy og metodeverk, men å skape forståelse for at utvikling som håndverk har endret seg brutalt. Mens den tradisjonelle utvikler ble lært opp til at koding er koding, og at hun/han kunne være like bra på alle nivåer, fordrer dagens virkelighet spesialisering. På verktøy og innsikt. Forskjellen på en god og en dårlig håndverker – uansett bransje – er at den gode vet hva han ikke kan.
Det krever en korrigert innstilling til utvikling som profesjon. Aksept for at systemutvikling handler mer om sammenkobling av komponenter, mindre om koding. Og at samme verktøy aldri kan være like godt til grunnmur som til toppetasje.
Tilpasningen til nåtidens behov og fremtidens krav skjer ikke ved å bytte verktøy eller plattform, men ved å akseptere en ny arkitektur og tilhørende utviklingsmodell: Tjenester i kontinuerlig utvikling, sammensatt av komponenter som lever – noen kort, andre lenge, ingen evig.
Se også:
Legg igjen kommentar
Du må være innlogget for å kunne kommentere.