Posts Tagged ‘collaboration’

h1

Vilka frågor besvarar er Working Agreement?

torsdag, 6 december, 2012

Alla team har någon form av uppfattning kring vad som betraktas som accepterat och bra beteende i teamet mellan teammedlemmar. De flesta vet att kollegor inte uppskattar när du är sen till ett möte. Kanske har ni en tyst överenskommelse kring hur ni röstar och tar beslut.

Vissa team skriver ner sitt beteende- och samarbets-”protokoll” i en Working Agreement.

Du kanske tycker att sunt förnuft täcker det mesta och att skriva ner det känns fåning. Suprise! Sunt förnuft är subjektivt och ni har antagligen olika uppfattningar kring mycket. Toppen! Låt oss diskutera och upptäcka våra gemensamma värderingar.

 

Läs hela blogginlägget här (på engelska på Crisps blogg).

 

 

Annonser
h1

Prototype Driven Development – En utopi?

torsdag, 29 april, 2010

Denna vecka har jag fått seriösa griller i huvudet. Företaget jag höll kurs för i tisdags arbetade hårt med prototyping för att undersöka vilka koncept som fungerade och inte fungerade. Tänk om hela produktbackloggen kunde ersättas med en levande prototyp?

Fram tills i tisdags betraktade jag prototyping endast som ett verktyg för teamet och produktägaren för att flytta en funktioner och features från ”Anarchy” or ”Complex” space ner mot ”Complicated” eller ”Simple” space.

Prototypen blir närmast ett verktyg för groomingen av produkt-backloggen. När produktägare och kund sett och klickat runt i prototypen kan EPIC User Stories brytas ner, detaljeras och prioriteras (eller förkastas). När detta arbete är gjort har prototypen spelat ut sin roll. Den fungerar alltså bara som ett ”hur”, ett verktyg att förstå vad man vill ha och vad som fungerar bäst, ett steg i utvecklingsprocessen på resan mot att leverera värdefull och användbar mjukvara.

Med lite tur kan man ibland återanvända lite kod från prototypen till den ”riktiga” produkten men oftast har den spelat ut sin roll och förkastas till skräpkorgen (eller arkivet).

.

Men nu snurrar (för mig) många nya tankar, åtminstone kring prototyping av gränssnitt och dialoger. POC:ar för att undanröja tekniska frågetecken eller risker lämnar jag därhän för tillfället.

.

För, tänk om…

  • Vi inte alls förkastar våra olika prototyper utan prototypen föds i tidig analysfas och fortsätter sedan leva, förändras och växa genom hela projektet.
    .
  • Prototypen är så enkel att bygga ut och laborera med att Produktägaren själv kan experimentera med att lägga till dialoger, skapa dummy-funktioner och koppla ihop systemet på olika sätt. (Kanske har produktägaren ett prototyp-team till sin hjälp eller så spenderar ordinarie team en viss tid av sin sprint för att skulptera prototypen som ett steg i det kontinuerliga analys- och designarbetet.)
    .
  • Prototypen kan ”spelas upp” i olika skepnader. Man bygger inte en helt ny prototyp för att gestalta en annan variant av dialogen utan prototypen kan ställa in i vilket version vi vill experimentera med denna testkörning. Skepnader och flödesvarianter kan enkelt konfigureras on the fly.
    .
  • Vissa delar av prototyp-produkten består av luddiga dialoger och grova funktioner medans andra är tydligare, mer detaljerade och närmare en implementerbar nivå.
    .
  • Prototypen låter sig delas upp i funktioner och komponenter som teamet kan estimera.
    .
  • Estimaten behöver inte lagras i en separat lista någon stans utan är en del av modellen och kopplas till ”prototyp-komponenter”.
    .
  • Komponenterna kan innehålla dolda attachments som inte syns vid körning. Exempelvis word dokument, sökvägar in i wikin, osv.
    .
  • Komponenterna kan innehålla annan meta-information som t.ex:
    • Prioritet
    • Att-Göra-lista med öppna frågor för produktägaren
    • Vilket team som eventuellt ska bygga funktionen
    • Vilken release/sprint funktionen eventuellt är planerad till
      .
  • Slutligen så går prototypens komponenter att skriva ut som en prioriterad lista. Denna lista kommer snarare likna ett träd med grenar som spretar iväg. Ibland lever flera varianter av samma funktion (User Story) fram tills dess att en av dem implementeras och andra förkastats.

Kommentar: När jag skriver ”komponent” ovan menar jag inte modul eller klass, jag syftar till en dialog eller en specifik funktion i användargränssnittet.

.
.

Om denna fantasi besannas har vi då helt och fullt lyckats ersätta produktbackloggen med en prototyp?

Men varför stanna där? Anta att plattformen och språket vi bygger prototypen med är samma som vi använder när vi bygger den ”riktiga” produkten och att implementera en komponent/funktion i prototypen enbart handlar om reda ut återstående detaljer, skriva koden bakom, testa av samt rensa bort döda versioner och aspekter?

Når vi hela vägen hit är vår release-branch helt enkelt en specifik konfigurering av prototypen. Känns definitivt som en utopi men kanske ett vision att arbeta mot?

h1

”Hur rolig var sprinten?”

tisdag, 6 april, 2010

Idag brände vi av en radda produktiva och roliga team-workshoppar. Först ut på morgonen var en nästan 3,5 timme lång retrospective. Kändes förlösande att konstruktivt och kritiskt granska oss själva, vårt samarbete, vår dialog med (och beroende gentemot) organisationen och styrgruppen.

.

1. Etablerade agenda

Först etablerades dagens syfte och agendan med tidshållpunkter presenterades. Detta dels för att time-boxa passen men också för att skapa en helhetsbild att hänga upp arbetet på.

Tog 2 minuter.

.

2. Tog teamets temp

Det första jag gjorde var att be teamet snabbt och individuellt svara på en rad frågor.

1) Hur rolig var sprinten?

2) Hur nöjd är du med
din egen insats/prestation?

3) Hur nöjd är du med teamets
insats/prestation?

4) Hur bra var teamets förutsättningar
efter avklarad Sprint Planering?

5) Hur hög arbetsro rådde under sprinten?

Skalan gick från 9 (superbra) till 1 (värdelöst). Dessa temp-frågor kommer upprepas varje retrospective. Svaren kommer sparas och trackas (genomsnittliga värdet) över tiden och kan sedan analyseras och diskuteras (t.ex. jämföras mot velocity, drag, etc.)

(Nästa gång kommer vi skriva ner våra poäng först i hemlighet var för sig innan vi sätter upp prickarna. Detta för att minimera risken att påverkas av redan uppsatta prickar. )

När alla hade besvarat frågorna med sina prickar gjorde vi en super kort reflektion men stannade inte upp för djupare analys utan gick raskt vidare till nästa punkt. Syftet med övningen är endast att snabbt få igång tankeverksamheten, minnas tillbaka till den gångna sprinten och få upp energin i rummet.

Totalt tog detta cirka 10 minuter.

.

3. Brainstorming

Efter att vi tagit temperaturen på teamet gick vi snabbt vidare till ”Brainstormning”. Alla tilldelades små post-its på vilka man skulle skriva ner sina reflektioner, åsikter, tankar m.m. och sätta upp dem på väggen. Detta gjordes utan struktur och med högt till tak. Inga åsikter eller känslor är för dumma för att inte tas upp och synliggöras. Närhelst man skrivit en lapp sattes den upp och teamet diskuterade punkten tills alla förstått vad författaren ville säga eller ge uttryck för.

Detta är teamets tillfälle för självreflektion, självgranskning, förlösning, diskussion, tänka högt, dela med sig av gjädje och frustration, fånga upp idéer och förslag på förbättringar.

Om dynamiken i gruppen är sådan att vissa talar högt, mycket och gärna medans andra är tysta och blyga behöver denna del av retrospectiven en struktur och utformning för att alla ska få komma till tals och känna sig delaktiga.

Andreas klurar på sin egen nyss uppsatta lapp

Lapparna sorterades in i följande kategorier:

Roligt! Bra!
Saker som blev lyckade och som teamet ska fortsätta med. Något som var speciellt roligt eller gick speciellt smidigt? Roliga händelser. Bra – men vi kan ännu bättre!
.

Dåligt! Frustrerande! Tråkigt.
Saker som inte gick som planerat. Olyckliga omständigheter. Frustration! Rutiner eller processer som inte funkar som de ska. Saboterande omständigheter.
.

En blomma till…
Speciella tack till speciella insatser. Tack för hjälpen! Beröm. Klapp på axeln.
.
.

Funderingar. Frågetecken.
”Varför …?”, ”Jag önskar jag visste hur … ?”, ”Hur kan vi … ?”, ”Hur lyckas vi … ?”, ”Hur kommer det sig att … ?”
.
.

Ideér. Förslag.
Förslag på förbättringar, saker som kan göras annorlunda. Idéer på hur teamet kan samarbeta bättre, kommunicera bättre, minimera waste, förebygga teknisk skuld, första kund och krav bättre.
.

Denna övning tog nästan ca 90 minuter innan vi kände att vi tömt ut allt vi ville få sagt och tyckt till om det vi ville tycka till om.

OBS! Under denna övning har Scrum Mastern ett stort ansvar. Ingen kritik. Allt ska upp. Scrum Mastern får inte  bete sig defensivt eller sabotera viljan att tala och tänka fritt och högt. Scrum Mastern får inte ta bort eller formulera om lappar. Det skulle hämma möjligheten att nå insikter och få fram allas tankar och synpunkter.

.

4. Summera actions

Efter en fem minuters paus samlade vi våra tankar och gick tillbaka in i vårt war room. Nu var det dags att summera, finna bakomliggande orsaker till frustationer, konkretisera förändringsförslag och idéer.

Alla lapparna gicks igenom, var för sig. Kunde vi komma på en action till lappen satte vi upp den i ”!” rutan. Ibland fick vi klura en stund, kanske backa för att se den större bilden och diskutera en stund innan vi kunde enas om vad lämpligast och effektivast action var. Men vi tog oss igenom alla lapparna och var efteråt oerhört tillfreds med oss själva, vår analys och vår lista över actions.

När vi var färdiga med actions grupperade vi dem. Grupperna denna gång råkade bli ”Sprint Planering”, ”Dagligen”, ”Arbetsro och Övrig-prio”, ”Attidyd/Mentalitet” och ”Externt”. Kanske inte säger dig något men för oss är betydelsen solklar 😉

Detta tog cirka 60 minuter.

Denna övning kan med fördel timeboxas. Gäller såklart övriga övningar beskrivna här också. Det är enkelt att skena iväg och förlora sig i detaljer.

Listan över actions som kräver en arbetsinsats bör inte vara för lång så att den blir en belastning i sig under sprinten. Likaså kan man inte hoppas på att förändra allt man vill på en gång. Ett steg i taget leder troligtvis till beständigare förändringar. Behövs det hjälper Scrum Mastern teamet prioritera det som känns viktigast och ger störst impact.

.

5. Summering för styrgrupp

Denna gång kände vi att det var viktigt att få framföra våra idéer och förslag till styrgruppen samt dela med oss av det vi upplevde var frustrerande för att få ökad förståelse för våra förändringsförslag. Vi presenterade alla actions, svarade på frågor, diskuterade. Mycket givande! Ytterligare några actions kom upp på väggen.

Vi hade mycket att prata om och fick många frågor om våra lappar så innan denna sista övning var över hade ytterligare cirka 60 minuter förflutit.

.

6. Reflektera

Sist reflekterade vi som hastigast över förmiddagens arbete, vad som var bra/dåligt med upplägget och vad vi tyckte om vår prestation och vår gemensamma prestation. Tror det syns på bilden nedan att vi var ganska belåtna 🙂

Nu återstår bara att se hur väl vi lyckas med att genomföra våra actions och följa våra egna förmaningar till oss själva.

Teamet (från vänster): Jag, Andreas, Henrik och Peter

h1

Fingervotering – Blixtsnabb konsensus check

fredag, 26 mars, 2010

Fingervotering, ”Fist of Five”, är en simpel men effektiv teknik för att se om ett förslag har stöd i en grupp.

När det är dags formuleras det eventuella beslutet teamet ska ta (exempelvis av Scrum Mastern). Sedan ombeds varje teammedlem visa vilket stöd de känner för förslaget genom att hålla upp ett antal fingrar som representerar hur mycket de stöttar förslaget, alternativt en sluten näven.

Mycket effektivare än att t.ex. gå varvet runt och be alla uttrycka och förklara sitt stöd (eller ogillande av förslaget) med ord – speciellt när alla är ense ;-p

Sluten näve = ”Jag vill diskutera förslaget ytterligare för jag kan inte gå med på det som presenteras just nu”. Ett sätt att blockera konsensus.

1 finger = ”Jag vill diskutera mera, belysa vissa problem och/eller föreslå några ändringar.”

2 fingrar = ”Jag är ok med förslaget men vill diskutera några detaljer lite ytterligare.”

3 fingrar = ”Jag håller inte med till 100% men kan vara ok med det. Behöver ingen ytterligare diskussioner.”

4 fingrar = ”Gillar förslaget och kommer jobba för dess sak.”

5 fingrar = ”Grymt förslag! Jag leder gärna arbetet!”

.

Konsensus?

Om alla håller upp tre eller fler fingrar antas förslaget ha stöd i gruppen och teamet nått konsensus.

Om någon håller två eller färre fingrar ska dessa ges en chans att förklara sina argument eller tvivel. Teamet diskuterar och argument bemöts. Sedan fingervoterar man igen och fortsätter tills teamet nått konsensus – eller beslutat sig för att lägga förslaget på hyllan och gå vidare.