Kommentarer till 12 fallgropar i Scrum http://true-consulting.se/fallgropar-i-scrum/ Social Media Consulting Wed, 04 Aug 2010 07:53:13 +0000 hourly 1 http://wordpress.org/?v=3.0.1 Av: Min topp fem på saker som gör ett Scrumprojekt extremt otydligt « Finn Lydänge http://true-consulting.se/fallgropar-i-scrum/#comment-138 Min topp fem på saker som gör ett Scrumprojekt extremt otydligt « Finn Lydänge Mon, 10 May 2010 20:32:21 +0000 http://true-consulting.se/?p=279#comment-138 [...] Andra saker som kan få ditt Scrumprojekt att komma snett och hamna i dåligt sällskap kan du läsa om på True Consultings blogg. [...] [...] Andra saker som kan få ditt Scrumprojekt att komma snett och hamna i dåligt sällskap kan du läsa om på True Consultings blogg. [...]

]]> Av: Therese Reuterswärd http://true-consulting.se/fallgropar-i-scrum/#comment-127 Therese Reuterswärd Sun, 28 Feb 2010 17:42:11 +0000 http://true-consulting.se/?p=279#comment-127 Huvudet på spiken: Projektägare borde finnas hos både kund och leverantör; som beställare på ena sidan och som "proxy för den verkliga kunden" hos leverantören. Scrum Mastern bör ansvara för teknisk höjd, vägval, problemlösning och coachning av utvecklarna. Fördelen med både en Scrum Master och en PL är att projektledaren då hinner leda fler projekt parallellt. Sen har jag som "proxy" inget emot att styra upp scrum board, planning meetings, demos, köpa extra minne till teamets datorer eller testa färdig funktionalitet :) Huvudet på spiken: Projektägare borde finnas hos både kund och leverantör; som beställare på ena sidan och som ”proxy för den verkliga kunden” hos leverantören. Scrum Mastern bör ansvara för teknisk höjd, vägval, problemlösning och coachning av utvecklarna. Fördelen med både en Scrum Master och en PL är att projektledaren då hinner leda fler projekt parallellt. Sen har jag som ”proxy” inget emot att styra upp scrum board, planning meetings, demos, köpa extra minne till teamets datorer eller testa färdig funktionalitet :)

]]> Av: Joel Abrahamsson http://true-consulting.se/fallgropar-i-scrum/#comment-126 Joel Abrahamsson Sun, 28 Feb 2010 17:16:54 +0000 http://true-consulting.se/?p=279#comment-126 I en perfekt värld skulle jag säga att det är produktägarens roll att övervaka budgeten medan konceptförståelsen kommer naturligt för hela teamet genom att det inte finns någon person som är ansvarig för kundkontakten, dvs hela teamet har kontakt med kunden och sätter sig in i hur kundens verksamhet fungerar. Sen kan ju verkligheten naturligtvis sätta sina begränsningar. Av de scrumprojekt jag deltagit i hittills tycker jag mig dock kunna uttyda att det fungerar mycket bättre när det inte finns någon person som har en enbart administrativ och relationsbyggande roll (läs: projektledare) i teamet utan då alla teamets medlemmar adderar kundnytta, om än i olika utsträckning. Emil skrev ett intressant inlägg om detta för ett tag sedan, http://unwillingcoder.com/Entry.aspx/get-rid-of-the-project-manager-get-more-value Sägas bör dock att jag inte tror att den traditionella projektledaren inte längre behövs, men jag tror att den personen är betydligt bättre lämpad som produktägare hos kunden eller (i värsta fall) som proxy för den verkliga kunden hos leverantören. Gällande att hålla kodbasen lättrörlig så förstår jag att inlägget inte på något sätt uteslöt det. Jag tycker dock att det är en fråga som diskuteras på tok för lite, framför allt i proportion till hur mycket projektmetodik diskuteras. Detsamma gäller ofta för hur man ser på frågorna i många organisationer. Jag tycker ofta att man ser att företag skickar sina projektledare på utbildning för att bli scrum masters och sina utvecklare på utbildning för att lära sig en specifik teknik, typ EPiServer CMS, och sedan ska man tuta och köra med agil mjukvaruutveckling. I själva verket tycker jag att man borde skicka sina projektledare på utbildning i produktägarskap, uppmuntra sina utvecklare att läsa på om några av de ämnen jag nämde i min tidigare kommentar och ständigt söka nya vägar att bygga mera flexibel mjukvara. Och skicka alla på den där scrum kursen :) Ursäkta långrandigheten, som du märker är detta ett ämne som intresserar mig :-) I en perfekt värld skulle jag säga att det är produktägarens roll att övervaka budgeten medan konceptförståelsen kommer naturligt för hela teamet genom att det inte finns någon person som är ansvarig för kundkontakten, dvs hela teamet har kontakt med kunden och sätter sig in i hur kundens verksamhet fungerar.
Sen kan ju verkligheten naturligtvis sätta sina begränsningar. Av de scrumprojekt jag deltagit i hittills tycker jag mig dock kunna uttyda att det fungerar mycket bättre när det inte finns någon person som har en enbart administrativ och relationsbyggande roll (läs: projektledare) i teamet utan då alla teamets medlemmar adderar kundnytta, om än i olika utsträckning.
Emil skrev ett intressant inlägg om detta för ett tag sedan, http://unwillingcoder.com/Entry.aspx/get-rid-of-the-project-manager-get-more-value

Sägas bör dock att jag inte tror att den traditionella projektledaren inte längre behövs, men jag tror att den personen är betydligt bättre lämpad som produktägare hos kunden eller (i värsta fall) som proxy för den verkliga kunden hos leverantören.

Gällande att hålla kodbasen lättrörlig så förstår jag att inlägget inte på något sätt uteslöt det. Jag tycker dock att det är en fråga som diskuteras på tok för lite, framför allt i proportion till hur mycket projektmetodik diskuteras. Detsamma gäller ofta för hur man ser på frågorna i många organisationer. Jag tycker ofta att man ser att företag skickar sina projektledare på utbildning för att bli scrum masters och sina utvecklare på utbildning för att lära sig en specifik teknik, typ EPiServer CMS, och sedan ska man tuta och köra med agil mjukvaruutveckling. I själva verket tycker jag att man borde skicka sina projektledare på utbildning i produktägarskap, uppmuntra sina utvecklare att läsa på om några av de ämnen jag nämde i min tidigare kommentar och ständigt söka nya vägar att bygga mera flexibel mjukvara. Och skicka alla på den där scrum kursen :)

Ursäkta långrandigheten, som du märker är detta ett ämne som intresserar mig :-)

]]> Av: Therese Reuterswärd http://true-consulting.se/fallgropar-i-scrum/#comment-125 Therese Reuterswärd Sun, 28 Feb 2010 16:46:06 +0000 http://true-consulting.se/?p=279#comment-125 Att kodbasen är lättrörlig är ju en oerhört viktig förutsättning! Du har helt rätt, och som projektledare utgår man ifrån att teamet tar eget ansvar för att rätt metodik för systemdesign och utveckling tillämpas. Jag tycker också själv att Scrum Master ska vara en utvecklare (även om det inte rekommenderas att det är tech-gurun). Men Scrum Mastern måste isåfall också ha kundkontakt, konceptförståelse och övervaka timmar och budget. Scrum hanterar ju som bekant inte kostnad och projektekonomi heller.. Att kodbasen är lättrörlig är ju en oerhört viktig förutsättning! Du har helt rätt, och som projektledare utgår man ifrån att teamet tar eget ansvar för att rätt metodik för systemdesign och utveckling tillämpas. Jag tycker också själv att Scrum Master ska vara en utvecklare (även om det inte rekommenderas att det är tech-gurun). Men Scrum Mastern måste isåfall också ha kundkontakt, konceptförståelse och övervaka timmar och budget. Scrum hanterar ju som bekant inte kostnad och projektekonomi heller..

]]> Av: Joel Abrahamsson http://true-consulting.se/fallgropar-i-scrum/#comment-124 Joel Abrahamsson Sun, 28 Feb 2010 12:56:19 +0000 http://true-consulting.se/?p=279#comment-124 Mycket intressant och välskrivet Therese! Jag saknar dock den, enligt min erfarenhet, vanligaste och djupaste fallgropen: att inte inse att projektmetodiken bara är en av flera delar i att jobba lättrörligt med mjukvaruutveckling. Minst lika viktigt är i min mening att systemdesign och utveckling sker på ett agilt sätt, vilket inte scrum på något sätt garanterar. Framför allt då scrummastern är en icke-tekniker (i min mening fel) tas ofta egentligen självklara begrepp som SOLID-principerna, TDD och continous integration (för att nämna några) inte upp alls. Finns inte de bitarna på plats är projektet dömt att misslyckas efter några månader, oavsett hur väl man har infört scrum, eftersom kodbasen inte är lättföränderlig. Man har slagit i scrum-väggen, http://allankelly.blogspot.com/2009/07/scrum-wall-another-agile-failure-mode.html. Som vanligt har Ayende formulerat det jag försöker säga mycket bättre än vad jag kan på sin blogg: http://ayende.com/Blog/archive/2010/02/20/nice-process-but-what-about-the-engineering-bits.aspx Mycket intressant och välskrivet Therese!

Jag saknar dock den, enligt min erfarenhet, vanligaste och djupaste fallgropen: att inte inse att projektmetodiken bara är en av flera delar i att jobba lättrörligt med mjukvaruutveckling.
Minst lika viktigt är i min mening att systemdesign och utveckling sker på ett agilt sätt, vilket inte scrum på något sätt garanterar.
Framför allt då scrummastern är en icke-tekniker (i min mening fel) tas ofta egentligen självklara begrepp som SOLID-principerna, TDD och continous integration (för att nämna några) inte upp alls. Finns inte de bitarna på plats är projektet dömt att misslyckas efter några månader, oavsett hur väl man har infört scrum, eftersom kodbasen inte är lättföränderlig. Man har slagit i scrum-väggen, http://allankelly.blogspot.com/2009/07/scrum-wall-another-agile-failure-mode.html.

Som vanligt har Ayende formulerat det jag försöker säga mycket bättre än vad jag kan på sin blogg: http://ayende.com/Blog/archive/2010/02/20/nice-process-but-what-about-the-engineering-bits.aspx

]]>