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?

Årsags/Effekt diagram

Et af de værktøjer jeg, engang imellem, finder frem fra min værktøjskasse er et "årsags-effektdiagram".

Se en beskrivelse her: http://en.wikipedia.org/wiki/Ishikawa_diagram

Det er et super værktøj til at brainstorme over et problem på - forleden brugte jeg og en anden chef kollega på dba.dk værktøjet til at identificere en række årsager til store udfordringer vi har lige nu.

Den store udfordring med værktøjet er at det giver lidt et sortsyn på situationen - du får en rigtig god liste over årsager til problemer, og viser typisk hvor komplekt situationen er.

Har du nogle erfaringer med dette eller andre værktøjer?

------

Jeg har ikke selv brugt det, men her har du et online tool:

http://www.pptmagic.com/downloads/ProjectMgm/Fishbone.swf

Estimering

Vi er inden for de sidste par måneder begyndt at drive estimeringen ved hjælp af poker planning (se tidligere indlæg her).

Jeg er stødt på en meget god artikel ang. emnet. Den indeholder forskellige tilgange til estimering og deres fordele og ulemper:

http://leadinganswers.typepad.com/leading_answers/2007/11/agile-estimatin.html

Når jeg skal forklare, hvorfor man ikke skal og kan bruge meget tid up-front på estimering, så tegner jeg altid en graf som nedenstående hentet fra artiklen:

Projektleder stillingsopslag

Den Blå Avis a/s som medie og it-virksomhed
dba.dk er Danmarks største handelsplads på nettet og et af de mest besøgte sites med 1,4 mio. unikke besøgende om måneden og 90 mio. sidevisninger. Vi er på forkant med brug og udvikling af it og beskæftiger i alt ca. 200 medarbejdere, primært lokaliseret i unikke omgivelser på Marselisborg lystbådehavn i Århus.

Projektafdelingen
Det er projektafdelingens ansvar at sikre styring og ledelse af forretnings- og it-projekter, primært softwareudviklingsprojekter for vores online-forretning www.dba.dk. Vores it-afdeling er i en spændende udviklingsproces, hvor vi satser 100% på MS-.NET framework og en moderne it-platform baseret på Microsoft produkter.

Som vores nye projektleder indgår du i projektafdelingen, hvor der i forvejen sidder tre yderst kompetente projektledere, og du vil typisk komme til at arbejde med et til to samtidige projekter af 4 – 8 måneders varighed.

Dine arbejdsopgaver består bl.a. i følgende:

• Samarbejde med forretningen og udfordre denne omkring krav og løsninger
• Samarbejde med projektteam om teknisk analyse, estimering og planlægning
• Samarbejde med forretningen og projektteam omkring arkitektur, QA og processer
• Udarbejde og vedligeholde projektplan
• Projekt kick-off
• Styregruppemøder, SCRUM møder
• Kommunikation til og fra projektteamet samt coaching af projektteamet

I din hverdag vil du opleve stor erfaringsudveksling med de øvrige projektledere omkring projektmodeller, procesforbedringer og udfordringer i teamet. Du får stor berøring med forretningen og bidrager væsentligt til at skabe synlighed omkring strategisk vigtige projekter.

Dine faglige kvalifikationer:

• Videregående uddannelse indenfor it eller medie
• Dokumenteret erfaring fra ledelse af produktudviklingsprojekter
• Kendskab til webudvikling og gerne til agile udviklingsprincipper, fx SCRUM
• Gerne projektledercertificering, fx IPMA, SCRUM eller lignende

Din person:

• Du er struktureret og har sans for de væsentligste detaljer
• Du har overblik og forståelse for forretningens behov
• Du er samarbejdsorienteret, udadvendt og kan begejstre et team
• Du har en gennemslagskraft, der sammen med dine øvrige personlige og faglige kvalifikationer sikrer fremdriften i et projekt.

Vi tilbyder dig ansættelse på en innovativ arbejdsplads med fokus på kvalitet og udvikling og en gage, der fuldt ud vil modsvare dine kvalifikationer. Du vil opleve en ledelsesform med stor respekt for individet, og et miljø, hvor vi kombinerer humør og højt fagligt niveau. Du får en udfordrende hverdag, og det er vigtigt at du kan fungere på jobbet og privat. Tiltrædelse snarest muligt.

Vil du vide mere om jobbet, kan du kontakte Projektchef Daniel Mathiasen for en uforpligtende snak på mobil: 20 10 70 11.

Send din ansøgning til job@dba.dk mærket Projektleder i emnefeltet. Vi vurderer løbende de indkomne ansøgninger, og du kan regne med et hurtigt svar.

En leders kommunikation...

Jeg faldt over en artikel omkring vigtigheden af en minimalistisk tilgang til kommunikation - når du forsøger at nå dit hold.

I korte træk, her er de 6 regler præsenteret i artiklen

1. Minimalistik
   Beskeden skal være kort og have dybde, et eksempel kan være "en tommelfingerregl"
2. Overraskende
   Noget der lyder som en selvfølgelighed er ikke nok - prøv med en ulogisk selvfølgelighed ;-)
   
3. Konkret
   Brug tiden på at blive konkret, overfladisk kommunikation forbliver overfladisk
   
4. Troværdighed
   Sikrer dig at beskeden er troværdig
   
5. Følelser
   Snak til hjernen - og til hjertet!
   
6. En historie
   Historier skaber billeder, og vi husker billeder - fortæl en historier, men husk de 5 foregående regler
   

Det er svært - jeg ved det, jeg øver mig stadigvæk hver eneste dag.

Læs hele artiklen her: An interview with Chip Heath - The McKinsey Quarterly

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.