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

Produktudvikling: Amazon teknologi

Når man arbejder med web som primær platform for ens applikationer, så vil man også uundgåeligt komme til at beskæftige sig med performance og scalability problemer knyttet til den trafik, som et pågældende site måtte have.

Amazon som jo har enorm trafik på sitet. Eksempelvis har Amazon 3 millioner checkouts dagligt. For at kunne håndtere den slags trafik må man være mere kreativ end de fleste, hvad angår teknologi som henter data fra data stores. Dynamo er en blandt mange teknologier udviklet af Amazon til at håndtere disse krav:

Dynamo is designed to ensure that, typically, "99.9% of the read and write requests execute within 300ms"

Uanset det load, der måtte være på sitet så vil Dynamo sikre at read/write forespørgsler sker inden for 300 milisekunder for 99,9% af tilfældene. Ret vildt. Men hvad endnu vildere er, så er teknologien designet til at betragte hardware fejl som en naturlig del af dens eksistens:

Amazon’s software systems need to be constructed in a manner that treats failure handling as the normal case without impacting availability or performance.

Den slags problemer påvirker altså ikke ovennævnte performance. Imponerende ikke?

Hvis du vil læse mere om, hvordan Dynamo virker, så prøv at læs Dynamo: Amazon’s Highly Available Key-value Store

Innovation og Scrum/Agile

I mine øjne er der en fare for at kvæle innovation til fordel for kortsigtede leverancer med procesmetoder som Scrum. Hvis man tvinger udviklere til at have fokus på at levere hver måned eller oftere, så vil der ikke være meget overskud til at tænke innovativt... altså innovativt på den måde man ser i virkelig skelsættende produkter. Et godt eksempel er Apples produkter, som er gennemsyret af god innovation på produktudviklingsfronten både hvad angår materialer, hardware, software og samspillet imellem disse. Hvad er jeres holdning til dette? Har i nogle gode konkrete eksempler jeg kan poste her?

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.

Continuous Integration

Bøvler I også med at få lavet et fornuftigt CI setup? Hvordan kommer man igang, hvor er faldgruberne, hvad er de gode ting at gøre? Der er mange spørgsmål i den forbindelse. Her på Den Blå Avis har vi brugt det sidste år på at få fornuftige miljøer op at stå, og det er ikke altid helt enkelt.

Martin Fowler har skrevet en god artikel, man kan starte ud med, hvis man ønsker at hjælpe til med den proces (husk dog at det er udviklerne selv som skal drive det, da de ved bedst...). Jeg synes selv den giver et godt overblik over de problemstillinger man vil støde på i, og ja jeg synes det er sundt for en projektleder eller Scrum Master at have en holdning til og forståelse for den slags.

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?