Categorie Archief Artikelen

Dagelijkse 15 minuten stand-up, start-van-de-dag, scrum of flow-sessie

Je bent tegenwoordig géén echt ontwikkelteam meer als je niet elke dag even samen gaat staan om een Stand up – , een Scrum – of een Flow sessie te doen. Als het aan het begin van de dag is wordt het ook wel Start van de dag sessie genoemd. En – hoewel niet dagelijks – de Keek op de week heb ik ook al langs zien komen. Ik ben helemaal voorstander van dit soort sessies, het geeft je de mogelijkheid om je activiteiten in het team te synchroniseren en de communicatie simpel te verbeteren. Iedereen krijgt de kans om op de hoogte zijn van wat er speelt. En vooral belangrijk iedereen krijgt de kans om hulp te vragen!

Wat Wat Wat

Tijdens de stand-up sessie is het de bedoeling om er achter te komen wat er speelt in het team en waar eventueel nog hulp nodig is. Veelal wordt er gebruikt gemaakt van een drietal vragen:

  1. Wat heb je bereikt sinds de vorige bijeenkomst?
  2. Wat ga je doen voor de volgende bijeenkomst?
  3. Wat zijn de obstakels die je nu in de weg staan?

Soms draai ik de vragen om. Dus als eerste Wat zijn de obstakels, dan Wat ga je doen en als laatste Wat heb je bereikt. Ik merk dat deelnemers vaak de meeste zendkracht hebben aan het begin van hun verhaal en dat snel de aandacht van de toehoorders verslapt. Aangezien ik het meest interessants vind waar iemand tegenaan loopt (zodat ik je kan helpen!) en minder interessant vind wat je gisteren hebt gedaan (ik kan je toch niet meer helpen) draai ik de vragen om.

Ongeveer 15 minuten

Een stand-up duurt ongeveer 15 minuten. Er is dus niet veel tijd om iedereen uitgebreid aan het woord te laten. Vooral ingewikkelde inhoudelijke discussie zorgen ervoor dat je heel erg kunt uitlopen.  Het is niet de eerste keer dat ik dan ongeïnteresseerde deelnemers zie staan die soms ook nog even hun facebook of twitter aan het bekijken zijn. Zonde van de tijd dus. De facebook-checkers hadden wellicht beter gewoon aan het werk kunnen zijn! Het is gebleken dat een duur van 15 minuten lang genoeg is. Als je dit dagelijks doet dan komt het niet vaak voor dat er ineens allerlei grote onbekende problemen naar voren komen. Of heeft iemand de vorige sessie staan slapen….? Een 15 minuten sessie betekent wel dat je stand-up gestructureerd moet laten verlopen. Hiervoor heb ik een aantal huishoudelijke regels. Ik pas ze toe als dit nodig is:

  • Één iemand praat de rest luistert. Dus niet iedereen door elkaar heen praten.
  • Wees voorbereid. Wat heb ik ook alweer gedaan gisteren? is niet de juiste opmerking.
  • Privé zaken voor later. Dat je gisteren voetbal hebt gekeken is heel interessant maar bespreek dat op een ander moment.
  • Wijs je sticky note aan. Bij het gebruik van agile dashboards met sticky notes is het handig als de spreker zijn of haar sticky notes ook aanwijst. Deze fysieke beweging zorgt ervoor dat iedereen meteen ziet waar het over gaat
  • Kom op tijd! Dan mag je ook weer op tijd weg en verspeel je niet de tijd van anderen.
  • Focus op het doel. Dit kan het einde van de sprint zijn, de opleverdatum of het zo snel mogelijk de werkzaamheden op  Done te krijgen met zo min mogelijk work-in-progress.
  • Het is geen statusupdate meeting voor de projectleider of andere management. Hiervoor zijn andere middelen. Het is bedoeld is van en voor de teamleden.

Chicken and Pigs

Bij wat grotere teams heb ik het liefst dat alleen de personen aan het woord zijn die werkelijk een bijdrage moeten leveren aan het eindproduct. Natuurlijk zijn andere personen zeer welkom bij de sessie als toehoorder. De bekend agile cartoon over chicken and pigs past hier goed bij http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig . Een Product Owner is wat mij betreft onderdeel van het team. Hij of zij wordt dus ook verwacht bij de stand-up en moet dus ook actief mee doen.

Ritme

Het is goed om de stand-up elke dag op dezelfde tijd en plaats te houden. Het zal dan sneller een gewoonte worden waardoor in het team in een ritme gaat komen. Het kan voorkomen dat iemand een keertje niet kan. Ga vooral door met de stand-up op hetzelfde moment en locatie. Eventueel kan de afwezige vooraf een mede teamlid informeren zodat deze de plek van de afwezige in kan nemen. Dit mag geen gewoonte worden!

Volhouden

Hoewel soms een stand-up als last wordt gevoeld is het toch verstandig om door te zetten. Zodra het blijkt dat tijdens de stand-up geen nieuwe informatie wordt verteld en geen hulp meer wordt gevraagd omdat iedereen al op de hoogte is, dan kun je ervoor kiezen om minder stand-ups te doen. Ik heb dit nog nooit meegemaakt. Er is altijd wel iets te melden of er is hulp nodig. Dus wat mij betreft gewoon volhouden! De enige keer dat ikzelf dacht dat de stand-ups wellicht overbodig ging worden waren juist de teamleden erg enthousiast! Het was de mogelijkheid om te tonen dat het goed ging! De projectleiding en productowner waren toendertijd heel tevreden (en we hoefden geen ingewikkelde excelrapporten te maken met allemaal groene smileys). Als je het goed doet kost een stand-up ook niets. Alle tijd de je investeert levert direct tijd op door de juiste hulp die je krijgt en door de besparing op andere sessies zoals teamoverleg, wekelijks projectoverleg maar ook kennisoverdrachtsessies en andere voortgangsmomenten.

Tips

Tijdens de vele stand-up sessies die ik heb meegemaakt heb ik nog wat leuke tips gevonden die je eventueel kunt toepassen:

  • De laatste persoon die zich aansluit bij de stand-up sessie is degene die sessie faciliteert: Het hoeft niet altijd de scrummaster te zijn en dit kan helpen zodat iederen op tijd aanwezig is.
  • Gebruik een toeter om iedereen te attenderen op de stand-up sessie: Hoewel iedereen zelf de tijd in de gaten kan houden hebben mensen soms moeite om hun werk los te laten..
  • Een stand-up heet niet voor niets stand-up: Als je staat ben je automatisch actiever en alerter. Blijf je achter je bureau zitten dan ben je toch eerder afgeleid.
  • Doorloop niet altijd dezelfde richting. Ga eens de andere kant op.
  • Doe een rondje per product backlog item. Vooral als je een aantal product backlog items hebt ingepland die minder met elkaar te maken hebben.

De stand-up sessie is wat mij betreft één van de technieken in de agile wereld die je gewoon moet doen en geen discussie over de effectiviteit. Alleen de mensen die dit nog nooit goed hebben ervaren twijfelen.

Estimation and planning with smart use cases

Wat zijn smart use cases. Hoe kan kan ik er mee schatten en nog meer informatie. Deze presentatie heb ik gedaan tijdens het smart use cases event van Capgemini in 2008. De slides staan online!

Wil je meer weten over Smart use cases? Wat zijn de verschillen en overeenkomsten met user stories, gewone use cases? Hoe kun je slim en pragmatisch omgaan met specificaties in een agile werkwijze? Neem dan contact met mij op. Ik help je verder!

Presentatie Wat is scrum?

Regelmatig heb ik presentaties mogen geven over Scrum. Ik leg dan uit wat specifiek scrum is, waar bestaat het uit, welke ceremonies zijn en nog veel meer. Veelal vul ik de slides aan met mijn praktijkervaringen en tips van de werkvloer.

In 2008 heb ik een presentatie gegeven bij Capgemini en deze staat online!

Wil je meer weten over Scrum? Wat zijn de verschillen en overeenkomsten met Scrum, agile en waterval en hoe kun je scrum implementeren en gebruiken in je organisatie? Neem dan contact met mij op. Ik help je verder!

Time as an actor for scheduled use cases

TIMERIn an use case model the actor is someone or something outside the system that interacts with the system. An actor may be a person, a device, another system or sub-system. The actor is represented as a “stickman” icon.

So what should we do when we want a use case is automatically started on a certain moment? Probably started by some scheduling mechanism.

According to the definition of an actor we need to know if the scheduling mechanism is a part of the system or something outside the system. Is it part of the system then you don’t model a actor. Is it something outside the system you do model the actor (with the name of that scheduling system)

But when modeling use cases we don’t know or we don’t want to know about how the system is implemented. So it’s not clear if we need to model the actor.

I prefer that all user goal level use cases are always started by an actor. Then I can easily check of my model is complete: every use case needs to be associated with an actor or with another use cases. If not the use cases is useless and can be removed from your model.

My recommendation is always model a Time actor for scheduled use cases also when the scheduling is implemented inside the system. It makes your model clear and complete.

ASP.Net Config Tool and MOSS 2007

Today our SharePoint server raised a nice exception: ‘File not Found’ when you tried to log on. Off course we were already familiar with the sound exceptions SharePoint raises so we inspected the event log.
Error: Failure in loading assembly: Microsoft.SharePoint.Portal, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c
Error: Failure in loading assembly: Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c

The solution was pretty forward, but raises the question how compatible is Microsoft with Microsoft…..

It seems that when you modify the web.config with the ASP.Net Configuration Tool, it adds an attribute (xmlns) to the <configuration> tag like so: <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
By removing the xmlns attribute the SharePoint the problem was solved.

041107-1221-aspnetconfi1.gif