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 #3 - Selvledelse

Selvledelse er i følge Det nationale kompetenceregnskab (s.12) en kompetence baseret på

"...evne og vilje til via eget initiativ at beslutte og gennemføre opgaver i
arbejdet i overensstemmelse med virksomhedens strategier."

Selvom definitionen er lidt stiv, så kan jeg godt lide dens fokus på, at det både er et spørgsmål om evne og vilje. Selvledelse kommer ikke af sig selv. Det er en kompetence, som individerne på et givent team skal opøve og ikke mindst ville.

Det enkelte individ skal være indstillet på at bryde med vaner og hele tiden udfordre sig selv og sit eget standpunkt, men samtidig også turde stille samme krav til andre. Det kræver både evne og vilje. Først når alle på et team gør det, vil teamet blive reelt selvledende og selvorganiserende.

Som leder er dit job, som jeg ser det, at opstille de rigtige rammer for ovennævnte kan ske. Ledelsesarbejde skal baseres på

• tillid fremfor kontrol
• motivation fremfor ordrer
• uddelegering af ansvar fremfor uddelegering af opgaver

Der er sikkert også mange andre ting, men det er i hvert fald et godt sted at starte, og husk på, når man uddelegerer ansvaret, så kan man faktisk også tillade sig at stille spørgsmål ved planlægning og løsning af opgaver, hvis planerne skrider, for nogen har jo taget ansvar for planlægningen og løsningen. At modtage og acceptere ansvar er lig med at bevæge sig væk fra ansvarsfraskrivelse, som efter min opfattelse er det største problem ved projektledelse baseret på command-and-control tankegangen.

Jeg slutter med et godt team-citat hentet fra en fantastisk god historie om transitionen mod Agile:

"The first thing we learned was that we needed to make open and honest
commitments as a team to produce high quality software every iteration. It’s not
as easy as it sounds. You need to check your ego at the door. There are no
heroes on our team….our team is the hero. There are no goats on team…our team is the goat. We sink or swim together."

Et godt link til danske artikler om selvledelse og teams kan findes her

Velocity.... fart hvad kan man bruge det til?

Hvis i har tid så læs følgende artikler med hver deres perspektiv på, hvad konceptet velocity kan tilføre en agil projektproces:

• Understanding your Velocity
• Should we measure velocity?

Velocity er et ret simpelt koncept, som bygger på Mike Cohn's ide om at man skal estimere i størrelse og uddrive farten igennem udførelse - estimate size, derive duration - og på den måde opnå en empirisk kontrolleret forståelse for den fart, hvormed et givent projektteam kan eksekvere en given opgave (eller user story).

Den del som tiltaler mig er, at eksekveringen af "estimat-timer" (som Cohn ynder at kalde story points for at undgå forvirringen med kalender-timer) adskilles fra estimatet selv. I alt for mange år har man talt om at estimater aldrig stemmer overens med de faktiske timer, og så har man brugt ligeså lang tid på at udvikle metoder til at foretage beregninger på estimater up-front for at gøre dem mere præcise osv. Hvorfor?

For mig at se er det temmelig indlysende, at et estimat givet på et tidspunkt, hvor viden om projektet og de konkrete projektopgaver er lavest (=dvs i begyndelsen af et projekt), aldrig kan indfri et ønske om 100% præcision. Det gør dog ikke estimater ubrugelige. Estimater fortæller jo stadig om et projekts størrelse og kompleksitet i grove træk, og det er faktisk meget værdifuldt i forhold til planlægning af projektet, og måske endnu vigtigere: porteføljeplanlægning..

Hvad synes i? Bruger i velocity på jeres projekter? I givet fald hvilke erfaringer har i gjort jer med det?

Teams #2 - Tillid

Hvad skaber grobunden for et velkonsolideret og high-performance team? Jeg tror, at det er det samme, som venskaber er bygget ovenpå: tillid og respekt. Tillid: at man har tillid til den andens adfærd og handlinger udføres med det bedste ønske i forhold til en selv. Respekt: at man respekterer hinanden og de forskelligheder man måtte have, og faktisk bruger respekten til at lære hinanden noget nyt hele tiden.

Vi har under Scrum-møder den sidste måneds tid stillet det samme spørgsmål (efter de tre andre..): Respekterer vi hinanden og hinandens forskelligheder? Det virker måske lidt too-much-agtigt og akavet, men formålet med spørgsmålet har været at bringe et konstant fokus på, at man skal se hinanden som ligeværdige i forhold til teamets mål og opgaver, og kunne stole på hinanden i forhold til, at hvis en udfører en opgave på en bestemt måde, så har andre på teamet respekt nok til at lade denne person udføre opgaven på denne måde, og ikke mindre, hvis nu opgaven er forkert udført, så har andre personer respekt nok til at turde indgå i dialog herom.

Tilliden har jeg hele tænkt som et biprodukt af fokuseringen på respekt, men efter at have læst en slide-præsentation af Diana Larsen om tillid og teams, så ser jeg nok lidt anderledes på det. Her er f.eks 21 gode tips (på engelsk) til at forbedre/skabe tilliden på ens teams:


1. Trust first—To get trust, give trust and act trustworthy
2. Set a tone for interaction and collaboration from the beginning
3. Identify clear, consistent purpose and performance goals
4. Communicate openly, freely, and honestly
5. Listen carefully and seek fairness
6. Develop comfort with discussing mistakes, concerns, and limitations
7. Respect each other’s opinions
8. Learn about each other’s perspectives
9. Establish strong business ethics
10. Visibly do what you say you’ll do
11. Interact with the team consistently and predictably
12. Decide how the team will decide
13. Take responsibility for team action
14. Give credit to team members
15. Empower team members to take risks and act
16. Make yourself available, accessible, and responsive
17. Show awareness, sensitivity, and support for the needs of other team members
18. Maintain confidences
19. Watch your language
20. Create social time for the team
21. Expect and allow emotional release, find a safe space to vent

Lidt ferielæsning

Jeg er ivrigt læser af bloggen All About Agile Development og har med stor interesse fulgt med i føljetonen 10 Key Principles of Agile Development. I den forbindelse har jeg samlet alle indlæggene til et lille hæfte, som jeg synes i skal bruge en ledig stund på at læse:

10KeyPrinciplesOfAgile.pdf

God jul og happy agiling :)

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.

Inspect-and-adapt

For at få størst udbytte af sit webdesign i forhold branding, klarhed, usability, budskaber etc. er det vigtigt at være stærkt iterativt orienteret. Overordnet UI design er på mange områder et levende eksempel, hvor effektiv inspect-and-adapt praksissen omkring softwareudvikling virkelig kan være. Jeg læste en artikel på Joel on Software, som havde en meget interessant case på området.Sat på spidsen kunne parolen for artiklen være noget i retning af:

"Det er ikke negativt, når kunden kommer og vil have lavet noget om! Det er
værdiskabende, og går man mod det, leverer man en dårligere vare."

Inspect-and-adapt gælder hele vejen igennem et projekt og på alle niveauer:

1. Software deles ind i værdiskabende releases defineret af forretningen (product owner). For hver release vurderes feedback fra kunder og brugen af systemet (inspect) i forhold til den overordnede releaseplan med henblik på at definere nye releases endnu skarpere i forhold til forretningsværdi (adapt)

2. Resultatet af en sprint demonstreres (inspect), så kunder eller forretningen kan give nødvendigt feedback, som teamet kan reagere på (adapt)

3. Efter hvert sprint holdes et retrospective, som sikrer at sidste sprint vurderes grundigt af teamet i forhold til ting, der går godt og ting, der kan forbedres (inspect), og at der bliver sat handleplaner op for de væsentligste ting (adapt)

4. Hver dag holdes der team-standups, hvor arbejdet vurderes (inspect) op i mod den plan som teamet har lagt (adapt)

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

I disse DASH 8-tider...

Jeg har lige læst et indlæg (http://www.think-box.co.uk/blog/2006/01/aeroplane-in-flight-metaphor-for-agile.html), hvor det at flyve bliver brugt som metafor på (agile)-softwareudvikling og projektplanlægning. Ideen er, at mange af de mekanismer, der er på spil i agile development, direkte kan overføres til det at holde et fly i luften og få flyet frem til dets destination.

Indlægget har mange spændende betragtninger på agile development ytret gennem fly-metaforen, og jeg er sikker på, at ideen er god og kan bruges til at forklare ikke-indviede personer grundtanken bag agile devlopment, spørgsmålet er blot, hvor god er en fly-metafor er lige nu i disse DASH 8 tider :)

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.

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

Lær Scrum på fem minutter...

Vi arbejder lidt med at forbedre/forandre vores processer her i Den Blå Avis disse dage. Vi har talt en del om Scrum i den sammenhæng. For mig at se er noget af de geniale ved Scrum, at den separerer udviklingsprocess fra projektprocess, hvilket gør det utroligt simpelt at forstå Scrum (og også at Scrum selvfølgelig ikke kan leve uden en god udviklingsprocess!).

Men alligevel kan det være svært at forstå og desto vigtigere: at kunne overbevise folk om styrkerne ved Scrum. Jeg har fundet et lille skriv desangående, som jeg synes gør sit job temmelig godt. Læs det, brug det og giv det til alle mulige (interessante) personer i din organisation. Det er indbydende og folk skal nok læse det, det tager jo kun fem minutter :)

God linksamling

Jeg fandt denne linksamling med artikler, ressourcer, websites og meget andet vedrørende agile udvikling og ledelser. Smider den i vores liste af links også. God læsning!