Difference between revisions of "Planningsspel voor zelf-organiserende teams"

From AardRock Wiki
Jump to navigation Jump to search
m
 
m
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Een team wordt bij elkaar gebracht waar mensen elkaar nog niet kennen,  
Een team wordt bij elkaar gebracht waar mensen elkaar nog niet kennen,  
en nog maar weinig weten van hetgeen ze realiseren willen, en hoe ze dat willen doen. Bij een samengaan van twee ondernemingen bijvoorbeeld, gebeurt het dat uit beide organisatie mensen ingeseind worden om met elkaar te praten en denken over de gezamenlijke toekomst.  
en nog maar weinig weten van hetgeen ze realiseren willen, en hoe ze dat willen doen. Bij een samengaan van twee ondernemingen gebeurt het dat uit beide organisatie mensen ingeseind worden om met elkaar te praten en denken over de gezamenlijke toekomst. Ook besluiten mensen in een netwerk om een groepje te vormen, met het idee om gezamenlijk iets te gaan ontwikkelen: een product, een rapport, een voorstel aan een overheid.  


Om met een dergelijk team resultaten te bereiken, op een prettige manier, is een manier van werken nodig die helpt om deze groet obstakels effectief te nemen.  
Het probleem.
Teamleden kennen bij aanvang van een project veelal elkaar's talenten en persoonlijkheden niet. Ook zijn ze onzeker over wat precies de bedoeling is, wat ze met elkaar moeten of willen gaan doen, en hoe dit aan te pakken. Ook speelt een rol dat mensen hun eigen projectspecifieke vaardigheden en rollen vaak nog niet kennen, en niet weten hoe groot en complementair die vaardigheden en rollen zijn ten opzichte van anderen in de groep. tenslotte is onduidelijk wat de waarde is die eenieder ervaart van het werken met de groep, en welke waarde er in totaal uitkomt.  


Om met al deze onzekerheden en onduidelijkheden resultaten te bereiken op een manier die prettig is en eenieder eert in zijn of haar waarden en gedrag, is een lekker werkende procesaanpak nodig. Daarover gaat dit patroon.


==hoe werkt het?==
Het {{pattern|planningsspel voor zelf-organiserende teams}} kan grotendeels hetzelfde zijn als het {{pattern|planningsspel voor ontwikkelprojecten}} met dien verstande, dat het zelf-organiserende team afwisselend zowel de rol van klant als de rol van ontwikkelaar speelt. Dit werkt (zelfs in een simulatiespel dat we gebruiken), als iedereen er op alert is - iemand die het planningsspel faciliteert kan daarbij helpen.


De reden dat in het {{pattern|planningsspel voor ontwikkelprojecten}} de rollen zo strict gescheiden zijn, is dat niet iedereen (in eerste instantie) voldoende distantie kan creeren om zowel moeilijkheid als waarde in te schatten, waardoor bij voorbeeld altijd hetmeest 'interessante' of het moeilijkste werk eerst wordt gedaan, in plaats van het meest waardevolle.


Ten eerste is er een beeld met een archetypisch voorbeeld van dat patroon.
=={{pattern|maar dit geheel terzijde}}==
    * Ten tweede, na het beeld, heeft elk patroon een inleidende paragraaf dat de context zet voor dat patroon en uitlegt hoe dit patroon andere patronen helpt te volmaken.
Het grappige is dat door het regelmatig spelen van het {{pattern|planningsspel}} mensen vanzelf beter worden dingen op waarde te schatten, en plezier gaan beleven aan het opleveren van waarde (in plaats van plezier in 'moeilijke uitdagingen' of 'technisch interessant werk').
    * Vervolgens markeren drie diamanten het begin van het probleem.
    * Na de diamanten volgt een kopregel, vetgedrukt. Deze kopregel geeft de essentie van het probleem weer in een of twee zinnen.
    * Na de kopregel komt het lichaam van het probleem. Dit is het langste gedeelte. Het beschrijft
          o de proefondervindelijke achtergrond van het patroon
          o de bewijzen voor haar waarheid
          o het bereik van de verschillende manieren waarop het patroon zich manifesteert in onze omgeving
          o het effect van het probleem op haar omgeving
          o de verschillende relevante krachten die het probleem een specifieke richting op trekken
          o en zo voort.
 
Vervolgens, wederom vetgedrukt, zoals de kopregel, komt de oplossing—het hart van het patroon—die het veld van fysieke en sociale relaties beschrijft die nodig zijn om het probleem op te lossen, in de eerder genoemde context. Deze oplossing wordt altijd in de vorm van een instructie geformuleerd—zodat je precies weet wat je moet doen om het patroon te realiseren. Dan, na de oplossing, toont een diagram de oplossing met labels voor de hoofdcomponenten.
 
Na het diagram volgen wederom drie diamanten om aan te geven dat het lichaam is afgesloten. Tenslotte, na deze drie diamanten, volgt een paragraaf die dit patroon verbindt met alle andere patronen die nodig zijn om dit patroon te vervolmaken, in te vullen, te verfraaien.
 
Er zijn twee essentiële bedoelingen voor dit formaat.
 
    * Ten eerste, om elk patroon verbonden met andere patronen te presenteren, zodat je de verzameling van alle patronen als een geheel, als een taal kan bevatten, waarbinnen je zelf—ook en met name als leek—een oneindige veriëteit van combinaties kan scheppen.
    * Ten tweede, om het probleem en de oplossing van elk patroon zodanig te presenteren dat je het zelf kan beoordelen en wijzigen zonder dat je de essentie kwijtraakt die de kern is van het patroon.

Latest revision as of 22:01, 9 January 2007

Een team wordt bij elkaar gebracht waar mensen elkaar nog niet kennen, en nog maar weinig weten van hetgeen ze realiseren willen, en hoe ze dat willen doen. Bij een samengaan van twee ondernemingen gebeurt het dat uit beide organisatie mensen ingeseind worden om met elkaar te praten en denken over de gezamenlijke toekomst. Ook besluiten mensen in een netwerk om een groepje te vormen, met het idee om gezamenlijk iets te gaan ontwikkelen: een product, een rapport, een voorstel aan een overheid.

Het probleem. Teamleden kennen bij aanvang van een project veelal elkaar's talenten en persoonlijkheden niet. Ook zijn ze onzeker over wat precies de bedoeling is, wat ze met elkaar moeten of willen gaan doen, en hoe dit aan te pakken. Ook speelt een rol dat mensen hun eigen projectspecifieke vaardigheden en rollen vaak nog niet kennen, en niet weten hoe groot en complementair die vaardigheden en rollen zijn ten opzichte van anderen in de groep. tenslotte is onduidelijk wat de waarde is die eenieder ervaart van het werken met de groep, en welke waarde er in totaal uitkomt.

Om met al deze onzekerheden en onduidelijkheden resultaten te bereiken op een manier die prettig is en eenieder eert in zijn of haar waarden en gedrag, is een lekker werkende procesaanpak nodig. Daarover gaat dit patroon.

hoe werkt het?

Het planningsspel voor zelf-organiserende teams kan grotendeels hetzelfde zijn als het planningsspel voor ontwikkelprojecten met dien verstande, dat het zelf-organiserende team afwisselend zowel de rol van klant als de rol van ontwikkelaar speelt. Dit werkt (zelfs in een simulatiespel dat we gebruiken), als iedereen er op alert is - iemand die het planningsspel faciliteert kan daarbij helpen.

De reden dat in het planningsspel voor ontwikkelprojecten de rollen zo strict gescheiden zijn, is dat niet iedereen (in eerste instantie) voldoende distantie kan creeren om zowel moeilijkheid als waarde in te schatten, waardoor bij voorbeeld altijd hetmeest 'interessante' of het moeilijkste werk eerst wordt gedaan, in plaats van het meest waardevolle.

maar dit geheel terzijde

Het grappige is dat door het regelmatig spelen van het planningsspel mensen vanzelf beter worden dingen op waarde te schatten, en plezier gaan beleven aan het opleveren van waarde (in plaats van plezier in 'moeilijke uitdagingen' of 'technisch interessant werk').

Retrieved from "https://wiki.aardrock.com/index.php?title=Planningsspel_voor_zelf-organiserende_teams&oldid=4465"