Cargo Cult Agile

Jeg læste en interessant artikel forleden omkring en vinkel på hele Agile-paradigmet. Artiklen handlede om en stamme af indfødte på en af øerne i nærheden af bikini (mener jeg), som efter at have set amerikanere bygge transportbase (en landingsbane og kontroltårn) forsøgte at "efterligne" disse artefakter for at tiltrække den transportlast de så komme ned med "jernørnene". Mange år efter fandt man således disse indfødte, som nu havde bygget kontroltårne af bambus og lavet deres egen landingsbane og som gik rundt med kokusnøddeskaller på ørene (som høreværn) i håb om at tiltrække de spændende ørne med den gyldne last. Ørnene var selvfølgelig aldrig kommet, men på trods af dette var det blevet en del af de indfødtes ritualer og spirituelle oplevelsesregister at dyrke denne vision.

The term ‘cargo cult’ is a reference to aboriginal religions that grew up in the South Pacific after World War II. The practices of these cults center on building elaborate mockups of airplanes and military style landing strips in the hope of bringing the return of the god-like airplanes that brought such marvelous cargo during the war - http://catb.org/jargon/html/C/cargo-cult-programming.html

Det er ikke første gang, jeg selv har tænkt tanken om, hvorvidt det vi udfører blot er Cargo Cult indenfor agile-paradigmet. Altså vi bruger sticky notes, whiteboards, burncharts, sprintplanning, retrospectives og impediments, men er vi virkelig agile?

Indskudt note:
Jeg har også set eksempler på nettet, hvor folk "praler" med deres compliancy i forhold til Diane Larsens ideer om retrospectives. (Hun har et eksempel, hvor hun anbefaler dot-prioritization, som blot betyder, at man går til tavlen og sætter en prik ved de tiltag man ønsker at prioritere højest.) Folkene havde til en større retrospective-session købt små runde dot-klistermærker, som man kunne sætte på papirerne i lokalet - how far out is that? Hvad er der galt med en kuglepen eller blyant?

For at runde den lange svada af: når alt kommer til alt bør man spørge sig selv om, hvad essensen af agile egentlig er? Alle artefakterne er i sidste ende vel mest biprodukter af denne essens? Hvad er dit bud på kernen - den inderste essens?

En artikel på jp.dk

Så er SCRUM omtalt på JP, i en længere artikel der beskriver processen.

Se artiklen her.

På den positive side nævnes at:

• Mest overraskende er produktivitetsforøgelsen. Der bliver virkelig leveret meget, meget mere programkode - i høj kvalitet
• Metoden kræver en del is i maven
• Der kommer oftest flere og bedre resultater ud af processen, end når man anvender traditionelle metoder

Blandt de negative erfaringer nævnes:

• Teamet bliver meget indadvendt
• Teamet let kommer til at overse afhængigheder til andre projekter
• Teamet let overser forudsætninger, der skal være på plads

Flere checklister...

Man kan ikke få for mange checklister til afdækning af, hvor godt ens Scrum-proces er implementeret / fungerer i det daglige.

Specielt synes jeg følgende lister er interessant (udover den fra min forrige post):

Henrik Kniberg - forfatteren til den gode bog Scrum And XP From the Trenches - har lavet et udkast til en liste:
http://blog.crisp.se/henrikkniberg/2008/02/01/1201823760000.html

Ligeledes har Michael James lavet en liste. Denne fokuserer på rollerne og det tekniske:
http://www.sendspace.com/pro/dl/qh5zug

Kender du nogen som er værd at nævne?

Hvor er agile er vi?

Prøv at gå igennem score-arket her med jeres teams:

http://kw-agiledevelopment.blogspot.com/2008/01/how-agile-are-you-take-this-42-point.html

Den er god til indikation af indsatsområder, omend lidt for "værktøjsorienteret" i mine øjne.

Teams #1 - Størrelse af team

Vi har kørt et par projekter efterhånden her på den blå, og jeg er begyndt at tænke på, hvor smertegrænsen for størrelsen af et team ligger i forhold til team-performance, kommunikation og sociale relationer.

Cockburn's Crystal clear siger noget i retningen af max 9 på teamet, inkl. testere og designere. En artikel på InfoQ siger "productivity drops off a cliff as team size increases". I den kvantitative ende kan man enddog finde formler for, hvordan størrelsen af et team er direkte relateret til kommunikationens kompleksitet.

Jeg er egentlig nået frem til, at den absolutte smertegrænse her på den blå befinder sig ved omkring 6 teammedlemmer. Vi har tidligere kørt med noget større teams, hvor vi også gjorde brug af outsourcing til Indien. Kompleksiteten var ekstrem høj i forhold til kommunikationen (flere sprog, flere kulturer og subadfærdsmønstre) og de sociale relationer (subgrupperinger indenfor teamet etc), at det gik meget ud over performance på den måde, vi søger det her. Team-performance betyder for mig, at en gruppe af mennesker bliver så sammentømret, at planlægning og fremdrift flyder frit som en naturlig del af teamets momentum. At skabe et sådan momentum kræver meget af de enkelte teammedlemmer. Pludselig bliver elementer som nedenstående vigtige:

• Åben kommunikation
• Holde en god tone
• Respekt
• Anerkendelse af personer og deres styrker og svagheder
• Planlægning
• Støtte når nogen har behov for det

Sjovt nok peger alle disse elementer i sidste ende på den enkelte person, altså det skal forstås som et skillset som et teammedlem skal have eller oparbejde for at kunne deltage i super produktive teams. "Teamwork is an individual skill", siger Christopher Avery i en god og praktisk bog om emnet.

Hvad er jeres erfaringer? Hvilken størrelsen dur de teams i deltager i? Og ikke mindst hvorfor?

Definition of done #2

Vi har tidligere skrevet om definition of done her på bloggen. I mellemtiden har jeg været igang med et team, hvor vi satte os ned og gjorde et forsøg på at lave en sådan definition. Det var nogle værdifulde lærepenge. Øvelsen afslørede hurtigt, at der overhovedet ikke var fælles fodslag for en sådan definition. Der var problemer med at separere forskellige niveauer af done - hvad skal der til for at en given opgave færdig, hvad skal der til for at en given release er færdig?

Min anbefaling er følgende for alle større projekter:

1. Sørg for at få defineret "done" som en del af projektopstarten
2. Hold en kort session, hvor teamet diskuterer de forskellige niveauer af done, eks. en user story, en sprint release etc. Brug yellow-stickers til det. Lad alle skrive deres bud. Læg dem på et bord, strukturer og bliv enige om niveauer
3. For hvert niveau lav en brainstorm med yellow-stickers. Alle deltager. Man skal ikke begrænse sig til, hvad der teknisk er muligt lige nu, men til hvordan det perfekt set vil være. Eks. start med user story. Lad et teammedlem starte med at lægge stickers på bordet, dernæst resten. Strukturer, grupper undervejs i logisk sammenhængende kategorier.
4. Når man er igennem et niveau, så "tegnes" der en streg på bordet, og teamet bruger tid på at placere de enkelte grupperinger over eller under stregen afhængigt af, om den enkelte kan lade sig gøre p.t. (over stregen) eller ikke kan (under stregen).
5. For hver under stregen diskuteres, hvad man kan gøre nu som alternativ, og om punktet skal løses nu eller på sigt (lige ned på din impediments liste)
6. Gå punkterne 3-5 igennem for hvert niveau.

Fordelen ved at have dette klart før et projekt starter er, at alle på teamet ved, hvad det indebærer, når en siger: "jeg er færdig med den opgave".

Inspiration hentet her fra:

• http://chrissterling.gettingagile.com/2007/10/05/building-a-definition-of-done/
• http://agilesoftwaredevelopment.com/2006/05/definition-of-done
• http://agilefaq.wordpress.com/2007/10/24/what-is-definition-of-done/

Planning poker

Der er nu to projekter, hvor teams er begyndt at anvende planning poker på Den Blå Avis. Det feedback jeg har samlet op indtil nu er følgende:

• Det er sjovt at estimere (på den måde)
• Det skaber nogle gode diskussioner
• Alle deltager og ingen kan ride med på sidelinien ("nå, jeg hørte ikke lige efter, men X sagde 5 og han plejer sku at vide, hvad han snakker om, så jeg siger også 5...")
• Teamet får et fælles sprog på opgaverne, da både Scrum Master, Product Owner og udviklere er til stede
• Teamet får en fælles forståelse for, hvad der er små, og hvad der er store opgaver. Product owner har måske et billede, og udviklere et andet - her alignes det.
• Det er hurtigere at estimere på denne måde
• Estimering med point (kortene) er svært i starten, for hvad dækker point over? Vi forsøger os mod at lade pointene illustrere den relative kompleksitet, men ofte falder man tilbage på timer.

Nogle af de punkter, som generelt gør sig gældende for planning poker er:

• Gruppebaseret diskussion hjælper med at definere opgaverne før estimering
• Der kombineres viden fra flere forskellige kilder (personer)
• Simultan afsløring af estimater reducerer anchoring effect og social sammenligning (han ved nok bedst, så jeg siger bare det samme)
• Minimalt overhead
• Face-to-face interaktion
• Alle tager mere ejerskab over estimater

Hvis du er interesseret i at læse lidt om planning game så kommer der her en interessant liste af links, du kan spise dig igennem:

• http://www.planningpoker.com/detail.html


• http://en.wikipedia.org/wiki/Planning_poker


• http://www.planningpoker.com/detail.html


• http://www.crisp.se/planningpoker/ (god illustrativ forklaring på anchor effect + her kan du også købe kortspil)


• http://www.substanceofcode.com/2007/06/09/planning-poker/


• http://blogs.msdn.com/dave_froslie/archive/2005/09/30/475791.aspx


• http://www.codinghorror.com/blog/archives/000981.html
• Agile Estimating and Planning - Kort præsentation (Mike Cohn giver et overordnet billede af hvordan planning game indgår i den store agile planning sammenhæng)

Hvis du er interesseret i at dykke lidt ned i diskussionen omkring estimering i timer/dage vs. point, så start her:

• http://blog.mountaingoatsoftware.com/?p=6
• http://www.agilegamedevelopment.com/2006/03/hours-vs-story-points.html
• http://epistemologic.com/2006/10/25/agile-estimation-story-points-vs-hours/
• http://edgibbs.com/2006/11/05/from-story-points-to-ideal-days/

Sluttelig, det kan selvfølgelig anbefales at læse Mike Cohn's bøger Agile Estimating and Planning og User Stories Applied, hvis indlægget her fører til videre interesse.

Vertikal eller horisontal udvikling?

Vi forsøger så vidt muligt at undgå, at vores projektteams arbejder på opgaver, som ikke er direkte relateret til forretningsværdi. Det handler om at forsøge at tilrettelægge arbejdsopgaverne således, at man laver hele det vertikale snit gennem lagene på en given applikationsplatform for en given funktion - fra UI til db...


Dette er ikke altid lige nemt at nå indenfor en sprint - specielt hvis funktionen er kompleks og indeholder mange alternative flows. Vi taler ofte om, hvordan man kan inddele komplekse funktioner i en række steps, som stadig vil have værdi for forretningen (måske ikke release-værdi, men i forhold til at kunne kommentere og forstå funktionen). Jeg fandt to små artikler om dette emne, som jeg synes I også skulle have glæde af: Vertical slicing og Slicing the cake.

Lige til slut: Hvad gør i? Hvad virker bedst for jer, og hvorfor?

Projektleder, en facilitator?

Igennem den sidste uge har jeg været dybt involveret i at få et team, som jeg indgår i, til at ændre adfærd og tage mere ansvar som team.

Jeg har ofte tænkt over, hvordan denne selvorganisering som Scrum teorier refererer til kan foregå i praksis. Det er svært at implementere selvorganisering. Det skal ligesom blot opstå af sig selv og så holdes igang, når først det er der.

Teamet som helhed er blevet presset til at levere bedre resultater end hidtil, samt at udvise større ansvarsbevidsthed omkring projektet. I den sammenhæng kunne jeg godt træde ind og lægge en plan for, hvordan vi kommer i mål i sådan en situation, men hele humlen er, at hvis jeg gør det, så bliver det min plan, og hvem bærer så ansvaret? Teamet eller jeg? Det er vidst nemt at svare på...

Lidt stik imod min natur har jeg hele ugen forsøgt at holde mig udenfor, hvordan problemerne angribes og løses. I starten mest for at gøre det muligt for de andre teammedlemmer at tage ansvar for processen, senere for at tydeliggøre nogle af de problematikker der skal arbejdes med: manglende fokus, koncentration, mødedisciplin og retning.

Resultatet indtil i går har været at teamet som helhed har lavet en plan, som alle medlemmer f'øler de kan binde sig til, men hvad har været væsentligere: der er blevet åbnet op for reelt samarbejde, sparring og vidensudveksling imellem alle på teamet. Det eneste problem, der har været indtil i går, er, at diskussionerne og møderne har været for diffuse, da alle først har skullet spore sig ordentlig ind på hinanden - hvad gør man ved det? Igen kunne jeg have valgt at indføre et sæt af regler, som alle skulle følge, og mit instinkt dikterede mig det vidst nok et eller andet sted i baghovedet. I stedet tog jeg diskussionen med teamet med udgangspunkt i: "nu hvor vi har vist at vi kan løfte det her og samarbejde, hvordan kan vi så nå til at vi effektivt kan holde fokus og kommunikation på et niveau, hvor det ikke suger al tid ud af projektet". Forslagene var enkle: møder skal have en agenda, der skal være en ordstyrer, timeboxing, parkering af issues, som deltagere føler er relevante (så kan de diskuteres bagefter) m.m

I dag har så været en ret underlig dag. For det jeg har oplevet er et hold, som samarbejder, og hvor alle tager ansvar for opgaverne. Møderne har været korte og effektive. Alle har været synkroniserede. Jeg gik hjem med en glad fornemmelse i maven i dag, for det er første gang jeg har oplevet selvorganisering spirre på den måde, og det slår alt, hvad traditionel ledelse nogensinde kan byde på.

På vej hjem i bilen tænkte jeg så: "hvad er min rolle i det her?", og mens P1 drønede derudaf med valgløfter og polemik, så gik det stille og roligt op for mig, at min rolle er ganske enkel, omend kompleks i praksis, for jeg skal blot sikre at den spirrende selvorganisering for lov til at gro sig fast...

Spændende blog: All About Agile

Jeg ved ikke om den er alment kendt, men i hvert fald synes jeg at All About Agile er en utrolig spændende blog. Læs f.eks føljetonen om 10 Key Principles of Agile Software Development eller om How to implement Scrum in 10 easy steps for god inspiration til jeres arbejde.

Scrum og læring

Ken Schwaber siger følgende i Agile Project Management with Scrum:

I was talking with the CIO of a large organization. He complained to me that he would run projects that would take 12 to 18 months and at the end of the project he would get something that he didn't actually want. I told him that I can deliver what he doesn't want in one month.

Det citat fik mig til at tænke på de fordele som er indbygget i Scrum i forhold til læring:

1. Organisationen/kunden/stakeholders har mulighed for læring meget meget hurtigere end ved mere traditionelle waterfall metoder, da man allerede efter en måned (eller to uger afhængigt af sprintlængde) kan forholde sig til, om det er det rigtige der bliver lavet
2. Teamet får allerede efter en måned feedback på, om det de laver er relevant. Dette er en motivationsfaktor i sig selv.
3. Efter hver sprint har teamet mulighed for at "sadle om" og ændre på deres arbejdsmåde og/eller organisation.
4. Efter hver sprint har produktejer og Scrum Master mulighed for læring i forbindelse med de mål og krav, der har været involveret i sprinten, og dermed hele tiden forbedre og præcisere disse ud fra det feedback som teamet giver.

Sprint-backlog

For næste projekt som starter op om en uge har vi valgt at anvende excel fremfor (tunge) tfs til taskstyring og kravdelen. Det betyder, at både produkt-backlog og sprint-backlog laves i excel. I den forbindelse kunne jeg godt tænke mig at høre om jeres erfaringer i den henseende. Hvilke problemer kan vi forvente at støde på, og findes der smarte løsninger på disse problemer? Hvilke felter har I med i jeres backlogs og hvorfor?

Jeg har lavet et udkast til en sprint-backlog, hvor der for hver dag er mulighed for at indtaste både timeforbrug og resterende timer. Det synes jeg ikke jeg har set i nogle af de andre sheets jeg har kunnet finde på nettet. Er der en grund til det? Umiddelbart tænker jeg selvfølgelig på, at nogle vil mene at det er rent tidspilde at forsøge at tracke performance af estimater, men hvis man nu gerne vil kunne kigge på, hvor lang tid en opgave tog i forhold til opgavens estimat, så er man vel nødt til at have den information med?

Fordele: Agile

Rundt om på nettet støder man ofte på lidt guf i forhold til at forstå og kunne kommunikere de reelle fordele ved en agile projekt- og procesmodel.

Som kommunikationsinstrument synes jeg følgende grafer fra VersionOne er stærke:

Traditionelle waterfall-projektmodeller har en tendens til at undstøtte de blå kurver ovenfor, hvor synligheden er høj i starten og hen mod slutningen, men hele projektperioden ind i mellem er mørklagt, ikke med hensyn til tal og budgetter, men med hensyn til det færdige system. På samme måde så "fryses" leverancen til at indeholde hele det specificerede system, hvilket betyder at forretningsværdien først realiseres (eller ikke!) ved launch af hele projektet.

Hvad skal en produkt backlog indeholde?

Vi er i øjeblikket i gang med at synkronisere vores brug af produkt backlogs på store projekter på Den Blå Avis. I den sammenhæng er det nærliggende at tænke over, hvilke data man egentlig ønsker at backloggen skal holde på...

Jeg har tænkt på følgende felter:

• Id = unik nummer for hvert backlog element
• Kravbeskrivelse = user story el. kort beskrivelse af arkitekturkrav eller andet
• Kontekst = gruppering (epics, themes) af krav (user stories)
• Release = en værdi som angiver hvilken forretningsmæssig-release kravet er tænkt at tilhøre
• Forretningsværdi = en værdi sat af produktejeren
• Risiko = en skalavurdering foretaget af teamet
• Estimat = kompleksitetspoint (som kan omformes til timer, hvis forretningen ikke forstår point)

Hvordan ser jeres backlogs ud?
På hvilket niveau vurderer I forretningsværdien? På det enkelte krav, eller på konteksten?
Hvordan arbejder I med estimering?
Skulle man inddrage en simpel test kolonne (som i Scrum and XP from the Trenches)?

Jeg kunne godt tænke mig at høre jeres bud...

Hickup: Det hedder product owner og ikke ProductOwner...

Jeg støder alt for ofte på artikler, kursusbeskrivelser og alt muligt andet, hvor elementerne i Scrum processen benævnes som var de entiteter i et diagram.... selv på http://www.controlchaos.com/

Eller se her for et ret grelt eksempel (BurnDownChart...øh).

Bare lige nogle generelle gode råd:

• Det hedder product owner, ikke ProductOwner.
• Det hedder product backlog, ikke ProductBacklog.
• Det hedder scrum master, ikke ScrumMaster.

Scrum er en proces, der fokuserer på mennesker og interaktioner, og derfor kan det godt nage lidt i mig, når man ser scrum begreberne brugt som om de var del i et class-diagram til en applikation under udvikling...

(det er i øvrigt en sygdom jeg også stødte på i mit tidligere job, hvor den slags sammensmeltninger og brug af kapitaler smittede af på slutbrugerdokumentation)

Hvorfor ikke waterfall?

Engang imellem er det rart at stoppe op og lige minde sig selv om, hvad det er, man har gang i, og hvorfor det er så super vigtigt. Jeg sidder i øjeblikket med forberedelse til nogle workshops omkring processen på næste store projekt her i huset. Her stødte jeg på følgende statement:

"Agile process focusing on delivering highest value in shortest time"

Så kort og præcist kan det siges. Motivationen for alt det man skriver om, alt det man går og forsøger sig med i forbindelse med en transformation fra waterfall til mere fleksible procesmodeller indfanges her.

Det kan være dejligt med sådan en reminder i ny og næ. Derudover kigger jeg ofte på følgende figur, når jeg behøver at minde mig selv om, hvorfor det jeg tror på er vigtigt:

Hovedprincipper bag Agile Software Development

Spændende læsning her: 10 Key Principles about Agile Software Development.

Måske man kunne udvide nogle af beskrivelserne for de enkelte principper eller udvide antallet af principper? Eksempelvis sidder jeg og tænker på to væsentlige principper, som jeg ofte selv har svært ved at bringe fornuftigt ud i organisationen:

1. Selvorganisering --> Det er ikke effektivt at mikrostyre det arbejde udviklerne skal udføre for at lukke en given sprint. De ved selv bedst. Men hvordan får man en gruppe af udviklere til at fungere selvorganiserende på det område? Hvordan håndterer man modstand i mod selvorganisering (nogle vil hellere skubbe ansvaret fra sig)?

2. Ethvert projekt har en estimeret produkt backlog! --> hvordan sikrer man dette? hvor skal snittes lægges. skal den gen-estimeres?

Har i nogle erfaringer eller kender i til artikler som uddyber disse områder, så skriv en kommentar.

Scrum hos Yahoo

Sjovt hvad man støder på, når nettet tager fat i en. Jeg så, at Gabrielle Benefield skulle holde foredrag og Scrum Master certificering på JAOO 2007 i år. Det fik mig til at søge efter hende på nettet.

Fandt en spændende artikel skrevet af hende og Peter Deemer omkring Scrum implementering hos Yahoo. Udover at have gode betragtninger på forskellen i Waterfall og Agile praksisser, så havde den følgende interessante data.

75 projekter og 700 mennesker hos Yahoo følger Scrum processer. En intern undersøgelse af deltagere på disse projekter viste følgende:

1. Produktivitet: 68% mente at produktiviteten var forbedret
2. Team moral: 52% mente at team moralen var forbedret
3. Tilpasningsevne: 63% mente at tilpasningsevnen var forbedret
4. Ansvarsfølelse: 62% mente at ansvarsfordeling- og følelse var forbedret/tydeligere
5. Samarbejde: 81% mente at samarbejdet var forbedret

Dette er jo nogle ret fantastiske tal. Måske kunne man undres lidt over team moralen, og at kun halvdelen synes den er forbedret. Mange taler om, at ulempen ved Scrum er, at processen lægger et konstant og vedvarende pres på teamet i forhold til at performe og levere. Har dette en indflydelse?

After Action Reviews, Retrospective eller projekt eval..

Kært barn har mange navne.

Selv med en velbeskreven procedure og med medarbejdere, der er erfarne i at arbejde indenfor rammerne af denne procedure, så er det min erfaring, at resultatet af mødet afhænger meget af, hvem der driver mødet.

Hos os holder vi en del after action reviews (se også Rune's indlæg), og vi forsøger at få projektdeltagerne til at komme med løsninger til de udfordringer de står med.

----

Jeg kom til at tænke på dette arbejde da jeg læste et indlæg på kolindkuren.dk, hvor konklusionen er - 80% af de der har stemt mener at deres organisation kan skabe mindst ti procent mere værdi for kunderne, hvis medarbejderne blev sat fri til at bestemme hvordan opgaverne skal løses.

Jeg mener vi er ret gode til at få input fra projektdeltagerne på den blå, og vi forsøger at implementere det gode input vi får tilbage.

Det er dog en kæmpe udfordring at få påvist problemer og deres relevante løsninger, eller på en god dag flere alternative løsninger, kommer frem i lyset.

Er der nogen her der har erfaringer med at tage AAR input og få implementeret ændringer baseret på det? Eller bruger i mest AAR's til at give luft for brok? Hvad gør i ?

Why do Agile Adoptions Fail?

En udvikler her på stedet sendte mig et link til en artikel med titlen Why do Agile Adoptions Fail? sammen med spørgsmålet om hvor langt vi egentlig var i vores adoption - sådan lidt sarkastisk, ikke :)

Personligt bryder jeg mig ikke meget om grundantagelsen i artiklen (agile practises do not fail...). Den er lidt for evangelistisk og med religiøse undertoner (the great agile savior), som jeg ikke mener gavner noget som helst set fra et pragmatisk synspunkt. Men når det er sagt, så synes jeg faktisk det er en sund praksis at tage stilling til, hvordan det egentlig går med adoptionen af agile praktisser. Her på stedet er vi nået langt, men der er stadig langt endnu, både hvad angår udviklingsproces, udviklere, projektledere, forretningen osv. I forhold til den liste som beskrives i artiklen kan der tilføjes mange ekstra punkter. Mine hurtige punkter er

1. Ingen eller få sprint reviews og demonstrationer


2. Entydig produktejer ikke udpeget


3. Produktejer ikke et fuldgyldigt teammedlem


4. Sponsor ikke i en position hvor denne forstår sit ansvar


5. De rette kompetencer i forhold til agile practises


6. Ingen dedikerede testere


7. Mangel på automatisering

Har i andre kan i jo tilføje dem i kommentarerne :)

I øvrigt kan man finde en checklist for Scrum praksis her (den fungerer i hvert fald som et ok udgangspunkt): Scrum Rules Cheat Sheet

Der findes også denne artikel som er værd at læse: Personal Agility For Potent Agile Adoption

At være en god leder...

Jeg læste et indlæg her til middag, som beskrev distinktionen imellem at være en chef (manager) eller en leder (leader) på en fantastisk måde.

"Managers use people to accomplish work; leaders use work to grow people".

En traditionel chef bruger folk til at effektuere sin plan for projektet og har dermed fokus på planens outcome mere end de individder, som uddelegeres de opgaver, der kan indkassere planen og produktet. En god leder derimod har fokus på individdet i planen og dets muligheder for at vokse med opgaven. I begge situationer vil individdet blive sat til at løse opgaver inden for rammerne af en given plan. Men som leder sikrer man nødvendig optimisme og motivation til løsningen af opgaverne. Det smitter så sikkert også af på kvalitet og hastighed...

Jeg ved ikke med jer, men ovenstående citat fik i hvert fald mig til at tænke på, hvor mange gange jeg agerer leder vs. hvor mange gange jeg agerer chef - og hvordan kunne jeg måske have gjort tingene anderledes. Indlæggets forfatter har selv følgende forskrift på, hvordan man kan begynde at agere leder fremfor chef:

My take is that we have an obligation to lay an appealing trail of
breadcrumbs to lead people along the path of figuring-out stuff for them
selves.

What the breadcrumbs look like and where they go depends on the
skills and needs of the person but a reasonable starting process would
be:

1. Ask them what they want to do
2. Ask them how they feel about areas for improvement
3. Provide resources (training, books, mentoring) in areas they have an
   interest for
4. Encourage “outsight” (input from people outside the organization) in
   their development Checkpoint regularly about how the process is going and if
   their goals have changed

After action reviews - Agile retrospectives

For alle projekter i huset afholder vi et after action review, som lister de ting, vi ønsker at organisationen skal huske og samtidig tage ved lære af på fremtidige projekter. Dette anser jeg for almindelig skik i hvilken som helst projektorganiseret virksomhed. Det er vigtig formel kanal ind i organisationens læring og erfaringsopsamling.

Derudover, så anvender jeg på større projekter retrospectives løbende for at korrigere projektets arbejdsmåde, rette projektmiljømæssige problemer (vi mangler en projektor, gruppen skal sidde samlet for højere effektivitet etc...) og for at styrke samarbejdet i projektgruppen. Vi er begyndt at anvende Scrum på vores projekter, og den proces kræver at man afholder et sprint review efter hvert endt sprint. En del af dette review vil blive brugt til at diskutere hvilke ting der skal forbedres eller styrkes på projektet, og disse action items føres så med ind i næste sprint (jeg vil begynde at hænge sticky notes med action items op på projektkontoret, så de er visuelle og synlige for gruppen og dens omgivelser). Jeg har altid anvendt en simpel notationsform for actions items ala "vi skal forbedre x i næste sprint", hvor det væsentlige er en tydelig markering af målsætning for det pågældende action item. I dag læste jeg en artikel på ScrumAlliance.org om emnet. Artiklen foreslår følgende notation for action items: 1. Nedskriv langsigtet målsætning (vi skal have automatiseret build-miljø), 2. Nedskriv her og nu målsætning (Dennis compiler hele koden hver dag en time før fyraften). Meget simpelt, jeg kan virkelig godt lide den opslitning, da den gør det nemmere at få leveret nogle action items, der kan handles på. Artiklen påpeger i øvrigt et andet vigtigt aspekt ved denne form for læring: "udvælg aldrig for mange action items". Hav max. 3 aktive items, så der ikke opstår et overhead i forhold til opfølgning og administration af processen.

Hvis du anvender retrospectives på dine projekter eller føler dig inspireret til at begynde med det, så kan jeg anbefale bogen Agile Retrospectives af Esther Derby og Diana Larsen (sidstnævnte er vært for en del arrangement på årets JAOO konference - kan kun anbefales...).

Giv magten til dit team #2 - Kulturel interferens

Jeg har besluttet, at næste post i føljetonen omkring at lade udviklingsteamet overtage magten i forhold til styring af udviklingsopgaver handle om et potentielt problem forbundet med lige netop at overlade magten til teamet.

Dansk Projektledelse (DPL) udgiver årligt en række medlemsmagasiner, som jeg læser. Nyeste nummer fokuserer på sælgerkompetencer indenfor projektledelsesdisciplinen. Specielt en artikel fangede min opmærksomhed: "Sælger af kultur" skrevet af Finn Svenning. Artiklen kigger nærmere på begrebet kulturel intelligens, og hvordan kulturel intelligens kan appliceres som værktøj i projektledelse. Definitionen på kulturel intelligens er "even til at skabe et konstruktivt samarbejde på tværs af kulturforskelle". Hvad har det med projektledelse at gøre? Jo se på dit team af udviklere, designere, forretningsudviklere og testere - hvor mange forskellige subkulturer huser du ikke her? Se på organisationen omkring projektet med salgsafdelinger, marketingafdelinger, tekstforfattere, support, kunder - hvor mange forskellige subkulturer eksisterer her? Det geniale ved artiklen er dens operationelle fokus på, hvordan disse kulturkløfter kan anvendes aktivt i ledelsesarbejdet. "Den kulturelt intelligente projektleder sørger for, at gruppen arbejder med deres kulturelle forskelle og ligheder som start på projektforløbet"... hvor mange af jer husker at gøre det? "Det er også vigtigt at aftale spilleregler for samarbejdet i projektgruppen, og her skal man tage udgangspunkt i den kultur, hver enkelt gruppedeltager kommer fra, så reglerne ikke bliver et tandløst kompromis"... hvor mange af jer husker at gøre det? Jeg har i hvert fald noteret mig følgende:

Ved projektkickoff skal

1. Alle på teamet præsentere sig selv, ens baggrund og hvorfor man mener, man er udvalgt som deltager på projektet
2. Teamet skal liste de umiddelbare styrker ved teamets interne forskelligheder og aftale at fokusere på disse
3. Der skal aftales spilleregler for teamets interne struktur (team lead er ok, men i mine øjne skal forummet i teamet være så åbent som overhovedet muligt.

Ok. Så vidt så godt. Men hvorfor er det altsammen væsentligt i forhold til overskriften på indlægget "giv magten til dit team"? Hvis nu man giver magten til sit team, men ledelsmæssigt gør man ikke noget for at skabe et godt og åbent forum, så er der en overhængende stor sandsynlighed for at en i gruppen (den teknisk stærkeste?) blot overtager hele styring og i princippet tryner de andres synspunkter, fordi han ikke tænker på de kulturelle forskelle, der eksisterer. Når testeren eller en anden udvikler ikke melder sig på banen ved en arkitekturændring, er det måske fordi de føler sig underlegne i forhold til en teknisk meget kyndig udvikler... men selv tekniske genier har behov for naturligt modspil, specielt fra andre kulturelle vinkler end lige netop hans egen.

Så tak Finn Svenning! Vi projektledere skal aktivt lede teamets interpersonelle strukturer, så den kulturelle interferens bliver brugt positivt til at skabe åbenhed og belyse problemer fra flere vinkler...

Ydmyghed...

En ting omkring projektledelse, som vi ofte diskuterer her på arbejdspladsen, er, hvordan man sikrer at projektledere tilvejebringer optimal information både til projektet (forretningsviden og -mål) og fra projektet til organisationen (status, fremdrift, issues/impediments).

Min chef sagde på et tidspunkt til mig, at jeg var en type, som havde det naturlige standpunkt at tingene nok kunne løses af mig selv - altså som udgangspunkt har jeg ikke behov for hjælp. Det arbejder jeg på at lave om, sådan at jeg naturligt vil inddrage de rette folk i eventuelle problematikker og derigennem få nødvendig viden og hjælp samtidig med at de rette personer informeres om projekthindringer.

Omkring temaet hjælp og evnen til at spørge om hjælp findes der en interessant artikel her

Definition of done...

Jeg er meget opmærksom på at kunne tracke projektets fremskridt målt som mængden af færdig funktionalitet. Hvorfor? Jo, hvis man nu antager, at projektet skulle stoppes lige nu, hvad nytte havde man så af, at eks. 66% af alle opgaver var løst, hvis denne mængde rent faktisk kun svarede til 2% færdig funktionalitet?

Dette er vist en meget almindelig antagelse for alle agile projekt-process modeller. Der hvor det bliver lidt sjovt er, når talen kommer ind på, hvad færdig egentlig betyder - the definition of done? Der findes mange bud, bl.a. læste jeg et godt et i dag her, men faktisk har jeg selv svært ved at komme frem til en entydig og universel gyldig liste. Efter min opfattelse skal definitionen af færdig forhandles med produktejere og udviklere som en del af opstarten på et projekt, og definitionen skal afstemmes med krav til deadline, kvalitet, genbrugelighed, testabillity osv.

Hvordan ser jeres liste ud?

Planning game - fortsættelse...

I forlængelse af Daniels tidligere post vil jeg godt gøre lidt reklame:

Der findes et færdigt kit man kan anvende til planning game (baseret på XPs principper). Jeg var igennem en øvelse i forbindelse med Scrum Master certificeringen, som anvendte dette kit, og det var en meget lærerig oplevelse... jeg kan på det varmeste anbefale alle projektledere at "lege" denne leg som intro på agile projekter, for ligesom at få folk i denne rette stemning og ånd.. På ganske kort tid lærer man om koncepter som velocity/fart, kompleksitet og story estimering.

Hent kittet her: http://www.xp.be/html/xpgame.zip

Domain modeling with color

Et stærkt værktøj, når det kommer til domænemodellering, er Peter Coad's modeling with color. Hans pragmatiske tilgang til domænemodellering er baseret på ideen om, at domænet består af en række (tekniske) arketyper: party, place, thing og moment-interval. Hver af disse har deres egen farve, og hele domænemodellen farvekodes efter dens indholds arketypiske værdi. Dette skaber en super godt overblik, men endnu vigtigere også et forum, hvori domænet kan diskuteres, analyseres og tilrettes... og ikke kun af teknikere, men også forretningsfolk. Hvis du vil læse mere om modeling with color, så læs pdf'en jeg linker til ovenfor. Denne post handler nemlig om, hvordan man undgår at ende i "farvediskussioner", fordi man ikke forstår værktøjet til fulde. Jeg læste en kort artikel om det her til morgen, og jeg synes den er meget sigende for de problemer man kan støde på med modeling with color, og samtidig god som inspiration for, hvordan man overkommer disse problemer. Det vigtigste i artiklen er argumentet om, at hvis man ender i farvediskussioner, så bør man erkende at diskussionen ikke er forkert, men oftest symptomatisk for noget andet... noget der mangler, eller ikke er defineret præcist nok...

Scrum Master Certificering

Sammen med en kollega har jeg deltaget i Scrum Master certificeringsprogrammet de sidste to dage. Initielt var jeg en smule skeptisk indstillet over det, specielt det "kommercielle" aspekt omkring at kalde noget for en certificering baseret på to dages kursus. Den del er jeg også stadig skeptisk overfor, altså man bliver ikke Scrum Master på to dage! Men derudover er kurset yderst inspirerende, hvis man beskæftiger sig med følgende problemstillinger:

1. Hvordan sikrer man at forretningen prioriterer alle krav ud fra deres forretningsværdi
2. Gode estimerings- og planlægningsteknikker
3. Ideer til hvordan man får teams til at være selvorganiserede

Jeg kan varmt anbefale at deltage i kurser, hvor Jeff Sutherland er vært. Han har stor ekspertise og erfaring, som han øser ud af. Næste gang han er i Danmark er til september, hvor der afholdes JAOO 2007 i Århus. Du kan tilmelde dig kurset her.

Giv magten til dit team #1 - Medbestemmelse

På det seneste har ideen om motivation af projektteamet fyldt mit sind meget. Derfor har jeg tænkt at starte en føjleton på området, som sikkert kunne skabe lidt sund debat :)

Grundlæggende bygger mange agile processdiscipliner på en antagelse om at motivation og empowerment af projektteamet er væsentligt for at kunne skabe gode resultater, og indenfor softwarebranchen dermed god software. Eksempelvis har Scrum sit udgangspunkt i at projektteams/udviklingsteams skal være selvorganiserende for at kunne levere fremragende software tilpasset kundens, produktejerens, ønsker og behov.

Jeg kunne godt tænke mig at dykke lidt ned i, hvad der gør et super team, og her tænker jeg specielt på, hvad man som leder kan gøre gøre for at sætte scenen i den forbindelse.

Første ting jeg har tænkt mig at skrive lidt om er noget som ligger mig meget nært i mit ledelsesarbejde: medbestemmelse, så her kommer det...

#1 Medbestemmelse
I modsætning til traditionel management tankegang, hvor projektlederen udstikker opgaver og får projektteamets medlemmer til at løse dem, så tror jeg på, at teamet selv skal lede og fordele det stykke arbejde, som de udfører. Projektlederen skal blot fascilitere at dette bliver gjort og bistå med gode indspark til processen, hvor nødvendigt. Dette er væsentligt af flere grund, men vigtigst er dog, at man som projektleder skal befri sig fra kontrolcenter-metaforen, hvor man kan sidde i sit eget skønne elfenbenstårn og styre sine projekter via flotte charts og reports. Teamet skal deltage i centrale beslutninger for projektet. På den måde får man også flere perspektiver på en given problematik, end man ellers ville have gjort. Som projektleder bør du

1. Involvere dit team i beslutningsprocesser, som omhandler teamet eller det produkt, som der arbejdes på
2. Sikre at teamet er klar over sit ansvar
3. Gøre det klart for teamet, at de har de kompetencer, der skal til for at kunne træffe de rigtige beslutninger
4. Sikre at der altid følges op på de beslutninger, der træffes (dvs. får dem omformet til planer, kommunikeret til stakeholders etc.)

Hvad får du ud af at gøre det? I mine øjne er der nærmest kun gevinster at hente (hvis det rigtige setup etableres):

1. Du får adgang til en meget bredere, og multi-perspektiveret, vidensbase (som i tekniske henseender er langt mere kompetent end du nogensinde kan være)
2. Ved at spørge teamet nedarves der konsensus for forslaget, som skal vendes. Teamet kommer op med løsningsforslag, som bliver til planer, og disse planer vil i sidste ende være produktet af løsninger tænkt af teamet selv og ikke af dig
3. Når mennesker adspørges om deres mening, så arbejder de hårdt for at komme op med gode ideer. Dette er et kæmpe plus, når man står midt i en kritisk situation i sit projekt og skal træffe vigtige beslutninger, om hvilken retningen arkitekturen eksempelvis skal tage

Medbestemmelse betyder dog ikke, at du kan læne dig tilbage og lade andre beslutte alt for dig. Du skal skabe det forum, hvori medbestemmelsen opstår, men som ordet medbestemmelse også ligesom indikerer, så er du også selv en deltager i processen. Måske beslutter du ikke noget om teknikken, men måske har du gode retningslinier for tænkningen eller scopet af diskussionen.

Sidst vil jeg lige nævne, at medbestemmelse også stiller store krav til projektlederens rolle som leder. Projektlederen skal være den toneangivende og altid gå foran som det gode eksempel. Hvis man som projektleder lader teamet træffe beslutninger på halvt grundlag, hvad lærer man så sit team? - At det er ok at træffe beslutninger på ufuldstændig information.. osv.

Forretningen, domænet & udvikling

Et stort problem for agile udviklingsproces er, som jeg ser det, at sikre fremskridt og konstant levering. Mange bøger beskæftiger sig ikke rigtigt med, hvordan man sikrer, at hver iteration producerer noget færdig funktionalitet, som principielt set skulle være deployment-klar.

Crystal Clear taler om walking skeleton strategien, som går ud på at man først får et simpelt arkitekturskelet op og køre, og dernæst fylder kød på det. Scott Ambler med Agile Unified Proces (som er den processmetode der ligger til grund for projekterne her på Den Blå Avis) taler om requirements-driven architecture og modeling in small increments. Lidt samme ide igen: man opbygger arkitekturen i små bidder, dog krydret med at arkitekturen skal udspringe fra forretningens/kundens krav. Men det store spørgsmål forbliver, hvordan gør man egenligt?

Belært af tidligere projekter er jeg blevet meget påpasselig med at tage domænet for givet. Vi opererer med en arkitektur, hvor de grundlæggende forretningslogikker og -objekter afspejles i en domænemodel. For mig at se er det essentielt at få domænet på plads tidligt i projektet, før udviklingen af krav starter. Det betyder at

• Krav skal være tilpas detaljerede
• Kravstiller skal kunne stå inde for kravene
• Kravene skal mappes til domænet
• Domænet skal afspejle løsningen af kravene

Dette arbejde er interessant af flere grunde. Det skaber en kontakt imellem kravstiller og udviklere som er helt nødvendig for at få kravstiller til at tage et aktivt ansvar i udviklingsprocessen og for at få udviklerne til at tage et aktivt ansvar i kravene. Med andre ord de bringer de to verdner tættere sammen. Kravstiller og udvikler kan diskutere krav på en måde, som de begge hver især forstår: Kravstiller taler ud fra forretningen, udvikleren ud fra domænemodellen. Gode eksempler kunne være:

Udvikler: Jamen skal kunden kunne få den rabat hver gang han handler?
Kravstiller: Øh, ja... Kunden får rabatten, fordi han handler for mere end 3000 kr om året hos os.
Udvikler: Ok, så man skal altså logge den samlede sum en kunde handler for?
Kravstiller: Ja det vil jeg da klart mene
Udvikler: Og hvis den samlede sum overstiger 3000 kr, så får kunden en rabatsats?
Kravstiller: Ja på 2%. Hvis kunden handler for over 10000 så stiger rabatten til 5%
Udvikler: Så det er en slags konfigurerbar trappesats? Skal i selv kunne vælge procentsatserne og beløbene?
Kravstiller: Det ville da være at foretrække, så skal vi jo ikke belemre nogen fra udviklingsafdelingen hver gang vi skal have det ændret!

Udvikler sidder her og kigger på det domæne, hun har tegnet op. Sikkert bestående af nogle ordrer, kunder og varer. Men ved at diskutere rabat med kravstiller ud fra domænet lærer udvikleren hurtigt at der skal tilføjelser til domænet for, at rabatten kan virke som forretningen ønsker det. Pointen her er, at hvis man i de tidlige faser får vendt domæment med kravstiller og de krav, der er registreret, så får man et mere stabilt udgangspunkt for udviklingsfasen. Det er min påstand, at dette arbejde i et eller andet omfang er nødvendigt for at kunne levere færdig funktionalitet efter hver iteration i udviklingsfasen, ellers skal der bruges for megen tid på undersøgelse af krav og ændring af domæne efterfølgende.

Vi arbejder med fire faser (hentet fra Agile Unified Proces & Rational Unified Proces): inception, elaboration, construction og transition. Inception er projektfødsel, hvor man definerer overordnede rammer for projektet, elaboration er der hvor man fordyber sig i projektet, construction der hvor kravene udvikles og transitition er udrulningen af projektet. Vi arbejder på Den Blå Avis med en kravsprocess, som definerer krav som værende 10% færdige efter inception og 80% færdige efter elaboration. De sidste 20% kommer i løbet af construction, når kravene udvikles (man kan ikke vide alt up-front!). På samme måde foreslår jeg egentlig at man går til både domæne og arkitektur...