Fortsätt till huvudinnehåll

Tyst brainstorming

Brainstorming är ett fascinerande koncept. Tanken är att en grupp tillsammans arbetar för att producera så många idéer som möjligt på ett tema. För att inte störa den kreativa processen finns en viktig förhållningsregel. Ingen kritik av idéer. Kritiken kommer senare. Min erfarenhet är att det är svårt att låta bli att kritisera under brainstormingen.

Möjligtvis, och jag skriver möjligtvis, kan det för personer med en extrovert läggning vara lättare att hantera kritik under brainstormingen. Är man bekväm med att tänka och prata samtidigt så är man förmodligen mer immun mot att folk avbryter och kritiserar under brainstormingen.

För personer med en mer introvert preferens kan utmaningen vara större. För det första kan brainstormingen i sig själv vara knepig för den som helst tänker för sig själv först, och sedan delar med sig av sina tankar. För det andra blir det inte bättre när någon avbryter den introverte, som äntligen uppmanat kraften att bidra med några idéer inför hela gruppen.


För att få en bättre balans mellan att tillfredsställa behoven hos personer med extrovert och introvert preferens brukar jag använda mig av tyst brainstorming.

I en tyst brainstorming får deltagarna under en känd tid tyst och på egen hand brainstorma idéer. Varje deltagare skriver själv ned sina idéer i en lista, eller direkt på post-its. När tiden är slut presenterar deltagarna sina idéer för varandra - använder man post-its klistrar man upp dem på till exempel en gemensam blädderblockslapp eller whiteboard. Behövs det kan man köra fler rundor på samma sätt.

Tyst brainstorming hjälper personer med introvert preferens att fokusera och förbereda sig under det tysta momentet, medan personer med extrovert preferens fortfarande har tillgång till den gemensamma presentationen och dialogen.

Kommentarer

Detta är ett jättebra tips, som även hjälper för att inte för tidigt styra in hela diskussionen/brainstormingen kring vad någon (troligen mer extrovert) deltagare vill att den ska handla om.

Jag har även med bra resultat använt den i ett format liknande det Bas Vodde beskriver i Plan of Action, där man först kör individuellt, därefter i par, vidare till flera par tillsammans och slutligen hela gruppen gemensamt.
Tobias Fors sa…
Hej Chris! Tack för feedbacken och för att du hittat fram till denna min helt färska blogg!

Populära inlägg i den här bloggen

Vad sprintplanering och glassinköp har gemensamt

En missuppfattning som lever kvar kring lättrörliga metoder är att de inte har tillräckligt med planering. Det är precis tvärtom, vi gör massor av planering. Dels gör vi så mycket planering som behövs när vi ska starta ett nytt projekt, dels gör vi granskning och revidering av planerna med en regelbunden rytm. Eftersom vi planerar så mycket behöver vi vara mycket effektiva planerare.

Varje sprint i Scrum börjar med en planeringsworkshop där produktägaren och teamet tillsammans väljer ut rätt mängd viktigt arbete för sprinten. Planeringsarbete kan lätt dra ut på tiden, särskilt när vi eftersträvar precision. Just därför är sprintplaneringen i Scrum begränsad till max en arbetsdag: sprintens första dag. Vissa team märker efter några sprintar att man inte ens behöver hela dagen för att göra en bra plan.

En effektiv sprintplanering kräver att samtliga inblandade kommer väl förberedda. Då kan planeringen genomföras inom tidsramen, och sluta med ett genuint åtagande från samtliga inblandade a…

Sprintbacklog på väggen, produktbacklog elektroniskt

En artikel på InfoQ om för- och nackdelar med att sätta upp sina planer och sin information på väggen fick mig precis att komma ihåg att jag har några tips att dela med mig av.

Sprintbackloggen är, som du redan vet, utvecklingsteamets eget verktyg för att hantera sitt åtagande i sprinten. Med hjälp av sprintbackloggen kan teamet granska och anpassa sitt arbeta på daglig basis. Detta är viktigt, eftersom utvecklingsteamet är själva motorn i Scrum. För att sprintbackloggen ska vara relevant och användbar måste den vara aktuell. Det kommer den att vara givet att två förutsättningar är uppfyllda.

Den första förutsättningen är att teamet verkligen tagit på sig ansvaret att planera och följa upp sitt eget arbete, eftersom man ser nyttan med att göra det och därför vill göra det.

Den andra förutsättningen är att det är extremt enkelt att hålla sprintbackloggen uppdaterad. Vanliga orsaker till att det inte är enkelt är att man lagrar sprintbackloggen i ett verktyg som alla inte behärskar till fu…

Både Scrum Master och teammedlem?

En vanlig fråga som jag brukar få har att göra med vad som händer när en person bemannar två roller i Scrum. Frågan lyder: kan man vara både Scrum Master och medlem i utvecklingsteamet?

Först lite bakgrund till svaret. Mitt standardsvar på alla frågor som börjar med orden "kan man" eller "får man" är ett rungande ja. Självklart kan man göra som man vill, och självklart får man själv (eller snarare tillsammans med sina kollegor) bestämma hur man ska göra. Man behöver inte tillstånd från en expert eller en arbetsmetod. Det kan tyckas som en detalj, men språket styr tanken. Därför tycker jag det är mer hjälpsamt att börja frågan på ett annat sätt. Så här: Vad kan konsekvenserna av att vara både Scrum Master och teammedlem bli?

För mig är det lättast att hitta till ett begripligt svar om jag börjar med att fråga mig själv vad syftet är med att dela på Scrum Master och teammedlemsrollen.
En anledning till uppdelningen är att redan i förväg bygga en beredskap för framtida…