Lad os starte med en lille anekdote: For nogle år siden var jeg på skiferie i Østrig med nogle venner og deres børn. Et af parrene, Jan og Pia, havde ikke selv nogle børn. Derfor ”lånte” de deres nevø John, så de kunne komme med på forældre-børn skituren med os andre.
Opholdet i Østrig gik fint for John, Jan og Pia – også selvom Jan og Pia tydeligvis ikke var vant til forældrerollen. På hjemvejen standsede vi alle på en rasteplads i Tyskland tidligt om morgenen, da vi trængte til lidt forfriskninger.
Tjeneren havde været på arbejde hele natten, så vi skulle være på dupperne for at få bestilt det rigtige. Jeg så ud af øjenkrogen, at John kiggede søgende rundt. Jeg var selv optaget af at få bestilt pommes frites til mine to døtre og en kop kaffe, så jeg fik ikke taget mig af hans søgende blik.
Lidt efter kom tjeneren så med maden. Pommes frites til mine piger, kaffe til mig og foran John stillede han: Sauerkräut!
John så igen op efter nogen, der kunne hjælpe ham. Han var tydeligvis ikke glad for indholdet på sin tallerken. Jan og Pia så ingenting, før der trillede en tåre ned ad Johns kind. Jeg prikkede til Pia. Hun opdagede, hvad der foregik og sagde til Jan: ”Jeg tror ikke, John har fået det, han godt kunne tænke sig”, hvortil Jan svarede ”John – han har fået det, han har bestilt!”.
John havde bestilt noget og fået det – men det var ikke det, han ønskede sig.
Agile projektledere arbejder for sine teams
Denne lille historie kan ses som et billede på, hvad der ofte foregår i traditionelle udviklingsprojekter med traditionelle projektledere ved roret. Nogen bestiller noget, og så får de som udgangspunkt leveret, det de har bestilt. Ofte med mere fokus på, hvad der er bestilt end på, hvad kunderne godt kunne tænke sig, eller hvad der giver den størst mulige forretningsmæssige værdi.
Er dette eksempel sat på spidsen? Ja!
Men er der noget om snakken? Ja!
For selvfølgelig kan man ændre kurs undervejs i et projekt, der er ledet af en traditionel projektleder. Sagen er bare den, at den traditionelle ændringsstyring ganske vist tillader ændringer, men alligevel ofte resulterer i færre ændringer. Dette påvirker projektet til at holde sig til de oprindelige specifikationer, snarere end at være åben og søgende i forhold til, hvordan forretningsværdien kan optimeres af de løsninger, der udvikles.
Agile projektledere er inspireret af principperne i det Agile Manifest (se box). Eksempelvis det 4. princip:Reacting to change over following a plan
Princippet handler om at lave planerne om i takt med at vi bliver klogere undervejs i projekterne. Og bemærk formuleringen ”… vi bliver klogere…”. Det fungerer nemlig langt bedre, når projektlederen (og/eller Scrum Masteren og/eller Product Owneren) i høj grad involverer og engagerer alle.
På den måde kan alle være med til at vurdere, om projektet er på rette kurs frem for, at projektlederen er den eneste, der beslutter retningen. Således vender Agile projektledere organisationen på hovedet – netop fordi, de Agile projektledere arbejder for deres teams frem for, at deres teams arbejder for dem.
Manifesto for Agile Software Development
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiations
- Reacting to change over following a plan
Og hvad indebærer det så, at de Agile projektledere arbejder for deres teams?
Det betyder, at de faciliterer, at alle involverede (teams og interessenter) forstår sammen, planlægger sammen, validerer sammen og reflekterer sammen. Og hvad det betyder, fortæller jeg dig nu.
Forstå sammen
Specifikationer kan komme til kort, hvis vi bruger dem som primær kilde til at opnå en fælles forståelse for det, vi skal udvikle. Derfor vender vi også disse på hovedet, så vi – ud fra nogle overordnede rammer og ønsker – starter med at dele og diskutere viden med hinanden i faciliterede møder og på den måde ender med at skabe en fælles forståelse.
Når vi har fået skabt en fælles forståelse, kan vi beskrive det efter ”just enough”-princippet. For når alle har forstået, hvad der skal laves én gang, så mindskes behovet for omfangsrige specifikationer. For vi har jo allerede forstået det sammen. Nu skal vi bare huske på det.
Der findes en række udmærkede faciliteringsteknikker til at forstå sammen. Eksempelvis Brainstorming, Story mapping, Use case camps, Brainwriting etc. Det der driver de Agile projektledere er, at folkene på deres teams sammen med relevante interessenter opnår den fælles forståelse sammen.
Planlæg sammen
”HVILKEN PLAN???”
Det var reaktionen fra en knalddygtig, erfaren og altid fortravlet udvikler, jeg havde på et team engang. Jeg gik rundt og spurgte folk til, hvordan det gik i forhold til planerne og mindede dem om, at det var fredag, vi skulle levere den første del af projektet.
Det med planerne var tydeligvis ikke noget, han syntes vedkom ham. Jeg så mig omkring og tænkte: ”Hvis der ikke er andre end mig på teamet, der har noget som helst forhold til de her planer, hvad skal vi med dem…?”.
Løsningen er selvfølgelig ikke at droppe planer og planlægning, men blot at understrege, hvor vigtigt det er for den Agile projektleder at involvere sit team, når planerne laves. Det giver mere realistiske planer for de mennesker, der skal udføre arbejdet, samtidig med, at det jo også er de mennesker, der ved en masse om, hvor lang tid de forskellige ting tager. Det giver ligeledes et større ejerskab over planerne, når alle har haft indflydelse på dem.
Derudover sætter den Agile projektleder genbesøg af planerne i system. På den måde ved alle, hvornår planerne opdateres.
Jeg ynder at sammenfatte ovenstående i denne sætning: ”The do’ers are the planners”.
Validér sammen
På trods af en stor indsats med sammen at forstå, hvilke behov teamet ønsker at dække med løsninger, så er og bliver disse specifikationer dybest set hypoteser.
For vi ved ikke om vi rammer plet, før vi giver brugerne vores løsning i hænderne og lader dem afprøve, hvordan den virker for dem. Først på det tidspunkt kan vi være sikre. Først her ved vi, om vores hypoteser holder. Når vi sammen validerer vores løsning, giver det de forretningsmæssige fordele, som vi jagter.
Og dette kræver, at den Agile projektleder går forrest og orkestrerer to ting:
- Dels skal vi have skabt og institutionaliseret en rytme for fællesdemoer og feedback Mange ender med at have to niveauer af demoer: Én hver 14. dag med teamet samt de nærmeste kolleger og interessenter, og én hver 2. eller 3. måned med flere interessenter samt nogle mere sammenhængende demonstrationer af kunde-flows etc.
- Dels skal vi have åbnet vores sind i forhold til at være åbne og nysgerrige, når vores kunder og brugere begynder at stille spørgsmål og foreslår ændringer til det, vi har udviklet. Selv har jeg nærmest måtte gå i terapi for at holde op med at råbe ”Scope creep” eller ”Vi har lavet det, I har bestilt!” – husk på John og hans sauerkräut – lige så snart nogen så meget som åbnede munden under demoerne. For det er jo lige meget, om vi har lavet det, der er bestilt, hvis det ikke kan bruges til noget. Så det handler om at invitere brugerne til feedback. I min bog ”TOGETHER, how leaders involve and engage people to get great things done” taler vi ligefrem om “beg for feedback” i erkendelsen af, at mange har vænnet sig af med at være åbne og ærlige om, hvad de mener om et produkt.
Reflektér sammen
”Hvis du havde sejlet mod kajen i en lidt spidsere vinkel, så havde det været lettere for mig at hoppe i land”.
Vi ynder at sejle i vores familie, og ovenstående er en typisk kommentar fra en lille de-brief på en havnemanøvre, som min lille familie har gjort det til en vane at have, når vi er kommet i havn og har fået skænket et glas rosé. Jeg synes, det er imponerende, så langt vi er kommet og så godt samspillet på båden efterhånden fungerer – selv i pressede situationer. Råben og skrigen er afløst af håndtegn og samspil. Herligt!
På samme måde oplever, jeg som Agile projektleder, at vi kan blive meget bedre i vores samarbejde, hvis vi blot tager os tid til at reflektere over, hvordan vi arbejder sammen, hvordan vi kommunikerer og behandler hinanden, samt hvordan vi taler om og overleverer opgaver og viden til hinanden.
Jeg medgiver, at der godt kan gå lidt langspyt i disse retrospektive betragtninger, men det skyldes som regel, at vi er for ambitiøse og opstiller en masse forskellige ting, som vi gerne vil forbedre – eller at vi gerne vil forbedre nogle ting, som vi ikke har indflydelse på.
Hvis vi blot vælger en enkelt ting for hvert sprint, og vælger noget, som vi selv kan ændre, så er der langt bedre chancer for, at vi får ændret på status quo, så vi ikke ender med flere som John, der får, hvad de har bestilt, men ikke det, de ønsker.