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.

Definition på et projekt #2

I går diskuterede jeg mit tidligere indlæg vedr. definition på et projekt med min chef. Han kunne godt lide definitionen, men syntes at der mangler en form for tidsafgrænsing eller et scoping element i den. Vi brainstormede lidt på det endte op med at indse, at det som manglede i definitionen var forretningsvisionen.

Et projekt er således

".. a collection of value scheduled for realization within a well-defined business vision"

Hvorfor er det overhovedet vigtigt? Jo for os her på den Blå Avis er det væsentligt i relation til at kunne definere projekt-pipelines og også sikre forretningens fulde fokus på et givent højprioritetsprojekt. Hvis man eksempelvis er ved at udvikle en applikation til styring af hotelværelsesreservationer, og produktejeren bliver mødt med et massivt pres for at indføre funktionalitet til reservation af lokaler og planlægning af store konferencer, så vil det med en klar og veldefineret forretningsvision for hotelværelsesreservationsprojektet (laaangt ord) være lettere at se at lige netop et konferenceplanlægningsmodul er lidt uden for scope.

Jamen hvorfor er det vigtigt at kunne se det? Hvorfor ikke bare smide det hele i backloggen og køre videre? Jo, projektet vil så i givet fald ikke længere have karakter af et projekt, men nærmere et program (paraply for mange projekter), og det vil besværliggøre kommunikation og forståelse blandt alle involverede. Det er også vigtigt for at undgå en projektdefinition, som i yderste fald ville ende med at se hver enkelt sprint, som et projekt.

Gode bøger til det agile folk...

På AgileJoe's blog fandet jeg en udmærket bogliste over bøger med fokus på agilitet.

Jeg kan i hvert fald anbefale:

• Berkun, Scott. The Art of Project Management
• Cockburn, Alistair. Crystal Clear
• Cohn, Mike. Agile Estimating and Planning
• Derby, Esther, and Diana Larsen. Agile Retrospectives

Disse bøger har alle sammen givet mig ny og værdifuld indsigt. Derudover har jeg - inspireret af listen - tænkt mig at læse:

• Collins, Jim. Good to Great
• DeMarco, Tom, and Timothy Lister. Peopleware: Productive Projects and Teams

Definition på et projekt

Jeg mener den klassiske definition på et projekt er noget i retningen af "relaterede opgaver med bestemt mål og afgrænsning i tid" eller "at nå et bestemt mål indenfor et fastsat tidsinterval"...

I hvert fald er det disse temaerne omkring plan, tid og opgaver, der danner grundlag for de klassike definitioner. Men ingen af disse på særligt godt på projekter baseret på agile grundprincipper. Jeg stødte i dag på en definition, som jeg selv godt kunne lide:

"A project is a collection of value scheduled for realization"

Den siger nemlig ikke noget om opgaver, tidspunkter eller planer - blot at værdi sættes til realisering. I Scrum eksempelvis vil det jo så være efter hver 30 dages periode (sprints)... Brug den eller noget der minder om, når nogen spørger dig om, hvad et projekt egentlig er - eller brug den blot til hele tiden at minde folk i organisationen om, hvad det projektet er struktureret omkring.

Agilt lederskab...

“I can’t change the direction of the wind, but I can adjust my sails to always reach my destination.”
– Jimmy Dean

Set på http://learningzone.wordpress.com

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 #2

Jeg faldt over denne youtube video som berører emnet fra et produktsynspunkt. Udover manden har en ufattelig kedelig stemme, så er det han viser og taler om faktisk ret så interessant. Næste gang du står og har problemer med at forklare forretningen, hvorfor agile er så godt, så husk på, hvad du får fortalt her.

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...).