Hej

Kan det virkelig passe at den næst største gruppe (målt på antal medlemmer) i Version2 ligger i den nederste halvdel hvad angår aktivitet (det er en måned side det sidste indlæg)? Uden aktivitet tiltrækker vi ikke nye deltagere og snart må vi se os overhalet af EA!

Størrelsen er dog ikke et mål i selv! Hellere en lille og agil gruppe (med hyppige leverancer) end en stor gruppe der er mere traditionel og hvor der kun kommer resultater med lange mellemrum ;-)

Agile udvikling er jo ikke en silver bullit, så der må være en masse vi kan diskutere. Hvorfor er der så ingen aktivitet?

Er alle gruppens medlemmer travlt optaget af at sprinte så vi ikke har tid til at blogge (så skulle vi måske overveje om vi har committed os for hårdt ift. vores kunder).

Eller er gruppens formål ”Denne gruppes formål er at diskutere brugen af agile udviklingsmetoder. Fordele og ulemper, samt "best-practice" for specifik?

Kun fantasien sætter grænser for hvad vi kan spørge hinanden om, eller hvilken erfaring vi ønsker at dele med andre – blot det handler om agil udvikling.

Så kom ud af busken og blog med jeres kollegaer i branchen om det i forhåbentlig brænder for – agil udvikling, uanset om det er XP, Scrum, DSDM eller you name it!

Stig Efsen, Trifork

Therese Hansen

Ja ja, skal nok :-).

For nyligt læste jeg et blogindlæg på en af mine yndlingsblogs om agil udvikling. Blogindlægget er en reaktion på et indlæg i Jyllands-posten omkring Scrum og kan læses her:
http://blog.erratum.dk/2008/05/en-artikel-p-jpdk.html

Der hæftes især ved, at Per Palmkvist Knudsen som skrev det oprindelige indlæg i JP, havde nogle negative erfaringer med Scrum - blandt andet:
1)teamet bliver indadvendt
2)Teamet let kommer til at overse afhængigheder til andre projekter
3)Teamet let overser forudsætninger, der skal være på plads

Er det også jeres erfaringer?

  • 0
  • 0
Kristian Thy

1) teamet bliver indadvendt

Eller teamet bliver sammentømret. Godt eller skidt i en tid hvor det kan være svært at holde på de gode folk?

2) Teamet let kommer til at overse afhængigheder til andre projekter

Skyldes det ikke at kunden ikke gør teamet opmærksom på de andre projekter? Det er jo kunden der bestiller teamets arbejde, så må han også bestille interop.

3) Teamet let overser forudsætninger, der skal være på plads

Forudsætninger for hvad? Drift? Involver driftsfolk. Test? Involver testfolk. Se også 2.

(Deklaration af interessekonflikt: Jeg deltog som udvikler i den nævnte sprintrække på krak.dk.)

  • 0
  • 0
Kurt Frederichsen

Hmmm - indlæggene omtaler "Scrum" og "agil" som om det er det samme fra gang til gang!

Min erfaring er at den tilgang langt de fleste har til "Scrum" er stort set lige så forskelligartet som der er personer der implementerer det.

Derfor tror jeg ikke at man kan sige hvad "Scrum" har af godt og skidt - men at man i forskellige implementationer kan udtale sig om hvordan de virker.

Kristians svar er netop at der findes løsninger, hvis man kender og forstår mulighederne i "Scrum" og kan få lov til at bruge dem... ...men i den virkelige verden er der ofte ikke en Scrum-ekspert ved hånden - ofte er det ildsjæle der efter at have læst en bog og snakket med andre, sætter noget igang. Måske har de ligefrem ScrumMaster kursus, der iøvrigt INTET siger om hvordan man ruller det ud i egen organisation. Og i praksis er det heller ikke alle frihedsgrader til rådighed. Måske er ikke alle relevante komptencer med i teamet - eller "kunder" er repræsenteret af én der reelt ikke er tilstede eller ikke ved nok - eller en projektleder kræver at han bestemmer nogle af detaljerne - eller...

Hér har vi måske bagsiden af den agile medalje... ...og hvordan får man så de rigtige ting til at ske?? ;-)

  • 0
  • 0
Rasmus Christensen

Spændende den med at overse ting.
Nu er et Scrum team jo ikke blot "udviklere", men et team, det være sig designer, domæneekspert, arkitekt mm. Så mon ikke arkitekten med den andel han giver teamet bør se de andre systemer? Og mon ikke domæneeksperten/useability eksperten vil hjælpe Product Owner med at skabe de rigtige produkt?

  • 0
  • 0
Stig Efsen

Jeg synes det er nemt at forklare hvilke principper Scrum bygger på. Når jeg underviser i Scrum oplever jeg også at deltagerne nemt kan forstå og forholde sig til de tre roller, de tre møder og de tre artefakter der produceres for at understøtte processen.

Men her stopper det nemme så også rimelig brat!

Som Kurt nævner, lærer man ikke på et Scrum Master kursus hvordan man skal implementere Scrum i sin organisation. Og det er flere gode grunde til.

For det første så er man indenfor Scrum Alliance interesseret i at alle får den samme ballast og ordforråd (ligesom hvis man tager en SCUBA diver certifikat) – det kan der sikkert siges meget for og imod. Hos Trifork sender vi alle på Scrum kursus – både udviklere, sælgere, bogholder, receptionister mv. Det betyder at alle kan forholde sig til hvad de har i ’backloggen’ og kan få prioriteret den i forhold til hvad der giver værdi for virksomheden.

For det andet så ligner Scrum mange andre metoder på mindst et væsentlig punkt - man bør nøje vurdere hvad der vil virke godt og ikke vil virke i sin organisation, før man starter en implementering.

For det tredje så er Scrum ’kun’ et ledelses rammeværktøj. Der er ikke beskrevet stolpe op og ned om hvordan man skal beskrive krav, hvordan man skal dokumentere sit design, hvordan man skal bygge sin software eller hvordan den skal testes. Det overlades til ’læseren’. En god idé kunne naturligvis være at anvende XP teknikker.

Man kunne selvfølgelig foreslå at Scrum kunne indeholde flere eksempel på hvordan man implementerer i forskellige typer organisationer, men som Henrik Kniberg skriver i sin bog så handler det om at eksperimentere og finde den rette løsning for organisationen og de mennesker der arbejder i den. Der er rigtig mange muligheder og alle er endnu ikke udforsket. På JAOO konferencen i sept./oktober er der fokus på hvordan Scrum implementeres i store organisationer.

Scrum er 20% teknik og 80% kultur. Vi er alle begrænset af vores erfaring og dårlige vaner. At ændre disse dårlige vaner til noget nyt og bedre er ekstremt svært og kræver både mod, ledelsesopbakning, lidt kapital at starte med og så en vilje til at ville det bedre. Det kræver ikke mindst evnen til at fastholde forandringen selv om det ser svært ud – og det bliver hurtigt svært fordi man når at gennemføre en hel udviklingscyklus på en måned eller mindre.

Bedste råd er at komme i gang og være agil, dvs. vedvarende at tilpasse sig sine omgivelser - ’inspect and adapt’.

Stig Efsen, Trifork

  • 0
  • 0
Kurt Frederichsen

Ja, Stig, du ender med at slå hovedet på sømmet! Scrum (og mange andre agile metoder) giver kun 20% af svaret! ;-)
Det der ville være interessant, var hvordan de mange ildsjæle kan komme i mål! Dem der griber f.eks. Scrum med begejstring og kan se hér er en vej, hvor de selv kan tage ansvar og skabe resultateter - hvordan kan de blive i stand til at ændre vaner og leder forandringer i deres organisationer, der muliggører rigtig agil udvikling? Hvordan får vi den dybe forståelse for de menneskelige og psykologiske mekanismer der er indbygget i f.eks. Scrum, der i virkeligheden sætter os i stand til at tilpasse så vi undgår faldgruberne og det kommer til at virke? Hvordan bliver vi i stand til at håndtere forandringsledelse der holder målet indtil de gamle vaner er aflært og de nye er blevet til rigtige vaner??

Det er denne del af de agile metoder jeg finder er den virkelige udfordring - og det er hér jeg er rigtig nysgerrig efter at høre om erfaringer, hvor man kan komme i mål uden at have 20 års erfaring og en MBA i ledelse af forandringer og procesforbedring...

  • 0
  • 0
Bent Myllerup

Scrum handler først og fremmest om menneskers måde at arbejde sammen på. Reglerne er få og simple, men alligevel kan det være svært at få det til rigtigt at fungere. Hvorfor mon det?

Jeg har prøvet at implementere Scrum nogle gange – måde som leder af software-afdelinger og som ekstern konsulent og det er min erfaring, at man kommer bedst igennem udfordringerne hvis man forholder sig til at det er en forandringsproces man har igangsat – og at man agerer efter dette. Scrum er mere end nye metoder. Det handler også om at bygge sine teams op og forholdes sig til, at den ledelsesmæssige tilgang skal være afpasset med det faktum at man virkelig ønsker selvorganiserende og højt performende teams.

Ud over at undervise teams, ScrumMasters og Product Owners i Scrum, få etableret prioriterede og estimerede Product Backlogs, startet byggeservere og kode-repositories, etc. gør jeg en del ud af at coache hele teams og individuelle nøglepersoner. Typisk laver jeg nogle teambuilding sessioner i starten af et projekt og tager så temperaturen under vejs. Dette kan være gennem retrospectives hvoraf det kan fremgår at der skal gås lidt mere i dybden med specifikke teamrelaterede udfordringer. Dem tager vi så ved en særskilt aktivitet.

Kurt efterlyser hvordan man kommer i mål uden 20 års erfaring og en MBA i forandringsledelse. Jeg har i forbindelse med min uddannelse som systemisk coach, skrevet en artikel som behandler nogle grundlæggende aspekter ved udvikling af teamidentiteten samt beskriver nogle konkrete øvelser man kan gennemføre. Denne artikel kan læses på Scrum Alliance’s hjemmeside: http://www.scrumalliance.org/articles/98-coaching-scrum-teams

Bent Myllerup, Agile Coach

  • 0
  • 0
René Schalburg

Når jeg ruller Scrum ud benytter jeg flg. simple metode:
0) PO og jeg har en eller flere korte sessioner hvor vi ser på PBL, specielt om entries er anvendelige til sprint planlægning, men også om prioritet og estimat er rimelige fornuftige.
1) Alle team-members, PO og SM får så en halv dags intro af mig. Introen er en nedkogt SM træning og fukuserer især på følgende:
1.a) At arbejde som team vs. at arbejde som gruppe.
1.b) Krav til SBL indgange, specielt præcision og estimerbarhed.
1.c) Selve processen, hvilke møder, hvilket formål med møderne. Jeg indskyder et fast "teknisk review/demo forberedelses" møde.
1.d) Roller og ansvar!!
2) Typisk næste dag, starter første sprint med planlægning. Jeg deltager og coacher, process såvel som teknisk(hvor jeg kan). Hvis vi kan nå det tages første Scrum sidst i denne session. Hvis vi (ikke mod forventning) ikke bliver færdige, fortsætter vi næste dag hvor vi stoppede.
3) Jeg deltager i (næsten) alle Scrum møder i første sprint. Hvis der er skeptiske personer får de særlig opmærksomhed, evt. 1-on-1 med mig for at få afstemt forventninger og løst op for forhindringer.
4) Vi afholder teknisk review/demo forberedelse, også med mig.
5) Vi afholder selve demoen med særligt indkaldte stakeholders (med igen)
6) Vi afholder 1ste retrospective med fokus på oplevelsen i 1ste iteration. Her bliver det meget vigtigt at jeg har været med i alle Scrum's, så jeg kan vende "det hele" - og dermed vise at teammembers (og andre) tages seriøst.

Det hele gentages i de to næste sprints, hvor jeg gradvist skruer ned for mit engagement. Dog deltager jeg i de fire store møder (plan, review, demo, retro) fuldt ud - og vurderer så om jeg skal fortsætte med det i endnu et par sprints.

I hele perioden er jeg "on call" for alle involverede, med løfte om at issues ikke kommer videre uden aftale.

So far - har den største udfordring været enkelt personer som har haft svært ved at nedbryde og estimere. Pga. dette får de lang snor i 1ste sprint, hvorefter jeg strammer op og indfører estimation poker og meget specifikke task kort.

René Schalburg, Terma

  • 0
  • 0
Kurt Frederichsen

Hej René

Tak for din meget præcise gennemgang - nu er det snart 1½ år siden og jeg har udviklet på min tilgang siden - og faktisk minder den meget om det du gør... Der ligger megen viden og erfaring bag dine valg, som virker i din organisation. Men det der egentlig lå i mit spørgsmål var også mere hvordan de stakkels folk, der læser bogen/tager kurset og begejstres - hvordan kan man klæde dem på til at klare det selv?
Hér bliver jeg mere og mere overbevist om at det kan man IKKE - man forudser ikke de menneskelige og organisatoriske faktorer og bliver ramt af en boomerang før eller siden! Og så bliver det som én sagde - man skal prøve at implementere Scrum mindst 3 gange, før det rigtig går op for én hvad det er der skal til for at det virker - eller alternativt få en "ekspert" til at hjælpe!

  • 0
  • 0
René Schalburg

Det kræver i hvertifald meget MERE end man får på diverse standardiserede kurser!
Man kunne vel forestille sig kurser specielt rettet imod opstart af Scrum teams - så vidt jeg ved findes de bare ikke p.t. - men det er vel også i høj grad team opstart / scrum indførsel konsulenterne lever af?!
Givet en nogenlunde kunde database kunne jeg ihvertifal leve godt af Scrum opstart. Jeg bruger 80-200 timer på et team, alt efter hvor meget modstand og mangel på "team" (vs gruppe) jeg oplever. (Så er der en anden som er SM - men ham træner/coacher jeg naturligvis også;-) )

  • 0
  • 0
Henrik Sternberg

Det er godt sagt: 20% teknik og 80% kultur.

Det selvforvaltende team er nøglen til at opnå den effektivitetsforøgelse i systemudviklingen, vi leder efter. Når vi implementerer f.eks. SCRUM i ny organisation, gør vi det ikke isoleret, men i en eksisterende kultur. Mine erfaringer siger at agile projekter, i hvert fald i større organisationer, ofte kan have svært ved at "holde fast", og at de over tid bliver isoleret. Agile projekter har en tendens til at udstille kulturelle modsætninger i deres organisation, som organisationen ofte reagerer negativt på. Disse modsætninger kan f.eks. vise sig når det agile projekt påpeger at fastpriskontrakter på baggrund af udelukkende analysearbejde ikke er et fagligt forsvarligt grundlag for at tilfredsstille kundens behov.
De 20% teknik er det letteste arbejde (men jo ikke altid let). Det retter sig mod teknikkerne. De 80% kultur er en stor udfordring. At tilpasse hele organisationens kultur til samarbejde baseret på tillid, mod og åben kommunikation er den agile bevægelses største udfordring.

læs mere på:
http://www.agil-procesforbedring.dk/index-filer/den_agile_organisation.htm

  • 0
  • 0