Verktøy for å få kunnskap, ikke styring
(Dette handler om smidig systemutvikling – les hele:))
Jeg kommer rett fra lørdagens faste spinning-time. Hadde tenkt å legge inn en ganske hard, men ikke for lang treningsøkt. Jeg har lært at det er viktig og ikke presse seg for hardt i treningsperiodene. De virkelig harde intervalløktene skal spares til formtoppingen. Mine mål for 2010 dreier seg om slå egne tider på Birken på ski, sykkel og på beina. Som i år.
Man kan få masse kunnskap om trening blant annet på olympiatoppen.no og på et utall nettsteder med diskusjonsforum. Når det gjelder utholdenhetstrening synes alle å være enige om at mange mosjonister trener for hardt og for lite variert. Dette går utover overskuddet og gir dårlig framgang. Men hvordan kan du vite om du trener for hardt? Første bud er å skaffe seg en pulsklokke. Jeg gravde dypt ned i lommeboka og kjøpte meg en Polar RS800 som kan gi en masse data om hver treningsøkt, basert på pulslogging. Under ser vi loggen fra dagens spinning-time. Jeg har her utfordret melkesyreterskelen min ganske kraftig.
Jeg har faktisk vært i sone 5 i 39 % av tiden – hvilket kanskje er litt for mye. Men, jeg har heller ikke tenkt å trene på et par dager, så jeg får sjansen til å opparbeide meg overskudd igjen før neste økt. I min lille 2-minutters retrospective konkluderer jeg med at jeg er fornøyd med denne økta. Må bare huske å ta det roligere neste økt. Pulsklokka gir meg også direkte feedback underveis i treninga, så jeg kan justere intensiteten etter hvor jeg ønsker å ligge. Veldig motiverende å følge med på dette!
Idrettsfolk er ekstremt avhengig av feedback for å øke prestasjonene. Man har en teori i bunnen om hva som er riktig trening i de ulike fasene. Og så bruker man alle tilgjengelige verktøy for å samle data og måle progresjonen mot målet. Men siden vi her snakker om mennesker så er det til syvende og sist den enkelte utøver som vil gjøre vurderinger løpende underveis. Det er ekstremt vanskelig å jogge rolig om været er godt, musikken på øret er suggererende og kroppen fungerer glimrende. Kommer man i flytsonen er det bare å la det stå til, så får man ta smellen etterpå. All loggingen og feedbacken kan ikke bli mer enn veiledende. Dataene motiverer og må brukes med måte til å øke kunnskapen om egen kropp, ikke til blind styring.
På samme måten er det med smidig systemutvikling. Vi ønsker data som kan gi oss kunnskap om to ting: 1) hvordan vi ligger an i forhold til det vi har forpliktet oss til og 2) data som kan gi oss kunnskap om hvordan det lønner seg å jobbe/samhandle. Scrum – som er det desidert mest brukte rammeverket – legger opp til å klare seg med så lite verktøy som mulig. Vi jobber i små team nettopp for at vi på en pragmatisk og uformell måte kan beholde oversikten. Vi har daglige møter for å koordinere. Vi må ha skikkelig kontroll på alle oppgavene i Sprinten og hva som gjenstår for å bli ferdig. Bruk gjerne Task Board (lapper på veggen) om man er samlokaliserte. Tar man disse tingene på alvor blir verktøybehovet minimalt. Det er faktisk et eksplisitt mål å holde verktøybruken på et ansvarlig minimum. Verktøy har en tendens til å institusjonalisere oppførsel, både den gode og den dårlige.
Når vi jobber i selvstyrte team må vi være ekstra oppmerksomme på hvordan vi bruker data. Vi ønsker åpenhet og synlighet, men vi må vokte oss for å premiere oppførsel på individnivå. Selvstyrte tem bygger på ”kollektivt eierskap” hvilket lett kan få en slagside om individer premieres eller straffes. Smidig dreier seg mye om å frigjøre seg fra tradisjonell tankegang basert på ”Command and Control” (Les her gjerne ”Freedom from Command and Control” av John Seddon). Om en autoritet tett på teamene (ofte kalt prosjektleder) begynner å bruke data for å styre teamene forsvinner lett dette eierskapet. Autoriteten er tydeligvis den som sitter med eierskapet her…
Det er sterke krefter som virker i motsatt vei av Smidig; Vaner, posisjoner, etablerte ”sannheter”, ønsket om å kontrollere osv. er eksempler på slike. Ønsket om å selge verktøy – eller gleden over et avansert dataverktøy er andre krefter vi må være obs på.
Når vi skalerer opp og må sette sammen mange parallelle team med visse avhengigheter må vi selvsagt håndtere denne kompleksiteten på en forsvarlig måte. I Scrum anbefaler vi flere verktøyløse mekanismer som Scrum of Scrums, oppmøte på hverandres Daily Scrum og ikke minst tversgående virtuelle team (eller communities som Mike Cohn kaller dem i sin siste bok). Dette er ekte smidige løsninger. Mange vil sverge til mer tradisjonelle løsninger som å ha en prosjektleder som koordinerer, kjøpe seg verktøy som gir styrings- og kontroll informasjon. Dette er ikke smidige løsninger.
Smidig dreier seg om å tilfredsstille brukernes (eller mer generelt interessentenes) behov og det bør stå i sentrum. Idealet er pull (som definert av Toyota) der vi lar oss styre av brukernes behov. Det vi virkelig bør samle data om er brukernes ønsker og om brukernes tilfredshet. Gå gjerne så langt som å kvantifisere og måle de verdiene og produktegenskapene brukerne ønsker seg (se www.gilb.no for mer info om Value Management). Dette gir mer verdifull styringsinformasjon og dessuten risikerer vi ikke å ødelegge de selvstyrte teamene.
Ukas Computerworld pusher Rationals Team Concert uhemmet under overskriften TEMA SMIDIG. I det jeg leser er det ikke noe som tyder på at dette er særlig smidig. Alt tyder på at dette er et verktøy for en prosjektledelse som ønsker å ha kontroll. God gammeldags Command and Control. Jeg har kikket litt på reklamen for verktøyet og får da bekreftet mine mistanker:
Her ser vi at de betrakter Burndown som et redskap til å kontrollere Quality of Planning.. Underlig burndown konsept også om man ser på Planned Work som går oppover. Er Arbeid definert som å bruke timer?
Jeg er redd for at nå en del sterke krefter har kastet seg på smidig-bølgen – uten å være smidige. Man ser at smidig selger og gjør noen justeringer i retning av iterasjoner og inkrementer. Dette er en farlig utvikling som kan vanne ut Smidig-begrepet. Vi mister da den kanskje vanskeligste utfordringen, nemlig å bevege oss vekk fra Command and Control mot selvstyrte team. Computerworld og andre er nyttige idioter som lar seg bruke i deres ”smidige” profilering.
In: Scrum · Tagged with: Scrum, ScrumBut, Styring