[SCRUM]Welke tool? Er zijn er zo veel!

[van.der.schulting]

Ik ben op zoek naar een Scrum tool voor een Ruby on Rails project.

Nu kwam ik de volgende drie tegen die me wel wat leken:
- Pivotal Tracker. (https://www.pivotaltracker.com/) Ziet er goed en compleet uit. Maar lijkt me om te beginnen ietwat complex, maar dat went wel snel denk ik. Helaas is het niet helemaal volgens Scrum.
- AgileBuddy. (http://agilebuddy.com/). Ben ik eigenlijk het minst gecharmeerd van. Een beetje hetzelfde als Pivotal, maar eigenlijk iets te simpel.
- ScrumNinja (http://www.scrumninja.com). Dit lijkt me echt wel iets goeds, implementeert scrum beter dan Pivotal Tracker en ziet er simpeler uit en is ook daadwerkelijk simpeler dan Pivotal Tracker.

Maar naast deze drie is er nog een legio aan Scrum tools. Als ik ze allemaal ga uitproberen zie ik door de bomen het bos niet meer,
Heeft iemand ervaring met een bepaalde Scrum tool waarvan je zegt, die moet je ook zeker overwegen?

De 'eisen' die ik in feite heb is dat de tool niet lokaal geinstalleerd hoeft te worden, dus dat ik hem webbased kan gebruiken. Daarnaast zou een Trial periode wel fijn zijn.

edit:
Tsja nu je het zegt... geen idee hoe je een Scrum tool richt op een programmeertaal

[Voor 6% gewijzigd door van.der.schulting op 26-05-2011 02:34]

[.oisyn]

Hoe kan een scrum tool nou gericht zijn op een specifiek platform / programmeertaal

[chime]

Whiteboard en post-its aan een muur ... meer heb je eigenlijk niet nodig.

[Andre-85]

Volledig eens met chime. Scrum moet zichtbaar, tastbaar en flexibel zijn. Een wand met grote vellen papier of een whiteboard, post-its, en een excel sheet voor de burndown. Veel meer heb je niet nodig.

Werk je in een team wat fysiek niet bij elkaar zit, kan een tool het overwegen waard zijn.

[van.der.schulting]

Andre-85 schreef op donderdag 26 mei 2011 @ 09:42:
Volledig eens met chime. Scrum moet zichtbaar, tastbaar en flexibel zijn.

Ik zie niet in waarom Scrum zichtbaar, tastbaar en flexibel moet zijn. Kun je mij dat uitleggen?

[Andre-85]

Scrum heeft mede als doel het inzichtelijk maken van voortgang, en het zichtbaar maken van impedements. Wanneer je dit 'verstopt' in een tool gaat deze zichtbaarheid verloren. Verder heb je als scrumteam fysiek een plek waar je in een klap kan zien waar aan gewerkt wordt.

Verder denk ik dat zo'n tool waste introduceert. Je kan sneller wat briefjes verhangen dan dat via een tool te moeten doen. Bij mijn weten behandeld geen van de gerenomeerde scrum boeken het gebruik van specefieke tooling. Dat zegt natuurlijk ook iets.

[van.der.schulting]

Andre-85 schreef op donderdag 26 mei 2011 @ 16:19:
Verder denk ik dat zo'n tool waste introduceert. Je kan sneller wat briefjes verhangen dan dat via een tool te moeten doen.

Bij ScrumNinja is het wel de bedoeling dat je de post-its versleept, zij het wel op je beeldscherm . Dan hou je inderdaad het probleem dat je geen fysieke plek hebt waar je briefjes hangen...

Maar hoe bedoel je dat 'zon tool waste introduceert'? Kun je dat iets meer uitleggen?

[BasieP]

Ik ben bang dat zo'n tool werkprocessen die stupid simple zijn (het ophangen van post-it's) ingewikkeld maakt.
dwz. Je teamleden moeten nu inloggen in zo'n app, connecten naar juiste project, en dan zien ze waarschijnlijk maar een deel van de post-its.

(en nee, ik ken de software niet)

maar 1 van de speerpunten van agile ontwikkelen is kiss.

zie ook:
http://agilescout.com/phy...for-agile-keep-it-simple/

[Voor 20% gewijzigd door BasieP op 26-05-2011 18:51]

[.oisyn]

Ik moet er niet aan denken dat ik met de hand post-it's moet gaan zitten verplaatsen . Sowieso ben ik niet zo'n fan van de "items on a wall" view. Daarnaast is er met een fysieke post-it geen enkele koppeling met andere bronnen voor meer informatie (bug database, user stories, uitgebreide beschrijving, etc)

Je teamleden moeten nu inloggen in zo'n app, connecten naar juiste project

En je staat er niet even bij stil dat zo'n tool waarschijnlijk gewoon standaard draait op je PC? Dus niet inloggen e.d., gewoon even een windowtje openklikken vanuit je luie stoel.

[Voor 63% gewijzigd door .oisyn op 26-05-2011 22:26]

[BasieP]

.oisyn schreef op donderdag 26 mei 2011 @ 22:24:
En je staat er niet even bij stil dat zo'n tool waarschijnlijk gewoon standaard draait op je PC? Dus niet inloggen e.d., gewoon even een windowtje openklikken vanuit je luie stoel.

Ik vind het leuk te lezen dat we beide niet weten hoe het precies gaat, en jij mij wijst op iets wat ik misschien verkeerd gok

[.oisyn]

Je begrijpt me verkeerd, ik werk dagelijks met zo'n tool . Maar al deed ik dat niet, dan leek me het alsnog voordehandliggend dat je gewoon standaard ingelogd bent, zoals met alle collaboration tools.

[BasieP]

.oisyn schreef op donderdag 26 mei 2011 @ 22:31:
Je begrijpt me verkeerd, ik werk dagelijks met zo'n tool . Maar al deed ik dat niet, dan leek me het alsnog voordehandliggend dat je gewoon standaard ingelogd bent, zoals met alle collaboration tools.

mja dingen die jij (en ik eigenlijk ook) standaard vinden zijn helaas niet overal aanwezig. Ikzelf heb op mijn werk al 4 inlogschermpjes voordat ik uberhaupt apps kan opstarten.
Vervolgens vragen die ook weer om wachtwoorden die elke 3 maanden verlopen en aangezien ik aan meerdere projecten werk moet ik ook daarin handmatige acties doen om daadwerkelijk te zien wat ik wil zien.

Natuurlijk kennen we beide de TS z'n situatie niet, maar zoals ik al wilde zeggen dmv het posten van die link:
het gebruik van post-its heeft zo z'n voordelen boven een applicatie

[.oisyn]

Good point, ik vergeet soms weleens dat sommige mensen moeten werken in een enorm bureaucratische IT-omgeving

[Voor 3% gewijzigd door .oisyn op 26-05-2011 22:35]

[chime]

Wel een tip: magnetisch bord pakken en post-its met magneetjes bevestigen ... anders wilt het wel eens gebeuren dat sommige taken na een tijdje "lossen"

Anderzijds: vaak werkten wij met 1 post-it met daarop de zin van de user story en totale schatting, daaronder verschillende die de subtaken preciseerden.

Post-its worden bij de dagelijkse stand-up aangepast.

Elektronische tools is allemaal leuk en wel, maar je verliest dan wat spontaniteit bij de stand-up.
Of erger => je kan de tool bij de stand-up niet (of heel omslachtig) gebruiken.

Gewoon het KISS principe toepassen: hoe simpeler, hoe beter ... ik kan weinig simpelere dingen bedenken dan een papiertje aan de muur op the hangen

[Znisses]

Wat Chime aangeeft met magnetisch bord en briefjes, doen wij ook, juist om de reden die Chime ook al aangeeft.

Wij hebben echter een intern system (soort forum in ASP, compleet inhouse ontwikkeld) waarin we issues vastleggen en toekennen aan mensen en teams. Hier doen we dan bijvoorbeeld ook de urenadministratie (veel issues voor veel klanten maakt facturering op andere manier haast ondoenlijk. In dit systeem hebben we een pagina gemaakt dat de burndown chart rendert op basis van de toegekende issues aan een sprint en de daar weer aan toegekende estimates.

Dit neemt niet weg dat we nog steeds 's morgens de scrum meeting doen voor het bord om even (max 15 min) de boel door te spreken en de voortgang te bespreken. We hebben er over nagedacht om ook dat digitaal te maken maar dat maakt meetings wat moeilijker (ondanks dat we maar een klein team zijn) aangezien het whiteboard 1 bij 2 meter is en we niet zulke grote schermen hebben )

Ik kan me enkel een digitale variant bedenken die wel zou werken maar dan moet je wel een beamer hebben in combinatie met whiteboard, anders haal je toch te veel uit een scrum meeting wat je volgens mij wel wilt behouden.

Maar zoals scrum ook al een beetje aangeeft, het moet voor jou en je team werken. Scrum is geen doel maar een methode/tool om een doel te bereiken

[Appesteijn]

Zoals je hierboven al kan lezen heeft een digitaal bord voor- en nadelen. Ikzelf ben groot fan van een analoog bord, dus 'echte' briefjes op een whiteboard. Dit heeft een aantal voordelen:
- De post-it's en het bord zijn fysiek, hierdoor nemen teamleden eerder eigenaarschap over het bord en de briefjes. Het scrumbord wordt de centrale plek van het team + als briefjes worden verplaatst, moet iemand opstaan en dit gaan doen waardoor iedereen in de buurt ziet dat er iets verandert.
- Je bent veel transparanter. Als je het bord (+extra informatie) goed inricht, kan een willekeurige voorbijganger in 30 seconden zien hoe het met je project gaat. (mbv Burndown, maar ook bv teamsfeer, KPI's, etc)
- Er is op een bord in een keer overzicht over alle post-it's. Bij een digitale variant moet je toch vaak scrollen omdat niet alles op een scherm past.
- Je kan makkelijk een extra kolom op je bord tekenen, met limieten gaan werken, het bord anders indelen, etc. Bij een digitale variant wordt je toch vaak beperkt door wat de tool kan en wat niet. Bij een analoog bord heb je deze beperking minder.

Voordelen van een digitaal bord:
- Koppelingen met bugtrackers, extra informatie (bv documentatie) is makkelijker te realiseren.
- Mensen kunnen er overal vandaan bij. (Dit vind ik ook een nadeel, want waarom zouden we dan nog met elkaar fysiek aanwezig zijn...)
- Briefjes kunnen niet van het bord vallen/ je hebt vaak een automatische backup oid.

[YopY]

quote: Chime

anders wilt het wel eens gebeuren dat sommige taken na een tijdje "lossen"

Dat is een 'smell', dat betekent dat je taken te lang blijven hangen, .

En post-its zijn leuk, onze 5x5 raamloos vergaderkamertje met twee bureaus en 5 mensen (tops) wordt er een stuk fleuriger van .

[van.der.schulting]

Thanks voor alle replies

Omdat het hele team van ons nog geen ervaring heeft met Scrum zit ik er toch aan te denken om het eerste Scrum project volledig digitaal te doen mbv ScrumNinja. Dus ook digitale post-its etc.
De belangrijkste reden hiervoor is dat we dan niet meteen onze 'eigen' methodiek erop nahouden, zoals sommigen in dit topic aangeven. Immers houd de digitale tool dit tegen. Het lijkt mij niet zo verstandig om bij het eerste project met alleen mensen zonder scrum-ervaring meteen een heel eigen methodiek te ontwikkelen. Persoonlijk denk ik dat het het verstandigst is om bij het eerste project je volledig te houden aan de Scrum-methodiek, zoals deze ooit bedoeld was.

Wat vinden jullie ervan om bij het eerste Scrum-project je volledig te houden aan de Scrum-methodiek, met behulp van een volledig digitale tool ipv een whiteboard met post-its?
En zoals aangegeven de belangrijkste reden om de digitale tool te gebruiken is het feit dat we dan niet kunnen afwijken van de Scrum-methodiek, immers houd de tool dit tegen.

[Appesteijn]

Heel erg goed dat je om het aan te leren strak de regels gaat volgen. Vaak weet je in het begin nog niet precies wat het effect en de bedoeling is van bepaalde regels en is het makkelijk om ze te negeren (bv een retrospective of een demo). Soms krijg je het gevoel dat 'je zit te mierenn**ken', maar je zult zien dat overal goed over is nagedacht en je door de 'ellende' van de verandering heen moet gaan. Daarna wordt het alleen maar leuk!

Ik zou in de beginfase juist een fysiek scrumbord gebruiken, zodat niemand er omheen kan dat jullie op een andere manier software willen gaan bouwen. Dat bord blijft daar staan en kan niet worden weggeklikt. Het is anders te makkelijk om net te doen alsof je net zo werkt als 'vroeger'.

Je kan ook makkelijker starten door met het team het bord te gaan maken, zo wordt het bord van iedereen en niet alleen van jou (of de andere teamleden die al enthousiast zijn). Bij een elektronisch bord is dit toch lastiger en is er niets fysieks aanwezig.

[Remus]

van.der.schulting schreef op vrijdag 27 mei 2011 @ 13:57:
Wat vinden jullie ervan om bij het eerste Scrum-project je volledig te houden aan de Scrum-methodiek, met behulp van een volledig digitale tool ipv een whiteboard met post-its?
En zoals aangegeven de belangrijkste reden om de digitale tool te gebruiken is het feit dat we dan niet kunnen afwijken van de Scrum-methodiek, immers houd de tool dit tegen.

Scrum geen methodiek, maar een raamwerk om je software ontwikkelproces en de samenwerking in een team mee te sturen. Gebruik van Scrum betekent niet dat je slaafs moet doen wat Scrum beschrijft: je moet nadenken, kijken wat het beste werkt voor jouw project.

Het gebruik van een whiteboard met stories, sticky notes ed is dan een stuk flexibeler en open voor aanpassing aan jouw project en jouw team dan een of andere software tool die een werkwijze afdwingt die vervolgens niet helemaal werkt voor jouw team. Zoek eerst uit wat werkt voor je team en ga daarna pas op zoek naar een tool die daar bij aansluit.

Scrum is een middel om je software ontwikkeling te doen, niet het doel!

[SeatRider]

Mee eens, maar het is niet verkeerd om het eerste project gewoon alle dingen te proberen die er volgens scrum bijhoren. Dus iedere sprint met planningpoker beginnen, en met een demo en evaluatie eindigen. Je merkt dan vanzelf wel wat voor jouw situatie wel en niet werkt. Ik heb twee jaar full flex gescrumd, en met mijn nieuwe team doe ik nu een afgeslankte (lean!) versie van scrum.

We werken in sprints van 4 weken, er wordt een backlog bijgehouden middels Google Spreadsheet en het team levert na elke sprint iets op dat getest is en werkt, en dus live kan. We zagen niet zo veel meer in evalueren om het evalueren. Om de moeilijkheid van de grotere issues te beoordelen laat ik een teamlid iedere sprint enkele inschattingen doen (in de orde van 1 dag/1 week/1 maand). Zo kunnen we beoordelen of iets de moeite waard is.

Nu ik het zo teruglees heeft het niet meer zo veel met scrum van doen, eerder gewoon agile .

Maar goed, een scrum tool is nergens voor nodig, een bord is wel zo leuk, en als de teams niet bij elkaar zitten (zoals bij mij) werkt Google docs net zo makkelijk.

[van.der.schulting]

Nu had ik het er dit weekend nog met iemand over en kwamen we tot de conclusie dat het toch handiger is om inderdaad een fysiek whiteboard te hebben ipv een digitaal whiteboard. Dit omdat ik de enige developer ben en ik kan niet van de andere mensen verwachten dat zij altijd gaan inloggen op het digitale systeem.

So far so good. Nu mijn volgende probleem:
Zoals ik aangaf ben ik de enige developer. Niemand, behalve ik, heeft een boodschap aan allerlei 'technische' taken als 'create db for story' en 'write test for story'. De enige boodschap die zij hebben is dat ze 'langzaam' alle technische gele briefjes op het bord van links naar rechts zien verplaatsen. Zo kunnen zij zien hoever een story is gevorderd.
Mijn vraag is: Wat vinden jullie?
1. Moet ik een whiteboard ophangen met alleen maar stories op gele briefjes en de technische taken elders bijhouden (verbergen voor de andere projectleden)? Zij hebben immers geen enkele boodschap aan deze taken.
2. Moet ik mijn stories op het bord schrijven en de technische taken op de gele briefjes zetten. Hoewel de andere projectleden geen boodschap hebben aan mijn technische taken, kunnen zij wel aan de hand van waar de technische taken hangen 'aflezen' welke stories klaar zijn en welke nog gedaan moeten worden.

Mij lijkt optie 2 handiger, maar tegelijkertijd vraag ik me een beetje af, heeft een story wel voldoende technische taken om deze nog eens op aparte briefjes onder te verdelen?
Hoe denken jullie erover?

[eamelink]

Wij schrijven de stories op de post-it's, jouw optie 1 dus. De stories kan je vertalen in een aantal technische issues (create db, write test, etc.) en die kan je dan in een issue tracking systeem bijhouden, als je dat nodig vindt. Ik kan me goed voorstellen dat je dat ook achterwege kan laten. In principe zijn er toch niet meer dan een of enkele stories tegelijkertijd in progress, dus de taken die bij daarbij horen zijn nogwel in je hoofd te houden

[Appesteijn]

Ik zou voor optie 2 gaan. Ondanks dat de rest geen idee heeft van de technische taken die uitgevoerd moeten worden, kunnen ze (zoals je zelf al aangeeft) wel zien wel user-stories (en dus functionaliteit die hen wel wat zegt) al bijna klaar is om getest te worden.

Ook geeft het jou structuur en inzicht over welke en hoeveel taken je nog moet uitvoeren om een userstory af te ronden.

[Dragor]

Ik zou voor optie 2 gaan om de redenen die hierboven gegeven zijn.

Maar het mooie van Agile/Scrum is dat je aan het einde van elke sprint een retrospective doet. Daarin bepaal je wat er in de afgelopen sprint goed en slecht is gegaan en (een deel van) de slechte dingen ga je proberen te verbeteren in de sprint erna. Dit kan dus ook zijn dat een fysiek whiteboard voor jou (of je collega's) niet goed werkt.

Ik zou zeggen probeer gewoon optie 2 en mocht je er daarna achterkomen dat het niet werkt, gewoon iets anders proberen.

[bonzz.netninja]

optie 2. Je stories zijn sowieso te groot om los te scrummen dus dat moet je wel doen op geeltjes niveau.Uitdaging zit natuurlijk in het kunnen maken van losse testbare geeltjes (ja dan kan altijd maar is soms wel lastig)

[SeatRider]

Zeker niet optie 2. Een (user) story is een feature of wens die als geheel een bepaald nut voor de gebruiker oplevert. Daarom zijn ze ook altijd opgesteld in de vorm van "als $rol wil ik $activiteit zodat ik $nut". De user story wordt compleet uitgevoerd opgeleverd, of helemaal niet. Als ie niet compleet, niet werkend of niet getest is, zit ie niet in de release. Natuurlijk valt een user story op te knippen in talloze losse taken (icoontje maken, rapportage aanpassen, testplan herschrijven, database migratie, etc) maar die hou je niet bij op het bord maar zoals gezegd in een losse tracker. De product owner heeft namelijk alleen boodschap aan de status van de user story als geheel.

Dus optie 1

[bonzz.netninja]

SeatRider schreef op maandag 30 mei 2011 @ 09:02:
Zeker niet optie 2. Een (user) story is een feature of wens die als geheel een bepaald nut voor de gebruiker oplevert. Daarom zijn ze ook altijd opgesteld in de vorm van "als $rol wil ik $activiteit zodat ik $nut". De user story wordt compleet uitgevoerd opgeleverd, of helemaal niet. Als ie niet compleet, niet werkend of niet getest is, zit ie niet in de release. Natuurlijk valt een user story op te knippen in talloze losse taken (icoontje maken, rapportage aanpassen, testplan herschrijven, database migratie, etc) maar die hou je niet bij op het bord maar zoals gezegd in een losse tracker. De product owner heeft namelijk alleen boodschap aan de status van de user story als geheel.

Dus optie 1

Dat is niet zoals scrum werkt (maar dat zegt niet dat je dat niet moet doen). Maar SCRUM is in eerste instantie een ontwikkelmethodiek en helpt je dus ontwikkelen.

Zoals ik gewend ben is dat ik bijvoorbeeld 3 story's (witjes) op het bord hangen (wat er past in de sprint) en daarnaast alle geeltjes die daarbij horen. Vervolgens ga je de sprint in en gaat development lekker geeltjes verhangen tot einde van de sprint (en dus 3 mooie afgeronde stories). Hierbij zijn
- de geeltjes los testbaar
- en de uiteindelijke storie ook los testbaar

maar volgens mij zijn we het wel met elkaar eens en bedoelen we het zelfde

[Standeman]

Ik gebruik over het algemeen xplanner(-plus) om sprints in te plannen. Werkt redelijk eenvoudig en vrij flexibel. Zelf stop ik alles liever in een systeem, omdat je dan achteraf makkelijker de pijnpunten kunt identificeren en hoeveel tijd je waaraan hebt besteed.

Met alleen post-it's, excelsheets en een whiteboard kom je ook een heel eind en kan je prima een sprint doen, alleen is het dan achteraf wat lastiger om de sprint te analyseren omdat er een hoop info verloren gaat over het wie wat waar aan heeft gewerkt en hoeveel tijd het heeft gekost.

[Avalaxy]

Ik raad iedereen aan het boek Scrum and XP from the trenches te lezen, heel erg goed boek voor iedereen die met Scrum werkt of er mee wilt werken

[Anoniem: 168180]

Overzicht gebruik scrum tools in de wereld:
http://devsnotebook.free.fr/index.php?post/Tools-used-for-agile-projects-%3A-the-survey-results-!

Overzicht van (bijna) alle beschikbare scrum tools:
http://agilescout.com/best-agile-scrum-tools/

Succes

[Voor 24% gewijzigd door Anoniem: 168180 op 16-06-2011 15:26]