Fortsätt till huvudinnehåll

Dialog, inte diskussion

Dagens scrumtips är ett boktips: Dialogen och konsten att tänka tillsammans, av William Isaacs, översatt till svenska år 2000 av Bookhouse Publishing AB.

Scrum handlar om lärande, alltså om att bygga ny kunskap och ny kapacitet. Vi har tvärfunktionella team för att belysa de komplexa problem vi arbetar med ur så många perspektiv som möjligt. Varje person som bidrar med ett nytt perspektiv tillför fler kontrollerbara variabler, alltså saker vi kan justera för att hitta en lösning på problemet.

Styrkan med ett tvärfunktionellt team är dess förmåga att hitta lösningar som ett team av specialister från samma disciplin helt enkelt inte kan nå, eftersom de inte kan manipulera alla de variabler som behöver manipuleras för att lösning ska kunna uppstå.

Ett team som inser detta samtalar med varandra för att förstå varandras perspektiv. Man accepterar att alla bidrar med sin del av lösningen och att det enda sättet att lösa hela problemet är att lära sig se det i sin helhet.

Denna typ av utforskande samtal kallas dialog. Motsatsen till dialogen är diskussionen eller debatten. Få saker är så energikrävande som en diskussion mellan personer som alla är övertygade om att de sitter på den enda sanningen. Få saker är så energigivande som en dialog där alla deltagares perspektiv uppskattas och utnyttjas.

Hur ser era arbetsmöten ut? Diskuterar ni, eller för ni en dialog? Hur funkar det för er?

Kommentarer

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

Pragmatisk eller dogmatisk? Progmatisk!

Scrum är ett enkelt ramverk. Några få regler bildar tillsammans ett system av aktiviteter som kan användas för att styra komplext arbete. Att ta bort en väsentlig del ur ett fungerande system påverkar alltid systemet som helhet. Tar man till exempel bort återblickarna ur Scrum minskar sannolikheten för framgång omedelbart. Man får lika stora problem, om inte större, om man försöker applicera Scrum dogmatiskt. Den som aldrig kan tänka sig att kompromissa kommer inte att ha någon framgång när det gäller att driva förändring. Har du själv jobbat med någon som aldrig kan kompromissa förstår du varför. Så hur ska man göra? Följa Scrum dogmatiskt för att inte förstöra arbetsmetodens effektivitet, eller vara pragmatisk för att inte alienera sig från andra människor? Jag föreslår en kompromiss. Låt oss kalla den en progmatisk hållning . Den progmatiska hållningen fungerar så här. Vi är å ena sidan aldrig rädda för att tänka själva och göra förändringar i Scrum, men å andra sidan gör...

Hur lång ska en sprint vara?

Jag fick en fråga på mailen som löd: "Fick frågan av min chef varför vi har 3 veckors sprintlängd. Vet inte riktigt vad jag ska svara, det bara blev så. Vad säger du?" En sprint i scrum är en synonym för iteration. Det som utmärker scrums sprintar är att vi vill att de ska vara väldigt fokuserade och att de ska sluta i klar, potentiellt levererbar, produkt. Potentiellt levererbar betyder att om vi ville  så kunde vi skeppa ut produkten med ganska lite efterarbete. Tydlig och regelbunden feedback krävs för att styra utvecklingsarbete. Längre sprintar betyder att det blir längre tid mellan större avstämningar av nuläget, vilket ökar risken att vi drar iväg i fel riktning, eller att omvärlden ändrar sig så mycket under sprinten att det vi bygger hinner bli irrelevant. Ibland kan det kännas som om man lägger för mycket tid på planerings- och uppföljningsworkshops, vilket leder till idén att göra sprintarna längre. Jag vill hellre börja med att undersöka om arbetsmötena k...

Proxy-produktägare förtar effekten

Ibland möter jag team och organisationer som har, eller tror sig kommer att få, stora svårigheter med att engagera de personer som de helst skulle vilja ha som produktägare. Deras försök till lösning kan ibland vara att ducka för problemet, och tillsätta en mindre lämplig person som produktägare. Det kanske vanligaste exemplet är nog det här. En utvecklingsavdelning på ett företag är övertygad om att man aldrig kommer att lyckas övertyga sina produktchefer att ta på sig rollen som produktägare, så man utnämner istället representanter från tekniksidan som mellanproduktägare, eller som man ibland hör, produktägar-proxies. Tanken med en produktägarproxy är att kunna fortsätta kalla den formellt ansvarige för utvecklingsarbetet för produktägare, men samtidigt acceptera att denne inte kommer kunna leva upp till sin roll. Till en början kan detta verka som en lämplig strategi. Utvecklingsteamet får ju i proxyproduktägaren någon man kan gå till för såväl dagliga frågor som för planering...