Scrumtips - Tips om Scrum!

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

Efter att ha läst om arbetsgrupper där medlemmarna jobbar lite för separerat från varandra för dra nytta av ett teams sanna potential  frågar en anonym läsare: "Det vore intressant att läsa lite tips på hur man når dit. Om man nu är en grupp där man är lite för specialiserade. Vad gör man för att sprida kunskaperna på ett bra sätt?" Här är några handfasta tekniker som gör att kunskap i ett mjukvaruutvecklingsteam sprids. Men först lite kort om själva förändringen i sig. Grunden i all förändring är att behovet av förändring är känt. Så, om inte alla i teamet känner till att och varför det är en bra idé att jobba tajtare tillsammans måste ni prata om det. Hur skulle ni veta om ni jobbade bättre tillsammans? Vilka faktiska aktiviteter skulle ni göra? Hur skulle det kännas? På vilket sätt skulle resultatet bli bättre? Vilka nackdeler skulle ni se? Hur skulle ni hantera dem? Så, några konkreta saker ni kan göra. Planera aldrig ensam.  Klyschan är sann: planen är inget, plan

Som en kommentar till det jag skrev om motstånd mot dagliga morgonmöten i "Pragmatisk eller dogmatisk? Progmatisk!", skriver Magnus Ljadas: "En anledning till motstånd till morgonmöten, enligt min erfarenhet, kan vara att arbetet i projektet bedrivs väldigt specialiserat. Jag gör bara sånt som har med utskrifter att göra; du sysslar bara med webbformulär; och ingen av oss rör någonsin nånting som har med databasen att göra, för det är Staffans baby. Vi har liksom väldigt få naturliga beröringspunkter. Stor fråga kanske, men hur tar man sig ur/bryter en sån situation?" Verkligen en stor fråga, men vi prövar ett sätt att närma sig den. En bra teknik är att utgå från att människor vars beteende man inte håller med om eller förstår sig på faktiskt beter sig så rationellt som möjligt, men självklart med utgångspunkt från deras egna aktuella modeller av hur verkligheten fungerar. Tänker man så kan man i det här fallet fråga sig vilken modell av verkligheten man behöver h

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 vi

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 fra