h1

Ena teamet med en Working Agreement

torsdag, 23 september, 2010

Definition of DONE är ett viktigt verktyg för det agila teamet för att för att teamet som veta vad som förväntas av dem innan de får lov att  säga ”Nu är vi helt klara med funktion X!”. Men Defintion of DONE beskriver inte hur vi jobbar eller vilka principer och värderingar vi värderar och eftersträvar. Det här är teamets ”Working Agreement” kommer in i bilden, ett sorts av kontrakt som beskriver samarbetet, processen och principerna.

I mitt nuvarande uppdrag har teamet under kort tid växt kraftigt och vi har diskuterat mycket hur vi ska samarbeta bättre och mer fokuserat, både internt i teamet men även gentemot våra beställare och stakeholders. Därför har behovet vuxit fram att dokumentera vårt sätt att arbeta och enas kring vad vi tycker är viktigt.

Dels har vi under årets lopp etablerat rutiner och en rytm, men vi har också haft många workshoppar på sistone där vi diskuterat hur vi vill jobba framöver och hur vi behöver ändra vårt angreppssätt för att kunna lägga i en ännu högre växel. Alla i teamet har engagerats i dessa diskussioner men även våra beställare, våra mottagare av systemen i förvaltning och berörde avdelnings- och it-chefer. Idag påbörjade jag arbetet att summera allt i en ”Working Agreement”.

.

Innehåll i en Working Agreement

En Working Agreement innhåller saker som till exempel (och vårt är inget undantag):

  • Daily Stand-Ups – När och var hålls dom? Vilka är bjudna? Hur ser rutinen ut?
  • Planering – Hur genomförs Sprint Planning, Pre-Sprint Planning, Story Time Sessions, etc. När går de av stapeln? Vad är målet för respektive möte? Vem förväntas förbereda vad? Osv.
  • Test- & Kvalitetsstrategi – Hur testar vi? Vad testar vi? Vilka testar? Hur samarbetar teamet med beställaren i acceptans-testandet?
  • Principer och värdering – Vilka principer och värderingar vill vi att alla i teamet värnar om och lever efter? Vad är viktigt för oss vad gäller dialog och samarbete?
  • Hantering av buggar och defekter (under sprinten, efter sprinten)
  • Produktägarens ansvar
  • Scrum Masterns ansvar
  • Rapporter, Burndowns och Protokoll – Vilka behövs? Vem behöver dem? När önskas dom?

.

Workshoppa fram en Working Agreement

Enklaste och bästa sättet är (såklart) att bjuda in alla berörda till en workshop där ovanstående punkter diskuteras igenom ordentligt. Var inte snål med tiden då många av punkterna kan väcka mycket diskussion och debatt och det är viktigt att alla enas och håller med om det som slutgiltigen skrivs ner i en Working Agreement.

.

Signering

När Working Agreement diskuterats klart och formaliserats i text bör var och en i teamet skriver under på att man håller med och att man lovar att anstränga sig för att leva upp till överenskomna principer och värderingar och att man ämnar jobba efter den process man tillsammans kommit överens om.

När en ny teammedlem introduceras till teamet ska såklart även denna ta del av Working Agreement samt ges möjlighet att påverka och diskutera innehållet innan man skriver på.

.

Att vara agil betyder att lära sig

En Working Agreement är på inget sätt något heligt som är skrivet i sten. Kommer teamet fram till att man vill jobba på ett annorlunda sätt eller om nya principer och värderingar växer fram gäller det att kontraktet uppdateras så att det reflekterar detta.

Ha som vana att på Sprint Retrospective ställa er frågan om det är något som behöver justeras, uppdateras, tas bort, läggas till eller öppnas upp för diskussion.

.

Erfarenheter och tankar?

Har du erfarenhet av att sätta ihop en Working Agreement (eller liknande konstruktion) i ditt team? Hur gick ni tillväga och hur har resultatet fallit ut? Har det hjälpt teamet?

.

Annons

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com-logga

Du kommenterar med ditt WordPress.com-konto. Logga ut /  Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut /  Ändra )

Ansluter till %s

%d bloggare gillar detta: