Archive for the ‘Scrum metodik’ Category

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

 

 

h1

Övning: Agile Values

onsdag, 29 februari, 2012

Nu har jag lagt upp ytterligare material under ”Verktyg och Mallar”. Denna gång blir det en övning som jag själv kört flera gånger med fantastiskt resultat.

”Agile Values” är en diskussionsövning under vilken teamet eller projektet får en chans att fördjupa sin förståelse kring agiles och leans principer, men framförallt en möjlighet att diskutera dem!

Under övningens gång (som tar cirka 90-120 minuter att genomföra) får teamet (alternativt projektet eller avdelningen) en chans att diskutera agiles och leans principer och värderingar. Inte nog med det, grupperna får också en chans att diskutera hurvida man tror att principerna och värderingarna är sanna – dvs. är de viktiga att följa och värna om för att projektet ska nå maximal framgång?

.

.

Du hittar övningen genom att klicka här, eller på ”Verktyg och mallar” i högerspalten.

.

h1

Ikon-mani på Scrum-väggen

torsdag, 23 februari, 2012

I projektet jag är Agile projektledare och Scrum Master i just nu har vi tapetserat 8 meter vägg med allehanda Backlogs, Burndowns, grafer, prognoser och information. Det har också skett en mindre explosion i antalet ikoner vi använder oss av för att tydligare visualisera vad som pågår och vilken status arbetet är i.

Väggen som helhet ser ut såhär:


(Klicka för att se en större bild. Sprint Backloggen är ytan i mitten som är tjock med Post-Its.)

.

Sprint Backloggen

Sprint Backloggen är enkelt strukturerad:

Task-lapparna beskriver saker som ”Implementera X”, ”Koda Y”, ”Fixa Z”, ”Skriva testfall”, ”Systemtesta”, ”Skriva systemdok”, ”Fixa browserkompatibilitet”, ”Acc Test”, m.m. m.m.

Jobbar man med en task så placerar man en av sina egna avatar ikoner på eller bredvid Task-lappen. I projektet blev temat av någon anledning superhjältar i olika skepnader. Vi har ”The Governator”, ”The Iron Lady”, ”Chuck Norrs”, ”Yoda”, m.fl. som var och en representerar en person i teamet. Varje person har max tre avatarer, dvs. man tillåts inte jobba med mer än tre saker samtidigt. Oftast används dock bara en eller två samtidigt, vilket är bra.

Varje task i ”In work” kolumnen uppdateras dagligen dessutom med ett estimat på återstående effektivt arbete i timmar. (Dessa summeras dagligen i Sprint Burndown charten.) För varje dag som en task sitter i ”In Work” kolumnen får den dessutom en prick på sig så att vi kan se hur många dagar den suttit där. De flesta tasks är så små att de ska vara möjliga att slutföra under en dag så om antalet prickar växer vet vi att något skumt pågår.

Denna uppbrytning har dock inte visat sig vara en tillräcklig visualisering av nuläget. Så, för att komplettera status och vad som händer använder vi oss av en stor skara laminerade ikoner som vi fäster med häftmassa på Feature-lapparna eller Task-lapparna.

Förhoppningsvis ger det någon inspiration så håll till godo, här kommer ikonerna 🙂

.

Status ikoner

Topic för morgondagens Daily Standup
Om det är något vi känner att vi vill diskutera tillsammans i teamet på nästa morgonmöte markeras Feature- eller Task-lappen med denna ikon. Varje morgon scannar vi Backloggen det sista vi gör efter dessa Daily-ikoner, diskuterar dem, och tar sedan bort ikonen.
Top Prio!
Denna ikon signalerar att denna Feature eller Task är något som vi verkligen behöver fokusera på tillsammans!
Tar konstigt lång tid
Om en task fortsätter sitta i ”In Work” kolumnen dag ut och dag in gör vi alla uppmärksamma på detta med denna ikon. Uppenbart så pågår något underligt. Antingen så är personen störd av andra åtaganden, eller så behöver han/hon hjälp. Oavsett vad, något lurt pågår.
Pausat
Av någon anledning kan vi för tillfället inte jobba vidare med denna task. Antingen väntar vi på svar eller information från någon utanför teamet, eller så kanske personen som jobbade på uppgiften gått och blivit sjuk.
Frustration!
Med denna ikon delar vi med oss av den frustration vi upplever. Häromdagen hade en om samma task tre stycken frustrationsikoner. Så jobbigt var det att få ordning på den.
Defekter spökar
Denna ikon har vi använt lite olika men nu verkar det som om vi börjat använda den för att signalera att systemtesterna inte nått i mål på grund av funna buggar.
Färdig 🙂
För att komma ihåg vad man gjorde dagen innan så placerar man denna ikon på tasken när man flyttar in den i ”Finished” kolumnen. Då blir det mycket enklare att summera gårdagen på nästa Daily Stand-Up.
.För att tydligare visualisera vilka funktioner som är redo för systemtest och vilka som är redo för acceptanstest har vi nyligen skapat ytterligare några ikoner. Det visade sig att det inte var uppenbart enbart genom att kolla av i vilken kolumn våra Task-lappar satt för att avgöra i vilken miljö featuren fanns i.
Awaiting ST Deploy
När utvecklaren känner sig färdig och redo med funktionen och har gjort grundläggande testning i sin egen utvecklingsmiljö är koden redo att läggas upp i Systemtest (ST) miljön. Detta markerar vi genom att placera denna ikon på den stora Feature-lappen.
System test Ready
När funktionens kod har hamnat i ST-miljön (efter ett sk ”lyft”) markeras Feature-lappen med denna ikon. Det betyder att Systemtest-fall är skrivna och att vem som helst (förutom personen som utvecklade funktionen) kan påbörja systemtestning.
Awaiting AT Deploy
När systemtest är genomförd och teamet känner att funktionen är av tillräckligt hög kvalitet för att lyftas till acceptanstest (AT) miljön placeras denna ikon på Feature-lappen.
Acceptance test Ready
Denna ikon signalerar att funktionen finns i acceptanstest miljön. Dvs. när uppgradering sker av AT-miljön byts ”Awaiting AT Deploy” ut mot denna ikon. Det kan finnas kända problem, men den håller tillräckligt hög kvalitet för att teamet ska vara redo att ta emot feedback från acceptanstestning.
h1

Det är dyrt att vara riktigt agil. Eller?

onsdag, 2 november, 2011

Att vara agil när man jobbar i Scrum betyder (bland annat) att man efter varje iteration har lyckats bygga en ny fungerande och värdefull version av produkten (eller systemet) som går att leverera till kund eller butik om man så önskar. Men att vara riktigt agil kostar. Eller?

För att varje sprint ska resultera i en nytt levererbart inkrement ställs det stora krav. Först måste vi ha lyckats bryta ner våra features så att de är tillräckligt små så att flera får plats i sprinten. Och med ”få plats” menar jag att man hinner med allt för att gå från idé till leverans, dvs. varje enskild feature ska designas, kodas, testas, dokumenteras och sammanfogas med helheten (allt enligt vår Definition of DONE for User Stories). Vi behöver dessutom känna oss trygga i att resten av systemet fortfarande fungerar och att vi inte har introducerat nya buggar.

Om vi förutsätter att vi har kontroll över våra IT-system och inte har några externa beroenden vad gäller testmiljöer och servar (vi är inte beroende av externa köer för att få något jobb gjort) så är det ändå inte helt trivialt att få till en leverans varje sprint.

Låt oss titta på ett exempel på hur en treveckorssprint skulle kunna se ut.

.

Först och främst har vi våra Scrum möten. Syftet med dessa är att planera (läs analysera) vad vi ska göra härnäst (Sprint Planning), hur vi på bästa sätt koordinerar oss inom teamet (Daily Scrum), fånga upp feedback så att vi kan förbättra processen (Sprint Retrospective) samt lära oss vad som kan göra produkten ännu bättre (Sprint Demo). Sista fredagen är dessutom en sprint-fri dag där teamet kan hämta andan och samla ny energi till nästa sprint.

.

För att vi med trygghet ska vilja lämna ifrån oss den nya versionen (som innehåller våra nya features) vill vi dessutom känna oss trygga i kvalitén. Detta gör vi med att arbeta med att fixa buggar och verifiera buggfixar (Hardening). Vi vill också testa igenom systemet i sin helhet för att försäkra oss om att vår nya kod inte saboterat någon annan funktionalitet eller försämrat någon egenskap (såsom t.ex. prestanda). Denna testning inleds typiskt med en uppgradering av acceptancetestmiljön. Hela teamet hjälps åt att testa. Vad man fokuserar på klurar man ut som team genom att göra en riskanalys. Det kan t.ex. innebära en balans mellan körning av delar av regressionstestsviten plus identifierade Exploratory Testing sessioner. Var man lägger sin testfokus beror på var man ser att riskerna finns, vilka moduler som utsatts för förändring etc. När så slutgiltig paketering är gjord och en sista hand har lagts på dokumentationen är teamet redo att leverera den nya versionen till kund eller förvaltning. Tada!

.

Det som återstår är vårt utrymme för utveckling. Det är alltså denna tid som finns tillgänglig för design, kodning, testning och dokumentation av nya features. Det vi påbörjar ska hinna slutföras innan ”Code-freeez-mode” slår till.

.

Sådärja. Då har vi lyckats visualisera de olika typerna av arbete som pågår under en sprint. Låt oss visualisera hur de olika formerna av arbeta står i proportion till varandra…

.

Nu ska man ställa sig två frågor:

Vilket arbete tillför värde?
Vilket arbete är waste?

.

Eftersom exemplet inte förtäljer hela historien så kan vi bara spekulera. ”Development” och ”Scrum Meetings” tillför såklart värde, det är här vi skapar, analyserar, planerar, designar och koordinerar oss. Sedan bör vi ställa oss frågan – kan Scrum mötena (såsom sprint planeringen) göras effektivare och kortare?

”Hardening” borde inte behövas om vi byggde kvalitet från början. Detta är tydlig waste. Packaging, miljöuppgraderingar etc. döljer också troligtvis en hel del waste – detta borde gå att automatisera.

Den gemensamma testinsatsen som sker i slutet av sprinten… är den waste? Jag skulle argumentera för att den inte är det – här bygger vi kunskap om hur systemet som helhet mår efter att vi infört våra förändringar och bygger beslutsunderlag till frågan – ska denna release gå till kund?

.

.

Det som blir uppenbart av att titta på bilden är dock att själva utvecklingen av nya features som mest utgör hälften av arbetet. Mycket tid går åt till ”annat”. Man skulle kunna påstå att Velocityn blir ”lidande” (antal features eller Story Points per sprint) eftersom vi anstränger oss för att vara helt agila. Från ett leveransperspektiv är det så att varje sprint levererar ett färdigt och komplett increment, dvs. Definition of DONE för User Stories är komplett och lämnar inget till senare. Vi VET att vi hela tiden är redo för leverans till kund. I exemplet ovan ”vet” vi att vi har levererat 24 features när deadline närmar sig.

.

Att vara helt agil i Scrum kostar så det är enkelt att lockas till att flytta ut vissa kriterier från Definition of DONE for User Stories till Definition of DONE for Release. Dvs. vi skjuter viss testning, viss dokumentation, etc. till en ”release sprint”. Detta ökar vår Velocity (antalet features per sprint), men vi är å andra sidan inte leveransredo varje sprint eftersom vi har skjutit arbete och risk framför oss. Faktum är att release sprinten troligtvis inte alls blir en strikt timeboxad sprint eftersom vi inte vet hur mycket arbete och risk vi skjutit framför oss förrän vi sitter ner och planerar (och exekverar) den sprinten. Med detta upplägg kanske vi levererat 30 features när deadline kommer, men det troliga är att vi kämpar med testning, buggfixningar och refactoring av tekniska svagheter långt förbi deadline. Vad ännu värre är att vi har skapat en rejäl fördröjning i feedbacken mellan test och kodning då vissa tester inte körs förrän så mycket som fem sprintar senare.

.

Att inte vara DONE utan att först uppnå DONE i release sprinten öppnar upp för följande:

Vi riskerar missa deadline
Vi introducerar waste genom långa feedbackcyckler (både vad gäller test och kvalitet men även kundens feedback om funktions värde)
Vi skjuter på tekniska risk och missar chansen att hantera problem tidigt
Vi tappar den sanna insynen i hur vi faktiskt ligger till (vi vet inte vad som är klart och vad som är ”work in progress” eftersom vi inte testat klart)
Vi förlorar styrförmåga. Innan vi helt kan styra om fokus måste vi genomföra release ”sprinten”.

.

Så är det dyrt att vara agil, eller är det kostsamt att inte vara det?

.

h1

Video: Kanban applied to Scrum

måndag, 31 oktober, 2011

Jag tycker om att tipsa om korta filmer som på ett snyggt och enkelt sätt presenterar olika aspekter av agil utveckling.

Denna YouTube video på sju minuter från bti360 presenterar hur principerna bakom Kanban på ett enkelt sätt kan användas för att förbättra din Scrumprocess.

.

 

 

h1

Snygg (och fyndig) introduktionsvideo till Scrum

måndag, 20 juni, 2011

Ramlade idag över denna video som introducerar och förklara de flesta av de grundläggande elementen av Scrum på ett snyggt och roligt sätt.

Det finns många introduktionsvideos om Scrum på nätet men jag tycker denna från CollabNet sticker ut lite extra i sina förklaringar och i sin presentation av Scrums mekanismer och grundpelare.

.

.

Se ”Scrum Training Series | Introduction to Scrum” här:
https://training.csfe.collab.net/sf-images/training/scrum/intro/Intro_to_scrum.htm

h1

The Hyperproductive Scrum Dream Team

tisdag, 21 december, 2010

Den 2:a december höll jag ett seminarie på Lantmäteriet i Gävle med titeln ”The Hyperproductive Scrum Dream Team”. Seminariet spelades in och nu finns den tillgänglig på YouTube.

Seminariet handlar om Scrum teamet och hur man skapar förutsättningar för hyperproduktivitet. Vilka är nyckel- faktorerna? Vilka är utmaningarna? Om Death by Technical Debt. Hur möjliggör man och skapar en miljö där teamet kan växa inifrån.

.

.

Filmen är uppdelad i fyra delar. Klicka på länkarna nedan för att se dem alla:

PS. Ha gärna överinseende med mina många stammningar och ”öh…”. Jag vill minnas att jag blev ganska nervös när jag 10 minuter innan seminariet ska börja blev upplyst om att det skulle filmas. DS.

h1

Det beroendeframkallande spelet ”Scrum”

fredag, 12 november, 2010

Det finns belöningsmekanismer inom Scrum, stora som små, kortsiktiga och långsiktiga, som går att mappa mot ett online-spels dynamiska beroendeframkallande natur. Varför inte utförska dessa och förstärka dessa element inom Scrum?

Jag fick en ”Aha!” upplevelse tidigare idag när jag läste ett blogginlägg (Scrum & Gaming Addiction) av Peter Behrens som jämförde Scrum med online-spelens beroendeframkallande belöningssystem (som i t.ex. World of Warcraft och Farmville).

Peter refererar till ett TED Talk av Tom Chatfield – 7 ways games reward the brain. Inspirerad av Toms presentation reflekterar Peter över hur online-spelens belöningsmekanismerna återkommer i Scrum:

  1. Staplar som synliggör och mäter framsteg
  2. Multipla långsiktiga och kortsiktiga mål
  3. Belöna ansträningen
  4. Snabb, tät och tydlig feedback
  5. Ett element av osäkerhet/äventyr
  6. Möjligheter för vidare åtaganden
  7. Feedback och samarbete med andra människor

Om flera av ovanstående mekanismer saknas i ett online-spel tvivlar jag starkt på att det någonsin kan bli populärt eller kommer sälja speciellt bra. Man kommer helt enkelt tappa intresset.

Jag håller fullständigt med Peter om att man borde försöka förstärka de belönande mekanismerna även i Scrum. Vem skulle inte vilja ha ett jobb som man längtade tillbaka till, som erbjöd små och stora belöningen med jämna mellanrum, och blev belönad för att man anstränger sig och gör sitt bästa.

.

Förslag på belöningsmekanismer i ett Scrum-projekt:

Förslag: Visualisera så mycket som möjligt. Det finns en konstig tillfredställelse i att flytta post-its och kryssa av check-boxar.

Förslag: Lägg ner omsorg på fina och färgglada Burndown-charts. Gör varje dags framsteg synliga.

Förslag: Fira varje Sprint Demo med en tårta. Oavsett om teamet nådde i mål med sina Sprint mål så har teamet troligtvis ansträngt sig och gjort sitt bästa för att lyckas.

Förslag: Ring i klockan eller blås i vuvuzelan när en story uppfyller DONE.

Förslag (Peters): Istället för Story Points använd ”Cost Reduction Points” (om projektet går ut på att effektivisera IT driften), eller ”Social Status Points” om man bygger en Social Community. Eller varför inte ”DragonSlayer Erf” av den enkla anledningen att det är roligare.

Förslag: Låt teamet ha en ”Tech Day” under Sprinten, dvs. en dag då man tillåts göra vad man vill, t.ex. lära sig ett nytt verktyg, experimentera med en alternativ lösning, studera, etc.

.

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?

.

h1

Daily Scrum Checklistor

fredag, 10 september, 2010

Daily Scrum är säkert vardag för många, liksom mig själv, men efter ett tag riskerar rutinen att ta över. Därför blev jag glad när jag snubblade över några nyttiga checklistor för scrum mastern att ha i bakhuvudet inför, och efter Daily Scrum (aka Daily Stand-Up).

Mike Griffiths publicerade nyligen två artiklar på bloggen LeadingAnswers: Leadership and Agile Project Management Blog:

.

Detta är Mikes Top 5 viktigaste saker att tänka på innan och efter Daily Scrum, och jag håller varmt med om att det är bra punkter. Har dock inte funderat djupare och kritiskt granskat hans prioritering eller klurat över hur min egen lista sett ut om jag hade gjort den från scratch.

Det absolut viktigaste syftet med Daily Scrum är dock att ge teamet en chans att tillsammans reflektera över hur det går och hur teamet tillsammans på bästa sätt framgångsfullt och effektivs ska arbeta för att lösa dagens bekymmer och utmaningar och för att nå uppsatta sprint mål.

.

5 saker att tänka på innan Daily Stand-Up

  1. Vad arbetas det på just nu? – Vilka funktioner och User Stories arbetar teamet på just nu? Vad höll man på med igår? Är man klar med dessa eller kommer arbetet fortsätta under dagen?
  2. Gårdagens problem – Vad rapporterade folk för problem och bekymmer igår? Har dom blivit åtgärdade? Några uppföljningar som borde ske?
  3. Uppmärksamma teamet! – Är det någon som snart fyller år? Precis har gift sig? Visa uppmärksamhet och bry dig även om vad som pågår i teammedlemmarnas privata liv.
  4. Dolda surdegar? – Är det någon som kämpar på med en task utan att komma någon stans? Någon som försöker komma igång med något nytt utan att få fotfäste? Någon som switchar mellan tasks för att man kontinuerligt kör fast? Detta kräver speciell uppmärksamhet.
  5. Vad tänker du säga? – Precis som teammedlemmarna berättar om vad dom gjorde igår, vad dom tänker göra idag och  om dom har några bekymmer så bör även Scrum Mastern dela med sig av sina göråmål.

.

5 saker att tänka på efter Daily Stand-Up

  1. Problem – Problem och bekymmer som togs upp ska upp på Impediment listan (dvs. Scrum Masterns Att-Göra) och sedan adresseras i prio ordning. Följ upp dagen efter vad som gjorts (eller inte gjorts).
  2. Avvikelser i Velocity – fdskf jsdjkgfdklfjsfdjghjsfdkjg
  3. Känslor – Hur verkar teamet må? Var någon upprörd? Finns det frustration och irritation eller spänningar inom teamet? Ett litet samtal kring känslor kan iband göra underverk.
  4. Frågor – Uppstod frågor under mötet som behöver svar? Behöver du som Scrum Master sätta dig in i något tekniskt för att bättre förstå hur du ska hjälpa teamet?
  5. Beröm och feedback – Alla behöver återkoppling och uppskattar beröm och är i behov av  positiv kritik för att göra ett bra jobb. Uppmärksamma alltid om någon gör ett bra jobb, eller bidrar på ett värdefullt sätt till teamet, och tveka inte att rapportera tillbaka till teamet om någon annan ger beröm eller positiv feedback!

.