{"id":49,"date":"2019-08-14T15:01:48","date_gmt":"2019-08-14T15:01:48","guid":{"rendered":"http:\/\/scrum-agile.nl\/?page_id=49"},"modified":"2019-08-15T10:43:09","modified_gmt":"2019-08-15T10:43:09","slug":"zelf-organisatie-en-happiness","status":"publish","type":"page","link":"https:\/\/scrum-agile.nl\/?page_id=49","title":{"rendered":"Zelf-organisatie en Happiness"},"content":{"rendered":"\n

Onderstaande blog is door gastschrijver Rogier den Dulk geschreven.<\/em><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Een van de\ntwaalf van Agile principes is werken met zelf-organiserende,\nmulti-disciplinaire development teams. Zelf-organisatie is wat mij betreft is\ndit \u00e9\u00e9n van de meest lastige principes van Agile om te realiseren.\nHet klinkt namelijk simpel, maar vaak wordt niet helemaal begrepen wat hier mee\nwordt bedoeld en zeer vaak onderschat hoe lastig het is om teams echt\nzelf-organiserend te maken.<\/p>\n\n\n\n

Gelukkig zijn er\nmethode om zelf-organisatie te stimuleren. In dit artikel zal ik hier \u00e9\u00e9n\nvan toelichten.<\/p>\n\n\n\n

Hoera, we zijn\nzelf-organiserend
\n<\/strong>Zelf-organisatie betekent voor Scrum dat het (development) team zelf\nverantwoordelijk is voor de  werkinrichting en het resultaat dat\nhieruit komt. Alles wat nodig is om het sprintdoel te bereiken wordt door het\nteam zelf georganiseerd, evenals problemen oplossen die in de weg staan om het\nsprintdoel te bereiken.<\/p>\n\n\n\n

Door\nonervaren buitenstaanders van het Scrumproces wordt dit ook wel eens\ngezien als \u201cdevelopers mogen doen waar ze zin in hebben\u201d, maar dat\nverre van waar. Met zelf-organisatie geef je de developers de\nverantwoordelijkheid om te voldoen aan het commitment dat ze afgeven op\nhet leveren van waarde. Ze zijn gebonden aan afspraken die ze maken met hun\nproduct owner en hebben tevens te maken met vele invloeden van buitenaf die bepalend\nzijn voor het succes.<\/p>\n\n\n\n

Leiden doet volgen
\n<\/strong>Helaas kom ik vaak veel tegen dat product owners (PO) zich opstellen als de\nleider van een team. Soms wordt dit ingegeven omdat de product owner zich\nals een soort van opdrachtgever voelt voor het development team. In andere\ngevallen komt dit voort uit een traditioneel leidinggevende, die de\nrol van Product Owner op zich heeft genomen.<\/p>\n\n\n\n

Het is belangrijk om\nte benoemen dat er geen hi\u00ebrarchische relatie is tussen PO en\ndevelopment team; ze hebben uiteraard een aparte rol en verantwoordelijkheid,\nmaar zijn onderdeel van hetzelfde team. Sterker nog, het behalen van een sprint\ndoel is evengoed het resultaat van de PO (die zorgt voor waardevolle\nstories) en het development team, die zijn commitment waarmaakt.<\/p>\n\n\n\n

De valkuil van een PO\nom jezelf als leider op te stellen is dat je zelf-organisatie in de wielen\nrijdt. Hier geldt de wetmatigheid: leiden doet volgen. Wanneer er sterk\nwordt gestuurd op een team, dan zal dat team zich geremd voelen om\ninitiatief te nemen en als zelfstandige te opereren. Je veranderd dus\nprofessionals in dozenschuivers.<\/p>\n\n\n\n

Zelf-organiserend is\nniet vanzelfsprekend
\n<\/strong>Zelfs als er geen sterke leidende invloed uitgaat van een PO zullen\ndevelopment teams het soms lastig vinden om zelf-organiserend te werken.\nGegeven door een cultuur of een hi\u00ebrarchische organisatie waar ze uit\nvoortkomen is het geleerde gedrag opdrachten volgen. Maar ook een volle product\nbacklog draagt bij aan het gevoel dat er maar gewoon moet worden\n\u201cdoorgewerkt\u201d en geen ruimte voor reflectie of initiatief om werk slimmer in te\nrichten of processen of tools in te richten die ten goede komen van kwaliteit of\nefficiency.<\/p>\n\n\n\n

Om zelf-organisatie\neen \u201cfighting chance\u201d te geven kan het verstandig zijn om binnen een\ndevelopment team een aantal voorzieningen te treffen die kunnen helpen het\ngedrag te veranderen.<\/p>\n\n\n\n

Implementeer Happiness
\n<\/strong>Een methode die ik zelf toepas om zelf-organisatie te stimuleren\nis de implementatie van Happiness. Happiness is een met de PO afgestemd\n\u2018budget\u2019 (een percentage van de team velocity) dat wordt toegekend aan een\ndevelopment team en zij naar eigen inzicht kunnen inzetten. Happiness\nis feitelijk een mini-hackathon dat plaatsvind binnen de context van een\nSprint.<\/p>\n\n\n\n

De spelregels\nvan Happiness zijn als volgt:<\/p>\n\n\n\n

  1. Het team in overleg met elkaar bepalen hoe\n dit budget wordt besteed (de uitvoering mag samen of individueel, maar er\n moet consensus zijn over het gebruik hiervan);<\/li>
  2. Het team moet bij de review\n demonstreren\/presenteren hoe het budget is besteed, waarom hiervoor\n gekozen is en wat de resultaten zijn.<\/li><\/ol>\n\n\n\n

    De deliverables die\nuit Happiness komen lopen sterk uiteen, maar zijn altijd ten bate van het\nteam. Uit mijn praktijk heb ik team zien komen met voorstellen van oplossingen\nvoor vaak voorkomende verstoringen, proefopstellingen voor nieuwe tooling of\ntechnologie, de volgende stap richting continuous delivery, en ga zo maar door.<\/p>\n\n\n\n

    Happiness geeft vleugels
    \n<\/strong>De echte opbrengst van Happiness is een shift in bewustzijn van zowel het\nDevelopment Team en de Product Owner.<\/p>\n\n\n\n

    Door het toepassen\nvan Happiness leren development teams:<\/p>\n\n\n\n