Jezelf continu ontwikkelen en ondertussen schitteren in jouw vakgebied
Wil jij werken in een organisatie met collega's, die net als jij, passie hebben voor software development en ben je benieuwd welke carrière mogelijkheden er voor jou zijn?
\n
\n
Bij VX Company krijgen we veel unieke en uitdagende aanvragen voor projecten, opdrachten en ander werk. Wij zijn daarom altijd op zoek zijn naar nieuwe getalenteerde en gedreven professionals die teams en organisaties vooruit willen helpen. Bekijk de vacatures en zie waar jij ons team kunt versterken:
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Bij VX Company nemen wij de tijd om de perfecte match voor jou te vinden binnen ons werkveld. Hoe? Lees er alles over in deze blog. ","meta_description_search":"Bij VX Company nemen wij de tijd om de perfecte match voor jou te vinden binnen ons werkveld. Hoe? Lees er alles over in deze blog. ","slug":"https://werkenbij.vxcompany.com/blogs/kennisdag-december-2022","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"Een kennisdag bij VX"},{"header_data":{"excerpt":{"body":{"value":"Bij VX Company nemen wij de tijd om de perfecte match voor jou te vinden binnen ons werkveld. Vastbesloten vinden wij voor iedere collega de beste fit."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"blog_field":52168953593,"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"deleted_at":1668777046633,"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"src":""},"choice_field":"tekst_afbeelding","content":"Hoe detacheren bedrijven en waarom lukt het bij ons wel altijd? We kunnen ons voorstellen dat deze vraag wel eens door je hoofd is gegaan. Je werkt als gedetacheerde developer en hebt al meerdere keren een verkeerde opdracht gehad. Bij VX Company nemen wij de tijd om de perfecte match voor jou te vinden binnen ons werkveld. Vastbesloten vinden wij voor iedere collega de beste fit. Met oog voor de belangen van de klant, van VX Company en van jou, matchen wij je bij de best passende opdracht. Hoe wij dit doen? In deze blog lees je alles over hoe wij detacheren.
\n\n
Detacheren én het werken voor verschillende opdrachtgevers kent meerdere voordelen. Met jouw ambities kan je je namelijk bij diverse opdrachtgevers verder ontwikkelen. Wij kennen onze opdrachtgevers door en door. Wanneer er een klant komt met een specifiek vraagstuk starten wij het traject naar het vinden van de matchende developer. Doordat we in gesprek zijn met de klant begrijpen we de wensen en behoeften van de klant beter. Dit zorgt ervoor dat jij alles uit een relatief korte opdracht kunt halen.
Jouw ambities worden op voorhand besproken. Of dit nou op professioneel vlak of persoonlijk vlak is, door de juiste match te vinden word jij optimaal uitgedaagd. Met al deze kennis weten wij welke opdracht bij jou past en ga jij bovendien aan de slag met uitdagingen die een concrete impact hebben op een organisatie. Door onze grote diversiteit aan opdrachtgevers en opdrachten, is er altijd voldoende speelruimte om ook daadwerkelijke de beste match voor jou te vinden. Jij past dus altijd op een van onze opdrachten én binnen de werksfeer van de opdrachtgever.
\n
Ons detacheringsteam is een goed op elkaar ingespeeld team dat, in combinatie met de juiste kennis, zorgt voor jouw succesvolle match. Wij streven naar een echte connectie tussen jou en de opdracht, waarin we verder kijken dan alleen het commerciële vlak van een opdracht. Want waar de één het contact met de opdrachtgever onderhoudt, is de ander zeer betrokken bij jouw detacheringsproces. Dat maakt dat onze matches 99% van de tijd slagen.
Het is echter niet altijd perfect en detacheringen kunnen helaas wel eens mis gaan. Maar dit houdt ons scherp en zorgt ervoor dat wij leren van ieder project. Door continu te werken aan de verbetering van ons proces, kunnen wij onze opdrachtgevers beter van dienst zijn, en jou een passende match bieden. Bijvoorbeeld het optimaliseren van het Persoonlijk Ontwikkel Plan dat jij aan het begin van je loopbaan invult. We zorgen ervoor dat we jouw ambities nog concreter en tastbaarder maken.
Maar hoe ziet dit proces er dan uit? Doordat onze lijntjes kort zijn, zijn wij van alle ontwikkelingen op de hoogte. Ook wanneer jouw leerproces er bij een huidige opdracht op zit. Op dat moment gaan we samen verder kijken naar nieuwe uitdagingen in jouw werk als software developer.
Door een goede ‘’driehoeksverhouding’’ te hebben tussen de communicatie met ons interne personeel, de professionals en de opdrachtgevers is een geslaagde match vanzelfsprekend haalbaar. Bij ons ben jij geen nummer, maar een echt persoon. Wij leren jou kennen door de persoonlijke gesprekken die we samen zullen voeren aan het begin, maar ook gedurende jouw tijd binnen VX Company. Bij ons doe je meer dan alleen werken. Je krijgt de ruimte om jezelf continu te ontwikkelen en ondertussen te schitteren in jouw vakgebied.
","reverse":false},{"afbeelding":{"alt":"Ouafae-Oueld-Lbenay","height":1442,"max_height":1442,"max_width":2162,"src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Ouafae-Oueld-Lbenay.jpg","width":2162},"choice_field":"tekst_afbeelding","content":"Ouafae Oueld-Lbenay, Senior Test Specialist bij VX Company vertelde in een eerdere blog over haar werk bij VX Company: ‘’Ik ervaar veel vrijheid en de stimulatie om mezelf te blijven ontwikkelen.’’. In haar tijd bij ons heeft ze slechts één keer een opdracht gehad waar zij zich niet op haar plek voelde. Dit eenmaal aangekaart is er binnen no-time geschakeld. Al snel kon zij aan de slag bij een andere opdrachtgever. Wij geloven sterk in onze werkwijze: ‘’Want waar veel bedrijven het beloven, maken wij het echt waar!’’
\n
Benieuwd naar nog meer verhalen? De komende tijd nemen andere professionals en klanten je mee in hun ervaringen bij VX Company.
\n\n
Bij VX Company krijgen we veel unieke en uitdagende aanvragen voor projecten, opdrachten en ander werk. Wij zijn daarom altijd op zoek zijn naar nieuwe getalenteerde en gedreven professionals die teams en organisaties vooruit willen helpen. Bekijk de vacatures en zie waar jij ons team kunt versterken:
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Bij VX Company nemen wij de tijd om de perfecte match voor jou te vinden binnen ons werkveld. Hoe? Lees er alles over in deze blog. ","meta_description_search":"Bij VX Company nemen wij de tijd om de perfecte match voor jou te vinden binnen ons werkveld. Hoe? Lees er alles over in deze blog. ","slug":"https://werkenbij.vxcompany.com/blogs/de-unieke-werkwijze-vx-company","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"De unieke werkwijze van VX Company"},{"header_data":{"excerpt":{"body":{"value":"Developers often write “Selenium tests” which, after a while, become too slow. Let’s look at how to fix that!"},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Developers often write “Selenium tests” which, after a while, become too slow. Let’s look at how to fix that!
\nSelenium is an automated testing framework to test applications via a web browser (see https://www.selenium.dev/). Other forms of automated testing like unit testing only test one part of an application whereas Selenium tests the whole application – frontend and backend combined. This is a great feature because it proves that the application works in the same way that user access it.
\nWith automated tests running as part of a continuous integration environment, stakeholders can be more confident that the application has a high quality with few bugs. More and more automated tests mean fewer manual tests are needed before deploying each release to production, which therefore speeds up the application’s time to production.
\nAt first there are only a few tests.
\nThe picture below shows one block for each test. So here we see three tests running after each other. This works fast because there are only a few tests.
\n![\"Selenium](\"https://vxcompany.com/wp-content/uploads/2021/11/Selenium-tests-afbeelding-1.png\")
Unfortunately, Selenium tests can be slow and as more and more tests are created the test suite takes a long time to run.
\nThis next picture shows many tests running after each other and so taking too much time:
\n![\"Selenium](\"https://vxcompany.com/wp-content/uploads/2021/11/Selenium-tests-afbeelding-2.png\")
Each time a code change is pushed, the developer must wait for the continuous integration environment to run, including the Selenium tests. That can be a long and inefficient wait. So how can we speed up the Selenium test suite?
\nA good way to speed up the Selenium tests is to run then in parallel.
\nThis final picture shows the tests running 4 times in parallel. Now the tests finish nice and fast:
\n![\"Selenium](\"https://vxcompany.com/wp-content/uploads/2021/11/Selenium-tests-afbeelding-3.png\")
Let’s see how to implement that:
\nHints and tips:
\nSelenium tests are a great way to automatically test your application. Unfortunately, they can become too slow. Speed them up by running them in parallel. Problem solved.
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Developers often write “Selenium tests” which, after a while, become too slow. Let’s look at how to fix that!","meta_description_search":"Developers often write “Selenium tests” which, after a while, become too slow. Let’s look at how to fix that!","slug":"https://werkenbij.vxcompany.com/blogs/selenium-tests-in-parallel","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"Selenium tests in parallel"},{"header_data":{"excerpt":{"body":{"value":"Als developer weet je één ding zeker: je moet jezelf altijd blijven ontwikkelen. De veranderingen in het IT-vakgebied gaan namelijk écht sneller dan Usain Bolt op de 100 meter sprint. Goede training is dus cruciaal om bij te blijven. Volg cursussen, sluit aan bij webinars of deel actief kennis met je collega’s. Van die laatste optie is Niek Kuijken, .NET developer bij VX Company, in ieder geval groot fan."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Als developer weet je één ding zeker: je moet jezelf altijd blijven ontwikkelen. De veranderingen in het IT-vakgebied gaan namelijk écht sneller dan Usain Bolt op de 100 meter sprint. Goede training is dus cruciaal om bij te blijven. Volg cursussen, sluit aan bij webinars of deel actief kennis met je collega’s. Van die laatste optie is Niek Kuijken, .NET developer bij VX Company, in ieder geval groot fan.
\n“In de anderhalf jaar dat ik bij deze gespecialiseerde IT-dienstverlener werk, heb ik al meer kennis opgebouwd dan de vijf jaar daarvoor”, vertelt Niek enthousiast. “VX Company is gespecialiseerd in het bouwen van – veelal Enterprise – maatwerk applicaties voor haar klanten. Als developer word je gedetacheerd en zie je dus steeds nieuwe projecten. Heel eerlijk, ik had hier eerst mijn twijfels over, maar die zijn compleet verdwenen. Dat komt met name door de afwisseling. Ik merk dat ik hierdoor zoveel kennis opdoe. Kennis die ik niet alleen voor die specifieke klant gebruik, maar waar ik voor altijd profijt van heb. En als je een opdracht écht niet leuk vindt, kun je altijd samen kijken naar iets wat beter bij je past. Maar dat heb ik zelf nog niet meegemaakt.”
\nVoor zijn eerste project werd Niek ingeschakeld bij de afdeling applicatiebeheer van VX Company zelf. Het doel: een applicatie, die wordt ingezet door iedere afvalverwerker in Nederland, voorzien van een moderne interface en deze tegelijkertijd opknippen in microservices. “Tijdens dit project kreeg mijn kennis over front-end technieken een flinke boost”, deelt Niek. “En in het project daarna leerde ik juist alles over domain-driven design. Ik werkte op die opdracht namelijk samen met een collega VX’er die gespecialiseerd is op dit gebied. Heel waardevol, dankzij deze softwarearchitectuurkeuze worden alle regels vanuit de business geïsoleerd en bewaar je het overzicht. Hierdoor voeg je ook makkelijk nieuwe stukken toe. Een heel verschil met traditionele omgevingen waar het vaak een zoektocht is als je iets moet aanpassen.” Zeker binnen Enterprise omgevingen – waar VX Company haar applicaties voornamelijk in bouwt – is dat geen overbodige luxe. Deze applicaties moeten lang mee en je krijgt dus veel met onderhoud en aanpassingen te maken.
\nDomain-driven design zorgt niet alleen voor overzicht. Het maakt het ook een stuk makkelijker om je aanpassingen te testen. “Testen is altijd een soort ongewild kind geweest”, vertelt Niek lachend. “Ik merk vaak dat men daar als een berg tegenop kijkt. Normaal gesproken houd je je hart vast als je iets nieuws aan een bestaande applicatie toevoegt. Maar door deze designkeuze kun je alle logica testen en zie je direct of je groen licht hebt. Dat is niet alleen leuk, maar ook goed voor het hart. Het mooie is dat ik al deze kennis nu in mijn huidige – en stiekem ook leukste – project kan inzetten.”
\nIn dit project maakt Niek – natuurlijk samen met het projectteam – een applicatie voor een tak van Justitie en Veiligheid. Deze moet op onvoorstelbaar veel situaties voorbereid zijn. Denk aan allerlei soorten zaken die met verschillende nationale en internationale regelgeving te maken hebben. “Het is dus cruciaal dat de applicatie configureerbaar is”, legt Niek uit. “Dat is ook gelijk de moeilijkheid. We moeten ontzettend veel flexibiliteit faciliteren en tegelijkertijd zorgen dat het geheel testbaar en onderhoudbaar is. De klant moet hier natuurlijk nog jaren mee vooruit.” De applicatie wordt from scratch gebouwd, dus de beginkeuzes zijn cruciaal. Samen met het team koos Niek ervoor om dit te bouwen met een Angular front-end en een .NET Core back-end. Uiteraard gooide hij ook zijn nieuwe domain-driven design skills in de mix.
\n“Het project is nog niet klaar, maar het is mooi om te zien dat alle kennis die ik in de eerdere projecten opdeed hier weer terugkomt,” vertelt Niek enthousiast. “Eerder werkte ik bij een bedrijf met één product op de lijn. Dan ben je toch beperkt in de technieken die je gebruikt. Hier leer je zoveel van de projecten en je collega’s. Je ziet ook dat veel VX’ers hier al jaren werken, juist omdat ze zoveel verschillende projecten zien en continu nieuwe kennis opdoen. Daarnaast heb je óók nog een personal development plan, zo ben ik zelf ik bezig mijn Azure Developer certificaat te behalen. Alle ruimte voor training en ontwikkeling dus. Voor mij is dat VX Company.”
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Als developer weet je één ding zeker: je moet jezelf altijd blijven ontwikkelen. De veranderingen in IT gaan écht sneller dan Usain Bolt op de 100 meter. ","meta_description_search":"Als developer weet je één ding zeker: je moet jezelf altijd blijven ontwikkelen. De veranderingen in IT gaan écht sneller dan Usain Bolt op de 100 meter. ","slug":"https://werkenbij.vxcompany.com/blogs/overeenkomst-tussen-usain-bolt-en-developer","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"De overeenkomst tussen Usain Bolt en een developer?"},{"header_data":{"excerpt":{"body":{"value":"This is a blog series about functional programming with Elm. Setting up an development environment with Elm and electron should not be to difficult, but was it?"},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"deleted_at":1665412419132,"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"This is a blog series about functional programming with Elm. Setting up an development environment with Elm and electron should not be to difficult, but was it?
\nI’m a Software Engineer for a long time and have been programming in an Object Oriented way my whole career, mostly in Java. I like discovering new things and for a time that was mostly Java related. But while there was a lot of development around Java (not much in the language itself), it felt like more of the same. A new library here and there but mostly on known concepts. When I learned to program for the frontend, a whole new world opened. It felt like Java in the early days. Lots of frameworks and libraries popping up, great.
\nLots of these new frameworks and libraries were about functional programming. Even Java received functional programming features. They were easy to use, albeit in a different way. It peaked my interest, what is that, real functional programming? By the way it is not a new concept. it exists for a long time, but somehow it is popping up everywhere. So I wanted to do functional programming. But where and in what language? I could go for the backend (there are multiple candidates, like frege and eta), but I choose the frontend, because I needed a more stable framework/language.
\nElm is a functional programming language for frontend. Or as they say on the website, ‘A delightful language for reliable webapps.’ The most important features are ‘No runtime exceptions’, ‘Great performance’, ‘Enforced semantic versioning’, ‘Small assets’, and ‘Javascript interop’. It compiles to Javascript.
\nI looked on the web for combinations of electron and Elm and found ‘Elm electron webpack’. So I forked it and cloned the git repository. It was more a guide than a ready to use template. And that was a good thing. It started simple, using only electron. Then mixing in Elm and finally webpack.
\nElectron
Getting electron up and working was very simple. In the index.html add or remove some text to see something else. Then fire up electron main.js (or npx electron main.js if you installed it locally) and a window with the text and title should show up. A good start.
Bringing Elm into the fold
The Elm part was also no problem, the guide use Elm 0.18 and I had already installed Elm 0.19. But that was not a problem, because it does not use very much of Elm. The guide let’s you build the Elm bundle before changing the elm.json file, so it is possible that when you execute.
Nothing is produced and an error is shown:
","reverse":false},{"afbeelding":{"alt":"2022-09-06_10h00_21","height":335,"loading":"lazy","max_height":335,"max_width":585,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_10h00_21.png","width":585},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"So apply the change that is posted later in the guide, update the elm.json file to find your Elm files.
","reverse":false},{"afbeelding":{"alt":"2022-09-06_10h01_07","height":52,"loading":"lazy","max_height":52,"max_width":589,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_10h01_07.png","width":589},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Then fire up ‘electron main.js’ and it should work. Except it didn’t. There was a browser error:
","reverse":false},{"afbeelding":{"alt":"2022-09-06_10h01_49","height":38,"loading":"lazy","max_height":38,"max_width":586,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_10h01_49.png","width":586},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"This is because of a later version of electron is used compared to the guide. The new version separates the browser process from the node process.
\nA fix is to use the config option ‘contextIsolation: false’ in the ‘webPreferences’ part of ‘new BrowserWindow’ options. It does make electron less safe, because the client and server part are in the same context now.
","reverse":false},{"afbeelding":{"alt":"2022-09-06_10h02_47","height":127,"loading":"lazy","max_height":127,"max_width":586,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_10h02_47.png","width":586},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Now we can develop an application with Elm and electron. Use:
\n![\"2022-09-06_10h04_27\"](\"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_10h04_27.png\")
to enhance the app and
\n![\"2022-09-06_10h05_06\"](\"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_10h05_06.png\")
to check it in electron.
\nTo make life easier there are scripts for npm in the package.json file.
\nTo start the elm reactor and launch a webbrowser (firefox) on http://localhost:8000
\n![\"2022-09-06_10h06_03\"](\"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_10h06_03.png\")
PS: This might not work on Windows, because of the chaining of commands
\nTo build Elm and start electron:
\n![\"2022-09-06_10h06_51\"](\"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_10h06_51.png\")
PS: This might not work on Windows.
\nTo start Elm reactor without opening a browser window
\n![\"2022-09-06_10h07_37\"](\"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_10h07_37.png\")
To build Elm
\n![\"2022-09-06_10h08_15\"](\"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_10h08_15.png\")
To start electron without building Elm
\n![\"2022-09-06_10h08_50\"](\"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_10h08_50.png\")
I am glad that in the end I got it working with Elm 0.19 and electron. The guide helped me a lot to understand all the moving parts. In the next parts we can start building an application.
\nThe original guide included webpack. The version of webpack used was version 1. The Elm-loader for webpack version 1 does not support Elm 0.19. Since I wanted to use the latest version of Elm this was not an option. I tried to make it work with the latest version of webpack, but this was not a simple task. (If you want to see the attempt), but not a successful one. But since this is about Elm and not webpack, this is not a big problem.
\n","reverse":false}],"module_id":52218371028,"richtext_field":"
fdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"This is a blog about functional programming with Elm. Setting up an development environment with Elm and electron should not be to difficult, but was it?","meta_description_search":"This is a blog about functional programming with Elm. Setting up an development environment with Elm and electron should not be to difficult, but was it?","slug":"https://werkenbij.vxcompany.com/blogs/programming-with-elm","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"Programming with Elm: how difficult can it be?"},{"header_data":{"excerpt":{"body":{"value":"Learning by doing, teaching by sharing. Like most software services companies we have the regular meetups, webinars, blogposts, etc. We wanted to create a common theme for these events, an app that we could use in all our demos and articles. A bit like what Microsoft did with Wingtip Toys or Contoso Inc. (Contoso), but a lot simpler and smaller of course."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Learning by doing, teaching by sharing. Like most software services companies we have the regular meetups, webinars, blogposts, etc. We wanted to create a common theme for these events, an app that we could use in all our demos and articles. A bit like what Microsoft did with Wingtip Toys or Contoso Inc. (Contoso), but a lot simpler and smaller of course.
\nSo the project started as an idea for our meetup content and a nice looking demo app (no more “Hello World!”). As we were designing the demos, we acknowledged a common struggle: there is so much content for software people out there, how do we manage it all? Avoid “content overload” and still keep on learing? We decided to build a real app instead of a fictional one….. meet Amped: “Your connection to curated content”.
\n![\"\"](\"https://vxcompany.com/wp-content/uploads/2021/11/blog-building-the-next-killer-app-what-does-it-do-1024x402.png\")
Amped tries to provide a couple of things:
\nSo far, there is just the idea and a list of a couple of fundamental requirements. No software has been written yet, as we aim to document and share the entire process: learning by doing, teaching by sharing.
\nWe like demos. And we do not want to create another ToDo App.
\nWe aim to share the entire process, not only the code. So our content starts with documenting stakeholder mappings, creating personas, design discussions, etc. and eventually we will add the first lines of code (we are actually sitting on our hands now, we can’t wait to start coding).
\nThe GitHub readme contains a content list and schedule. Check it out if you want to read up on how we create the next “killer” app 😉
\nSharing is caring, right? Amped is capable of curating all types of content, not just tech related. It is totally up to you if you want to run your own instance and catalogue things like recipes, books, travel locations, etc. This project is OSS, MIT licensed so you can pretty much do with it as you please.
\nMaybe, who knows. It would be cool though. We welcome contributions and a guide is coming soon.
\nA real app we will develop and use ourselves. Our instance of the app will be targeted add the tech community and will be available at: https://totallyamped.tech once we have the first bits ready!
\nCheckout our GitHub repo for more information: https://github.com/VXCompany/amped
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Learning by doing, teaching by sharing. We wanted to create a common theme for events, an app that we could use in all our demos and articles. ","meta_description_search":"Learning by doing, teaching by sharing. We wanted to create a common theme for events, an app that we could use in all our demos and articles. ","slug":"https://werkenbij.vxcompany.com/blogs/building-the-next-killer-app","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"Building the next killer app"},{"header_data":{"excerpt":{"body":{"value":"Vandaag de dag wordt software zelden nog gemaakt door één enkele ontwikkelaar. Eigenlijk zien we vooral meerdere teams samenwerken aan applicaties en oplossingen. Hierbij is feedback van het grootste belang: het laat ontwikkelaars zien, dat de software op een bepaalde manier correct werkt. Het vertelt of de code qua syntax correct is (‘it builds!’), maar ook dat vitale onderdelen nog steeds werken zoals bedoeld is (de ‘unit tests’ slagen!) en dat de wijzigingen van individuele ontwikkelaars elkaar niet in de weg zitten. In dit artikel kijken we naar wat we allemaal aan terugkoppeling kunnen organiseren en op welke manier dat kan bijdragen aan betere software!"},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Vandaag de dag wordt software zelden nog gemaakt door één enkele ontwikkelaar. Eigenlijk zien we vooral meerdere teams samenwerken aan applicaties en oplossingen. Hierbij is feedback van het grootste belang: het laat ontwikkelaars zien, dat de software op een bepaalde manier correct werkt. Het vertelt of de code qua syntax correct is (‘it builds!’), maar ook dat vitale onderdelen nog steeds werken zoals bedoeld is (de ‘unit tests’ slagen!) en dat de wijzigingen van individuele ontwikkelaars elkaar niet in de weg zitten. In dit artikel kijken we naar wat we allemaal aan terugkoppeling kunnen organiseren en op welke manier dat kan bijdragen aan betere software!
\nWe gaan er bij softwareontwikkeling eigenlijk altijd van uit, dat er drie verschillende processen voor terugkoppeling zijn. Deze zogeheten ‘feedback loops’ verschillen niet alleen in detail maar vooral ook in de snelheid waarin ze de informatie aan de ontwikkelaar terugkoppelen. Laten we eerst kijken naar de terugkoppeling, die de meeste ontwikkelaars wel zullen herkennen. Ik noem dit de ‘Inner Feedback Loop’. Deze feedback loop is bijzonder belangrijk, omdat deze terugkoppeling geeft op de code die zojuist door de ontwikkelaar is geschreven. Dit betekent, dat de ontwikkelaar nog niet naar een andere context is geschakeld en de zojuist ingediende code nog vers in het geheugen heeft. In één van mijn favoriete podcasts (.NET Rocks) komt het regelmatig langs: “Feedback should be there before the Developer returns from the coffee machine!”. In de praktijk zou dat dus binnen 15 minuten moeten zijn!
","reverse":true},{"afbeelding":{"alt":"Continu-feedback-768x220","height":220,"loading":"lazy","max_height":220,"max_width":768,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Continu-feedback-768x220.png","width":768},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Dit type terugkoppeling is dus vrijwel direct. Normaal gesproken begint dit al in ontwikkelomgeving lokaal, de IDE (‘Integrated Development Environment’). De meeste van deze IDE’s hebben manieren om ontwikkelaars te informeren hoe het staat met de code terwijl deze wordt geschreven: in de vorm van rode kringellijntjes die aangeven of de code fout of verdacht is. Op de achtergrond is de compiler bezig met het compileren van de code en voert de unit tests uit. Vooral deze testen laten bijna in real-time zien of de code ernstige gebreken bevat. Dit speelt zich nog allemaal af op de lokale machine van de ontwikkelaar, maar zoals we al eerder gezegd hebben: software wordt tegenwoordig nog maar zelden door één ontwikkelaar gemaakt.
\nWanneer de ontwikkelaar zijn code af heeft, worden de wijzigingen doorgegeven aan de centrale repository. Op dat moment kunnen een hoop verschillende checks plaatsvinden:
\nTegenwoordig gebruiken de meeste teams een 2-staps proces: als eerste dient een ontwikkelaar de wijzigingen in en verpakt deze in een zogeheten ‘Pull Request’. Dit wordt gevalideerd: deels automatisch met behulp van bovengenoemde checks en deels handmatig in de form van een ‘Code Review’. Als de code slaagt voor deze checks, dan wordt ze samengevoegd met de ’main codebase’ of hoofdcode (een samenstelling van alle eerder gemaakte en gevalideerde code). Dit is tevens de start van de tweede terugkoppeling.
\nIn het ideale geval start deze terugkoppeling direct nadat de ingediende code is geïntegreerd met de rest van de code. Normaal gesproken wordt er vanuit deze codebase, direct een versie uitgerold op een omgeving. Maar voordat we uitrollen herhalen we een aantal checks en voeren we een aantal nieuwe checks uit. Het verschil is dat we dit nu doen op de gehele codebase en niet slechts op de ingediende wijzigingen. Dit betekent wel dat deze checks over het algemeen langer lopen en dus meer tijd kosten, maar ook dat we meer/uitgebreidere testen kunnen doen:
\nDit proces loopt een stuk langer vergeleken met de eerste loop, maar verzamelt ook gegevens in meer detail. Toch mag je verwachten dat deze terugkoppeling snel komt. Vooral om ervoor te zorgen dat ontwikkelaars zo min mogelijk verstoord worden, ze zijn immers al aan nieuw/ander werk begonnen. In geautomatiseerde systemen zou je dit soort testen dus het liefst niet in de nacht of wekelijks willen doen, maar direct nadat de wijzigingen aan de hoofdcode zijn toegevoegd. Op die manier kunnen we bevindingen direct terugkoppelen, misschien zelfs via een Slack of Microsoft Teams Channel!
\nDit is feedback die we niet direct het team in gooien. Denk aan bevindingen uit ‘Gebruikers Acceptatie Testen’ of foutenmeldingen uit logfiles op productie. In dergelijke gevallen is meestal een vorm van onderzoek of triage nodig en om die reden meer geschikt voor ticket- of bugtracking systemen. En voor feedback waar snel op gehandeld moet worden, denk dan aan ‘emergency hotfixes’, e.d.? Daar kun je het beste een apart proces voor inrichten, want die moeten normaal gesproken zo snel mogelijk door het team opgepakt kunnen worden.
\nIn deze loop vind je dus zaken als:
\nAls we de drie feedback loops aan elkaar koppelen krijgen we een reeks aan stappen die bestaan uit de checks en validaties. Als we de stappen uit deze reeks willen automatiseren komen we in de meeste gevallen al snel uit bij een zogeheten “Continuous Integration / Continuous Deployment” pipeline.
\nIn de meest eenvoudige vorm geeft CI/CD je controle over de voortbrenging van software door geautomatiseerde stappen. Continuous Integration is het mechanisme waarbij je het werk van individuele ontwikkelaars samenvoegt in de hoofdcode. Je zorgt er dus voor dat de losse wijzigingen goed samenwerken met elkaar én met het werk dat al eerder is gedaan. Continuous Deployment neemt deze wijzigingen zo vaak als nodig uit de hoofdcode en rolt deze direct uit op een (productie) omgeving. Om uit de hele keten de feedback te organiseren (en standaardiseren) kunnen we daarnaast gebruik maken van iets wat ‘Continuous Testing’ heet.
\nLaten we kijken naar een voorbeeld waarin het allemaal samenkomt. Het volgende diagram toont een CI/CD pipeline waarin een aantal van de checks en tests zitten die in dit artikel langs zijn gekomen. Hoewel het hier een versimpelde versie betreft van een echte pipeline (te weten van Amped, een Open Source project), zit er toch al aardig wat in. Het zal ook zeker niet op alle situaties van toepassing zijn, maar het toont wel hoe de drie typen feedback samenwerken om waardevolle terugkoppeling te verzamelen.
","reverse":false},{"afbeelding":{"alt":"continuous-1","height":835,"loading":"lazy","max_height":835,"max_width":1793,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/continuous-1.jpg","width":1793},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Omdat we, vooral bij de eerste twee feedback loops, zo min mogelijk tijd willen verliezen maken we in dergelijke pipelines in hoge mate gebruik van geautomatiseerde stappen. In dit getoonde diagram zit ook maar één handmatige stap (de ‘Code Review’) op de weg naar de productieomgeving! Deze methodiek kennen we als Continuous Testing, soms ook wel Agile Testing genoemd. Het beschrijft het proces van het uitvoeren van geautomatiseerde testen als onderdeel van de software delivery pipeline om feedback te krijgen op de risico’s van een bepaalde software release. Met andere woorden: wat zijn de (bedrijfs)risico’s van de software die je uitrolt op productie.
\nDe naam is overigens verwarrend, want met Continuous Testing wordt niet bedoelt dat we de hele tijd testen… het betekent vooral dat we in elke fase van het software delivery proces testen hebben zitten die bepaalde risico’s in kaart brengen. Omdat wij toch terugkoppeling willen in elke fase van het proces is dit een mooie methodiek om onze drie feedback loops in onder te brengen!
","reverse":false}],"module_id":52218371028,"richtext_field":"fdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Software wordt zelden gemaakt door één ontwikkelaar. Deze blog beschrijft wat we aan feedback kunnen organiseren en hoe dat bijdraagt aan betere software!","meta_description_search":"Software wordt zelden gemaakt door één ontwikkelaar. Deze blog beschrijft wat we aan feedback kunnen organiseren en hoe dat bijdraagt aan betere software!","slug":"https://werkenbij.vxcompany.com/blogs/continu-feedback","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"Continu feedback"},{"header_data":{"excerpt":{"body":{"value":"Of het nu gaat om kleine of grote systemen, ik vind het fijn om veilige software te bouwen. Ik weet, dat ik daarin niet alleen ben. Sterker nog, ik durf wel te stellen dat iedereen veilige software wil maken. Hoewel ik dat al best een tijdje doe (software bouwen in het algemeen bedoel ik dan), vind ik het ook nog steeds lastig in een paar zinnen te beschrijven wat dat dan is… veilige software. Als het al zou lukken, dan is zo’n beschrijving ook weer niet eeuwig houdbaar. Zeker in de IT geldt: wat vandaag als definitie wordt aangenomen, kan morgen weer achterhaald zijn. Wat dat betreft had de oude Griek Heraclitus wel gelijk: ‘verandering is de enige constante’. Voor mij is dat misschien ook waarom software bouwen zo interessant blijft."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Of het nu gaat om kleine of grote systemen, ik vind het fijn om veilige software te bouwen. Ik weet, dat ik daarin niet alleen ben. Sterker nog, ik durf wel te stellen dat iedereen veilige software wil maken. Hoewel ik dat al best een tijdje doe (software bouwen in het algemeen bedoel ik dan), vind ik het ook nog steeds lastig in een paar zinnen te beschrijven wat dat dan is… veilige software. Als het al zou lukken, dan is zo’n beschrijving ook weer niet eeuwig houdbaar. Zeker in de IT geldt: wat vandaag als definitie wordt aangenomen, kan morgen weer achterhaald zijn. Wat dat betreft had de oude Griek Heraclitus wel gelijk: ‘verandering is de enige constante’. Voor mij is dat misschien ook waarom software bouwen zo interessant blijft.
\nDus een beschrijving of definitie geven van veilige software is ingewikkeld, maar is het ook lastig om te ‘doen’? Het antwoord is, net als zo vaak in de IT: ‘dat hangt ervan af’. Als je veilige software ziet als iets dat je éénmalig ontwerpt en realiseert, ja dan is het heel lastig. Als je daarentegen veilige software ziet als een bewegend doelwit en je processen zijn zo ingericht dat daar rekening mee gehouden wordt… en je steeds leert en verbetert… dan valt het wel mee. Begin met de basis, het fundament. Benut wat je nu weet van de omgeving, het gebruik en de gestelde eisen. Haal vervolgens tijdens het bouwen van de software steeds zoveel mogelijk informatie op (denk aan risico modellen, privacy eisen, informatiebeleid, etc.). Bouw door op wat je hebt: software beveiligen gebeurt door maatregelen in ‘laagjes’ op elkaar te stapelen.
\nHet sleutelwoord in de vorige paragraaf is wat mij betreft: ‘steeds’. Dit is dus niet iets wat je één keer moet doen, maar wat je regelmatig terug laat komen. Ik voeg dus graag (en met regelmaat) op basis van nieuwe ideeën en inzichten zaken toe, waarbij ik functionaliteit en beheersbaarheid natuurlijk niet uit het oog verlies. In dit artikel wil ik enkele van die ideeën benoemen, vooral de wat recentere. Sommige zijn in mijn eigen teams ontstaan terwijl andere weer uit de vakliteratuur komen.
\n\n
Vroeger was het leven simpeler, het IT leven dan. Ik denk nog even terug aan de tijd dat software veiligheid nog gelijkstond aan het installeren van firewalls (‘we maken een DMZ!’) en het laten uitvoeren van een penetratietest door een extern bureau. We zagen in die tijd software veiligheid als een zogeheten ‘Gate’. Kwam je daar doorheen, dan was je software veilig. De vergelijking ligt voor de hand, dus ik maak hem maar: de ‘Security Check’ op de luchthaven. Dit was oorspronkelijk alleen een ticket controle op de runway, net voor het instappen. Tegenwoordig is dat het gelaagde model, dat we allemaal wel kennen. Verschillende checks en validaties zorgen ‘in laagjes’ voor de veiligheid van toestellen, luchthaven en passagiers. En we zien nog maar een klein deel, want achter de schermen vindt geautomatiseerd nog een veelvoud van controles plaats.
\nDit is misschien wel de grootste verandering die we op dit thema in de jaren hebben moeten maken. Daar waar we vroeger gewend waren software achteraf te toetsen en te beveiligen, is het nu een onderdeel van elke fase in het leven van een product of dienst. Van ontwerp tot realisatie, elke iteratie weer.
\nLaagjes dus. Voor we hier naar gaan kijken wil ik het nog hebben over het doel van dit alles. Natuurlijk willen we veilige software, maar omdat de echte definitie lastig te geven is neem ik een uitgangspunt.
\n\n
\n
Niets mis mee wat mij betreft, maar dit geeft wel aanleiding om het te hebben over het volgende. Om te kunnen werken aan veilige software heb je mensen nodig die zich doordrongen zijn van deze risico’s. Ik bedoel hier niet per se ‘van de hoed en de rand’, maar wel het besef dat elke wijziging of feature nieuwe kwetsbaarheden kan introduceren. Ik heb het ook niet alleen over ontwikkelaars, want het gaat hier duidelijk om alle betrokkenen. Dus ook een Product Owner of een Business Process Owner. We noemen dit ook wel de security cultuur of veiligheidsklimaat. Er moet in een organisatie voldoende ruimte, aandacht en budget zijn om continu te werken aan veilige software.
\nWat mij betreft niet eens echt een laagje, eerder het fundamentele concept waarop de laagjes steunen. De term ‘Shift Left’ komt uit de hoek van het software testen. In het kort betekent het, dat we testen niet meer aan het eind doen (als een soort Quality Gate), maar integraal onderdeel maken van elke fase in de software ontwikkeling. Dit doen we net zo met software security activiteiten en maatregelen: we schuiven ze zogezegd dus naar links:
\n![\"\"](\"https://vxcompany.com/wp-content/uploads/2022/02/Shift-left.png\" "\\"shift-left\\"")
De ‘software security’ komt niet langer meer pas aan het eind van een proces ter sprake, maar is een onderdeel van elk van de fasen!
\nIn de requirements fase van een feature maak ik graag gebruik van persona’s. Dit zijn gedetailleerde, omschrijvingen van de personen die het product gaan gebruiken. Hoewel ze fictief zijn, creëer je hiermee toch een vorm van echtheid. Het is nu eenmaal makkelijker om ons te verplaatsen in mensen dan in doelgroepen of ‘’target audiences’’. De insteek van deze persona’s is vaak functioneel, maar ze kunnen ook gebruikt worden om (vanuit het functionele vertrekpunt) een beeld te krijgen van de autorisaties die nodig zijn.
\n![\"\"](\"https://vxcompany.com/wp-content/uploads/2022/02/Shelly-the-sharer.png\" "\\"shelly")
Neem bovenstaand persona van een applicatie genaamd ‘Amped’. Als we hier autorisaties uit gaan halen, doen we dat het beste in de vorm van Business Rules:
\nBezoekers van de applicatie Amped (‘Shelly the Sharer’) moeten
\nDit is natuurlijk maar een eenvoudig voorbeeld, maar je ziet al wel dat dit makkelijker te communiceren is dan bijvoorbeeld een ingewikkelde autorisatiematrix in Microsoft Excel!
\nGewone ‘User Stories’ kennen we wel natuurlijk: de korte beschrijvende verhaaltjes vanuit het oogpunt van de gebruiker om duidelijk te maken (of krijgen) wat deze nodig heeft of wil. Met vaak als doel dit uiteindelijk met een ontwikkelteam te realiseren. Je kunt ditzelfde systeem ook gebruiken om met het team vanuit een kwaadwillende gebruiker te denken en zo een ‘Evil User Story’ op te stellen. Ik merk vaak, dat dit in het begin wat lastig en onwennig is. Echter na een paar sprints komen de ‘goede’ ideeën meestal vanzelf! Bijkomend voordeel: afgeronde Evil User Stories kun je af en toe doorspitten en ze opnieuw in een sprint zetten.
\n![\"\"](\"https://vxcompany.com/wp-content/uploads/2022/02/Evil-user-stories-300x164.png\" "\\"evil")
Je kunt de Evil User Stories behandelen als normale User Stories en ze door teamleden laten oppakken. Er zijn echter ook andere methoden om hier mee aan de slag te gaan, bijvoorbeeld met iets als ‘Mob Testing’. Deze methode gaat als volgt: het hele team werkt aan dezelfde Evil User Story, op dezelfde locatie, samenwerkend achter één computer. Eén teamlid zit achter het toetsenbord (de ‘Driver’), één teamlid geeft de aanwijzingen (dat is de ‘Navigator’) en de rest (de menigte, oftewel de ‘mob’) kijkt mee en stelt vragen of maakt opmerkingen. Dit is een variant op Mob Programming, maar bij testen werkt het ook.
\nTwee onderwerpen samengepakt en niet de kleinste wat mij betreft. Gek gezegd: op elk van deze onderwerpen kun je afstuderen. Net als met de andere onderwerpen in dit artikel gaat het er niet om ze in volledigheid te behandelen. Weten dat ‘iets’ bestaat en hoe je er mee zou kunnen beginnen is een eerste stap.
\n![\"\"](\"https://vxcompany.com/wp-content/uploads/2022/02/Security-by-design.png\" "\\"security")
Security en Privacy by Design gaat over het nemen van maatregelen vanaf het begin, nog voor dat de eerste regel code is geschreven. Het staat daarmee dus recht tegenover de security testen e.d. die we vroeger helemaal aan het eind van de lifecycle deden. Als voorbeeld eerder gaven we de pen-test, die als een soort Quality Gate net voor de productiegang wordt uitgevoerd. Het is daarnaast iets wat continu in de levensloop van een product of dienst van toepassing blijft. Elke sprint, elke review, elke release. Zelfs bij het afdanken van het product speelt dit een rol.
\nBij deze twee onderwerpen begint het met ‘awareness’. Zorg dat alle betrokkenen (business-, process- en product owners) op de hoogte zijn en blijven van de noodzaak van veilige software. Gezond verstand is hierbij belangrijk, maar ook bijblijven in de vorm van regelmatige trainingen omdat inzichten steeds veranderen. Enkele maatregelen:
\nSecurity en privacy liggen wat mij betreft in elkaars verlengde: veel van onze maatregelen beschermen zowel de software als haar gegevens. Daarbij worden de kwetsbaarheden waarbij persoonsgegevens openbaar zouden kunnen worden vaak als het meest ernstig ervaren.
\nDe software die ik en mijn teams maak is al lang niet meer helemaal van ons. Ze bestaan voor een deel uit frameworks, tools, packages, dependencies, plugins…. Deze componenten zijn in de meeste gevallen Open Source projecten van derden en vallen daarmee buiten scope van Code Reviews en dergelijke. Wanneer er dus kwetsbaarheden optreden in dat deel van de software, lopen we het risico hier te laat -of geheel niet- achter te komen.
\nEen passende oplossing kan zijn om de gebruikte componenten te analyseren en tegen een openbare database van geregistreerde kwetsbaarheden aan te houden. Hiermee kun je op verschillende momenten in de software lifecycle bepalen of er een verhoogd risico is. Ik noem hier als voorbeeld Dependency Track van OWASP. Dit is een tool, die op basis van de ‘Bill of Material’ bepaalt welke componenten gebruikt worden en gebruikt de National Vulnerability Database om deze te scannen.
\nDe software development lifecycle (de SDLC) is een belangrijk mechanisme als het om veiligheid gaat. Het is het proces wat bij het maken en uitbreiden van software steeds doorlopen wordt. Daarmee is het ook het proces waarin al onze inspanningen (ook als het gaat om security) terug te vinden zijn. Neem bijvoorbeeld een Continuous Integration & Continuous Deployment pipeline. De plek waar wijzigingen van ontwikkelaars worden samengevoegd en (na de juiste checks) worden uitgerold op een omgeving. In dit CI/CD proces is feedback ongelooflijk belangrijk! Het vertelt of de code qua syntax correct is (‘it builds!’), maar ook dat vitale onderdelen nog steeds werken zoals bedoeld is (de ‘unit tests’ slagen!) èn dat de wijzigingen van individuele ontwikkelaars elkaar niet in de weg zitten.
\nIk stelde al eerder, dat er bij het ontwikkelen van software altijd risico’s ontstaan. Niet al deze risico’s zijn vooraf in te schatten en we moeten desondanks snel kunnen reageren met maatregelen. De SDLC moet dus ook ‘voorzien in het onvoorziene’. Ik denk daarom vooral aan automatische validaties, maar ook aan het ‘in place’ hebben van draaiboek voor het geval er iets misgaat ondanks alle maatregelen.
\nDit zijn op zichzelf kleine toevoegingen. Het echte (lees: meeste) werk zit hem vaak in het introduceren en onderhouden van de eerder genoemde security cultuur of veiligheidsklimaat. Dit gaat niet in één dag en is na de implementatie ook niet klaar. Je moet hier continu met alle betrokkenen aan werken. Ook bestaat 100% veilige software niet en er zullen altijd afwegingen moeten worden gemaakt waar (en tegen welke kosten) de grootste security winst te halen is.
\nMeer weten over hoe je een ontwikkelorganisatie zover krijgt? Of hoe je de juiste balans vindt tussen risico en zekerheid? Neem dan contact op met VX Company.
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Iedereen wil veilige software maken. Hoewel ik dat al een tijd doe, is het nog steeds lastig kort te beschrijven wat dat dan is… veilige software. ","meta_description_search":"Iedereen wil veilige software maken. Hoewel ik dat al een tijd doe, is het nog steeds lastig kort te beschrijven wat dat dan is… veilige software. ","slug":"https://werkenbij.vxcompany.com/blogs/veilige-software-bouwen","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"Veilige software bouwen"},{"header_data":{"excerpt":{"body":{"value":"Blijven leren en groeien zijn belangrijke aspecten binnen onze organisatie. Als IT-dienstverlener moeten we ons vakgebied in de gaten houden en voortdurend onze kennis en kunde ontwikkelen. Bij Software Development zorgen we daarom voor een cultuur waarbij het normaal is dat medewerkers onderling informatie, kennis en ervaringen delen. Het gaat daarbij om veel meer dan alleen maar de technische kant!"},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Toch is ‘kennis delen’ zeker niet iets wat je ‘aan’ kunt zetten. Het gaat niet vanzelf en vraagt eigenlijk altijd om nieuwe ideeën en initiatieven. We werken daarom aan een breed programma, experimenteren veel en vragen voortdurend om feedback. Zo zorgen we ervoor, dat er genoeg ruimte is om kennis te halen én te brengen! Een overzicht:
\nVrijwel iedere organisatie heeft ze en bij ons heten het Professional Meetings, kortweg PM’s. Toch doen we het net even anders en zijn het geen saaie presentaties van bedrijfscijfers. We delen bedrijfsupdates en belangrijk nieuws uit de markt en voorzien daarmee in de behoefte voor de professionals om geïnformeerd te blijven. Je krijgt iets mee van de strategie van het bedrijf en hoe het gaat met de klanten en de markt. De meetings zijn interactief, dus meedenken en vragenstellen is helemaal prima. Daarnaast is het ook een moment om elkaar weer even te zien en er is ruimte voor ontspanning in de vorm van een spel of quiz.
\nNa de PM’s volgen enkele tracks, die door medewerkers meestal gebruikt worden om te vertellen over de ervaringen in een project of bij de klant. Hierbij gaat het vooral om de persoonlijke kant in het verhaal en wat minder op de techniek of de oplossingen.
\nVooral in deze tijd waarbij iedereen thuiswerkt is bijpraten lastiger. We komen elkaar bij de klant of op kantoor vrijwel niet tegen. Aan het eind van onze PM’s organiseren we daarom een virtuele chatroom en is er ruimte voor digitale gezelligheid.
\nTalenten ontwikkelen en blijven groeien is voor mij altijd één van de leukste aspecten aan ons vak geweest. De markt verandert en klanten veranderen mee waardoor je regelmatig voor mooie nieuwe uitdagingen komt te staan. Als IT-professional probeer je daarom bij te blijven en te kijken hoe je de juiste kennis en ervaring kunt opdoen. Je ambitie is hierbij natuurlijk een belangrijke leidraad.
\nWe ontwikkelden daarom een online studiegids: een plek waar medewerkers een integraal overzicht kunnen krijgen van de studiegroepen, trainingen en workshops. De inhoud van de studiegids stemmen we gezamenlijk af. En is dus eigenlijk qua onderwerpen niet beperkt tot een bepaald thema, techniek of onderwerp. Ook collega’s uit andere bedrijfsonderdelen sluiten regelmatig aan.
\nEén van de laatste ontwikkelingen is, dat we een aantal workshops opengezet hebben voor klanten en dat we dus nu kennisdelen samen met én voor de klant!
\nNaast de interne studiegroepen en workshops maken we gebruik van een online leerplatform. Naar aanleiding van gesprekken die mijn collega’s en ik met elkaar hebben, kijken we samen of we op ons leerplatform geschikte videotrainingen beschikbaar zijn. Deze zetten we in leerpaden klaar voor andere collega’s. Daarnaast doen we elkaar aanbevelingen als een training goed bevalt.
\nVoor corona hadden we regelmatig een VXperience dag: een groot eigen kennisevenement dat één keer per jaar georganiseerd werd. Zeker nu in deze tijd kijken we of we dit weer fysiek kunnen organiseren.
\nVooral in het begin waren de online sessies en studiegroepen populair en goed bezocht. We zien nu (na ruim een jaar), dat de animo terugloopt en dat we daarom op zoek moeten naar andere vormen en manieren om kennis te delen. We experimenteren bijvoorbeeld met het gebruik van moderators die de groepen in goede banen leiden en aan het inzetten van draaiboeken en regie. Ook zetten we in op een hybride vorm waarbij we deelnemers thuis en op kantoor zullen gaan verbinden!
\nWe gaan straks weer deels terug naar het eigen kantoor of het kantoor van de klant. Wij hebben bij VX Company het streven dit zoveel mogelijk in overleg met onze medewerkers te doen. Niet iedereen wil weer fulltime op kantoor werken. Vooral een ‘zebra schema’ lijkt gewenst (ma-wo-vrij of di-do). Dit betekent uiteraard, dat alle meetings, trainingen, tracks en socials, etc. ook geschikt gemaakt moeten worden voor gecombineerd fysiek en online publiek!
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Als IT-dienstverlener ontwikkelen we steeds kennis en kunde. We zorgen voor een cultuur waar medewerkers onderling informatie, kennis en ervaringen delen.","meta_description_search":"Als IT-dienstverlener ontwikkelen we steeds kennis en kunde. We zorgen voor een cultuur waar medewerkers onderling informatie, kennis en ervaringen delen.","slug":"https://werkenbij.vxcompany.com/blogs/openlijk-kennis-delen","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"Openlijk kennis delen"},{"header_data":{"excerpt":{"body":{"value":"In 2017 Uncle Bob wrote a great book about clean architecture. It explains the principles of a good software architecture. The book contains lots of information about the SOLID principles, about boundaries in the application, about screaming architecture, and so forth. What’s great about the book, is that it isn’t dogmatic. It doesn’t have code samples explaining how to implement a use case or a controller. However, at some point you need to start coding. This leads to the question: What could a clean architecture look like? In this article I’ll explain my take on clean architecture."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"In 2017 Uncle Bob wrote a great book about clean architecture. It explains the principles of a good software architecture. The book contains lots of information about the SOLID principles, about boundaries in the application, about screaming architecture, and so forth. What’s great about the book, is that it isn’t dogmatic. It doesn’t have code samples explaining how to implement a use case or a controller. However, at some point you need to start coding. This leads to the question: What could a clean architecture look like? In this article I’ll explain my take on clean architecture.
\nRobert C. Martin wrote a book and a webpage about clean architecture. The schematic representation of the clean architecture looks like this:
\n![\"The-Clean-Architecture-300x220\"](\"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/The-Clean-Architecture-300x220.jpg\")
In this schematic representation, they architecture looks like an onion. It has layers. Each layer has a boundary. All dependencies point inwards. As a result, the closer you get to the core, the fewer dependencies the code has.
\nIn contrast to older architectures, the database is not the centre of the application any more. The business rules are.
\nIt’s quite abstract. In the clean architecture, business-rules are implemented at the core of the application: in the use-cases, and in entities. But when is something an entity? And what is a use-case?
\nAssume we’re working on a cab dispatching application. Dispatching needs to dispatch a cab to a location. A location is defined as a longitude and a latitude. A valid longitude must be + or — 180 degrees. This is an example of a business rule. Implementing this as an entity at in the core of the application could result in this struct:
\n"},{"afbeelding":{"alt":"2022-09-06_08h54_35-1","height":350,"loading":"lazy","max_height":350,"max_width":585,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_08h54_35-1.png","width":585},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"
A cab dispatching application contains several other domain concepts too. Like a cab, a cab driver, and a passenger for example. There’s a difference between these objects. Either their state changes, or they are immutable. A location, for example, is immutable. A cab, on the other hand, is not. It has an increasing mileage. And it is either taken or not. As a result, a cab entity is probably not a struct, but a class, and it might look like this:
","reverse":false},{"afbeelding":{"alt":"2022-09-06_08h57_13-1","height":551,"loading":"lazy","max_height":551,"max_width":581,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_08h57_13-1.png","width":581},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Nothing is “wrong” in clean architecture. It doesn’t matter whether you have anaemic or rich domain models. All the entities need to do is to capture the high-level business rules.
\nEntities enforce high-level business rules. From a single responsibility perspective, they have only one reason to change. In fact.. They will probably not change at all. A mile will always be 5280 feet and we can only fit as many people in to a car as there are seats. That will never change.
\nBut some things do change. When will a company bring a car to the junkyard? After 300,000 miles? After 5 years? A company is free to change that policy whenever they want. Those kind of business-rules are use-case specific. To not violate the Single Responsibility Principle, these “ifs” go into a separate file: the use-cases.
\nUse cases interact with the entities. They drive entities to achieve a business goal. Every use-case tells a story. And it might look like this:
\nThe rule of clean architecture is: all dependencies point inwards. The entities are at the core of the application, the are use-case layer depends on the entities, and the infrastructure layer depends on the use-cases.
\nAs you can see in the sample-code, the use-case layer interacts with infrastructure too. Like the database, for example. That makes the use-case layer seem dependent on the infrastructure layer. But with Clean Architecture, it should be the other way around. So how does that work?
\nAt the core of the application, you’ll find entities, use-cases, and interfaces. These interfaces define what the outside layers will look like and how the use-cases will interact with it. But the implementation is not at the “core” of the application. It’s implemented in another layer. That’s how the boundary is crossed.
\n![\"Core\"](\"https://vxcompany.com/wp-content/uploads/2021/09/Core-300x245.png\")
There are two types of interaction with use-cases. The use-cases interact with the system, or a system interacts with the use-cases. In ports-and-adapters, these are called the primary- and the secondary ports.
\nA primary port is an interface to something the application will respond to. Like a keyboard, for example. When you hit enter, the application will do something.
\nA secondary port is an interface to a system the application interacts with. Like a database. The application is operating the database. It sends it instructions, and the database responds to it.
\nIn most of the applications I’ve worked with, this is what the folder structure looks like:
\n![\"\"](\"https://miro.medium.com/max/408/1*Tu2z_cdYJ82ADQWyWpQiBg.png\")
We have a tendency to group things by type. But this makes it unclear what the application does with these types. Not to mention it’s failing capacity to scale. Try putting 300 entities in a folder. It will be a mess.
\nInstead, focus on the functionality of the application. We are building a cab dispatching application. So, group everything by functionality, and have the application screaming “CABS!!! CAB DRIVERS!! I’M A CAB DISPATCHING APPLICATION!!!”. It should be clear what the application does by it’s file- and folder structure only, without reading a single line of code. Put interfaces, entities, and use-cases in the same folder. By grouping by functionality, the application will grow organically and remain easy to navigate:
\n![\"\"](\"https://miro.medium.com/max/410/1*nFB-AZf7XFHz6FmIPnqBmg.png\")
The use cases and the entities are the core of the application. By invoking one, or a sequence of use cases, an application can achieve a business goal. There are several “things” that can do this. In case of an event-driven application, a command handler will typically invoke the use-cases. In my case, I’m building a REST API, and the consumer of the API can invoke the use-cases directly. A simple controller will look like this:
\nOr, in a more complex scenario:
","reverse":false},{"afbeelding":{"alt":"2022-09-06_09h02_00-1","height":234,"loading":"lazy","max_height":234,"max_width":584,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_09h02_00-1.png","width":584},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Note that I’m not using dependency injection on the constructor to inject the use-cases into the controller. I’m injecting directly into the method instead, because every controller method will probably use another use-case.
\nWith the entities, use-cases, and controllers in place, there’s only one more layer left: The infrastructure layer. This layer contains things like database adapters, or API calls to third party API’s.
\nImplementing infrastructure on the outer layer has several advantages:
\nUsing this DBContext:
","reverse":false},{"afbeelding":{"alt":"2022-09-06_09h15_21","height":262,"loading":"lazy","max_height":262,"max_width":584,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/2022-09-06_09h15_21.png","width":584},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Clean architecture projects often have a “Infrastructure” folder. This folder contains the adapters to the bits of infrastructure the application uses to accomplish things:
\n![\"\"](\"https://miro.medium.com/max/398/1*JLlrgZYnYUbh8-hdDQgmxw.png\")
This application uses:
\nThere are lots of concepts in the Clean Architecture. There are several ways of having that manifest in an actual application. I’ve built a simple .NET Core application with — what I think — is clean enough. Check it out: https://github.com/appie2go/clean-architecture let me know what you think!
\n\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"What could a clean architecture look like? In this article I’ll explain my take on clean architecture.","meta_description_search":"What could a clean architecture look like? In this article I’ll explain my take on clean architecture.","slug":"https://werkenbij.vxcompany.com/blogs/implementing-clean-architecture","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"Implementing Clean Architecture, DDD-style, with .NET Core"},{"header_data":{"excerpt":{"body":{"value":"Learning Test-Driven Development (TDD) isn’t very difficult. There are only a few rules you need to follow when doing TDD. And you can find plenty of resources that teach you the basics. But it is often a big leap from learning the basic TDD exercises to applying it in your day job on real-life production software. I know it certainly was for me! So, what can you do to make that leap easier? Let’s look at a number of strategies."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Learning Test-Driven Development (TDD) isn’t very difficult. There are only a few rules you need to follow when doing TDD. And you can find plenty of resources that teach you the basics. But it is often a big leap from learning the basic TDD exercises to applying it in your day job on real-life production software. I know it certainly was for me! So, what can you do to make that leap easier? Let’s look at a number of strategies.
\nYou can’t skip this step: you must learn the basics first. I think the best way to get started is by attending an intensive training course, but that is of course my very much biased opinion as a TDD trainer. You can also pick up a copy of the book Test-Driven Development By Example, by Kent Beck, which is more or less regarded as the origin of modern TDD practice. And then there are numerous courses on YouTube, Pluralsight, Udemy, and other learning platforms, tailored to your specific programming language and level of experience.
\nTDD is easy. Uncle Bob summarized the entire process in just three simple rules:
\nIf you follow these rules, you will get the red-green-refactor cycle which is so typical of TDD.
\nBut there’s a difference between understanding the rules, and ingraining them in your thought process to the point where applying them becomes automatic. So, in the beginning, don’t overthink things and just practice. Start with basic exercises such as FizzBuzz or the Bowling Game kata. Then, find new exercises to do, and keep repeating your favorite ones until you can do them by heart. There’s a certain elegant rhythm to TDD, and the more you practice this rhythm, the easier it becomes to apply it in different scenarios.
\nThere are two main ways you can use test doubles (i.e. mocks, fakes, stubs, etc.). The first one is to replace an expensive resource, such as a database or the network. You will often learn about this use of test doubles in courses and tutorials.
\nThe second way is to replace your own code with test doubles. For example, if you have some API controller that calls into a service, you could write a test for your controller where you provide a mock service instead of the real one. This way, you can completely isolate the controller in your test.
\nWhether you consider this a beneficial and powerful technique or a definite anti-pattern depends on the style of TDD you are practicing. See the next section on the two styles of TDD.
\nEven if you’re not a fan of using mocks to replace your own code, you may still want to consider this technique. When you want to apply TDD in a big, existing, legacy code base, it can be really helpful to use mocks like this to isolate certain classes. It can be a great get-your-foot-in-the-door technique to start applying TDD in an existing project.
\nLearning how to test and refactor legacy code is a very valuable skill to master. In simple exercises, TDD is relatively easy to do. Applying TDD in a fresh production codebase requires additional skill. And applying TDD in a legacy codebase can be outright challenging. You might face code that is hard to test, such as long methods, an over-use of static functions or variables, or tight dependencies between classes that are hard to break apart. You can learn how to deal with such situations by mastering only a handful of refactoring techniques. A good place to start would be this screencast.
\nThere are two main styles or schools of TDD: the classicist style (AKA Chicago school) and the outside-in style (AKA London school). If you have read Kent Becks book, or practiced one of the original katas such as the Bowling Game kata, you have seen an example of the classicist style. If you have read books such as Growing Object-Oriented Software Guided By Tests by Steve Freeman and Nat Price, or have practiced the Bank Account kata, you have seen examples of the outside-in style.
\nI should hasten to say that these styles are not mutually exclusive. Although most TDD’ers have a preference towards one of these styles as their default, both styles have their merits and weaknesses. Knowing both these styles allows you to pick the right TDD approach for the right situation.
\n\n\nTypically, it is said that you need more experience and design skills to successfully use the outside-in style as compared to the classicist style. For me personally though, it wasn’t until I watched Sandro Mancuso’s excellent screencasts on the Bank Account kata and a refactoring exercise on legacy code until I began to see how I could start applying TDD in my day job. This highly depends on your background and the kind of software that you are working on, but these are excellent learning resources on the outside-in style nonetheless.
\n
The architecture/design of your code (I’m using the terms loosely here) and the TDD process are closely related.
\nFirst of all, the quality of your design will dictate the ease with which you can write tests. In a loosely coupled, well designed system, tests are easy to write and maintain. In a tightly coupled code base, tests will be much harder to create and will typically involve very complex setups.
\nSecondly, the type of architecture will also influence the shape and style of your tests. In a typical 3-layered architecture, the tests you write tend to be somewhat different from the tests for a Clean Architecture-based system. Their setup will be different, and the unit or module that you are testing might have a different scope as well.
\nAnd then there is the concept of emergent design. In most examples of classicist TDD, a large part of your design will emerge in the Refactor phase of the TDD cycle, by cleaning up your code and removing duplication.
\nPersonally, I have become a fan of domain-centric architectures (which go by names such as Clean Architecture, Union Architecture, or Hexagonal Architecture/Ports-and-Adapters). In such an architecture, writing the bulk of your tests against the Use Case-layer/Primary Ports-layer seems to hit a sweet spot: tests are very expressive, easy to set up, and hardly tied to your implementation logic, which allows for a lot of freedom to refactor your production code.
\nFor more information on this combination of TDD and architecture, I highly recommend this presentation by Ian Cooper.
\nLearning TDD is just like learning how to drive a car: you don’t really learn how to drive until after you have gotten your drivers license. Similarly, you only really learn TDD after having learnt the basics and after you have accumulated some experience applying it in real-world code bases.
\nThe best way to accelerate that process? Practice! Practice the exercises, both classicist style and outside-in style. Repeat the code kata. Practice testing and refactoring legacy code. Practice applying it in your day job, even if that initially takes some extra time. Eventually, you’ll pick up more and more tricks along the way and you will notice that the practice starts to pay off: you write code faster, easier, and with less defects, and you’ll hardly ever need to use the debugger anymore.
\nI hope one of these tips resonates with you. Let me know in the comments. Now go and practice your kata!
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Learning Test-Driven Development (TDD) isn’t very difficult. There are only a few rules you need to follow when doing TDD.","meta_description_search":"Learning Test-Driven Development (TDD) isn’t very difficult. There are only a few rules you need to follow when doing TDD.","slug":"https://werkenbij.vxcompany.com/blogs/getting-started-with-tdd","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"Getting started with TDD"},{"header_data":{"excerpt":{"body":{"value":"How do you keep track of your tasks as a software developer? Perhaps your team uses a Kanban board, or issue-tracking system. And personally you might have a calendar, a to-do list, or even a personal productivity system such as Getting Things Done. There are a lot of productivity apps you can download. But there is one app that hardly ever shows up in productivity app reviews. An app that keeps you in a state of flow and makes you very productive: good old Windows Notepad*."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"How do you keep track of your tasks as a software developer? Perhaps your team uses a Kanban board, or issue-tracking system. And personally you might have a calendar, a to-do list, or even a personal productivity system such as Getting Things Done. There are a lot of productivity apps you can download. But there is one app that hardly ever shows up in productivity app reviews. An app that keeps you in a state of flow and makes you very productive: good old Windows Notepad*.
\n*The built-in text editor of macOS or your favorite Linux distro is fine as well, as long as it’s in plain-text mode.
\nTo understand the use of such a simple app as Notepad, we need to look at the way you work as a developer. The following cartoon by Jason Heeris illustrates this very nicely:
\nAs the cartoon clearly shows, you build a mental mental model of the code that you are working on. The more complex the code or the problem is that you’re trying to solve, the more complex this mental model is going to be. Any distraction will completely blow up this model, and you’re back to square one. But here’s the catch: quite often, you yourself are the largest source of distraction.
\n\n\nYou yourself are often the largest source of distraction.
\n
Picture the following scenario. You’re into a nice flow, building a new feature. In your head, you have built up quite a complex model already. Suddenly, you run into some unexpected issue in the code. It is not immediately related to the feature that you’re working on, but important enough that you don’t want to forget about it. It could be an important issue, such as a bug, or a major design flaw. Or it could be as simple as:
\nNow you’re faced with a dilemma. If you decide to solve this issue immediately, you have distracted yourself from your original task. The mental model you had created has gone up in smoke. And even if this issue only takes a couple of minutes to solve, it will still take quite some effort to get back into the flow of your original task.
\n\n\nIt takes quite some effort to get back into a flow, even after a small distraction.
\n
On the other hand, if you don’t address the issue right away, you might forget it. Or perhaps even worse: your brain, helpful as it tries to be, keeps reminding you that you should solve the issue, thereby continuously distracting you from your original task and preventing you from fully getting back into a nice flow.
\nAnd that’s where Notepad offers the ideal solution. Whenever you run into a side issue that is not related to your main task, make a quick note of it in Notepad. This hardly takes time or effort: ALT+TAB to Notepad, type a few keyword to remind you of the issue, ALT+TAB back to your code. Done. You were only minimally distracted from your original task, so your mental model of it remains largely intact. And your brain knows that you have written down a reminder for the issue. So it can relax, and won’t keep interrupting you about the issue and disturb your flow.
\n\n\nA quick note in Notepad keeps you focused on your original task.
\n
But why Notepad in particular? I already mentioned the Kanban board, your calendar, to-do apps. Why not park the reminder there? After all, those systems are built for productivity. How can a simple app such as Notepad be better?
\nThe reason is quite simple: the longer it takes to write down a reminder, the more your mental model of the original task begins to fade. So, you want to record a reminder as quickly and effortlessly as possible, and get back to your original task with minimal interruption. And it doesn’t get much quicker than Notepad. You don’t have think about labels, categories, priorities, markup, or anything else that a productivity app might require you to think about. You don’t even have to click anywhere to create a new reminder, you just start typing on a blank line.
\n\n\nIt doesn’t get much simpler than Notepad.
\n
I believe that getting into a nice flow and staying there is an important key to productivity. Plus, it feels better, more relaxed, less stressful. Anything you can do to achieve that is worth trying. So, next time you start coding your next feature, tell your colleagues that you don’t want to be interrupted for the next few hours, pour yourself a nice cup of coffee, open up Notepad, and have yourself a super productive coding session!
","reverse":false}],"module_id":52218371028,"richtext_field":"fdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"How do you keep track of your tasks as a developer? An app that keeps you in a state of flow and makes you very productive: good old Windows Notepad*.","meta_description_search":"How do you keep track of your tasks as a developer? An app that keeps you in a state of flow and makes you very productive: good old Windows Notepad*.","slug":"https://werkenbij.vxcompany.com/blogs/secret-weapon-for-flow-and-productivity-windows-notepad","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"Your secret weapon for flow and productivity: Windows Notepad"},{"header_data":{"excerpt":{"body":{"value":"How do you make your software development project a success? Make it Agile, is the popular answer. And many methodologies exist that will help you do that, such as Scrum and Kanban. But those methodologies usually focus on the work process, and not so much on the technical aspects of a software project. However, these technical aspects can impact your agility in a big way. What are these technical aspects, and how do they impact your software development project? Let’s find out."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"How do you make your software development project a success? Make it Agile, is the popular answer. And many methodologies exist that will help you do that, such as Scrum and Kanban. But those methodologies usually focus on the work process, and not so much on the technical aspects of a software project. However, these technical aspects can impact your agility in a big way. What are these technical aspects, and how do they impact your software development project? Let’s find out.
\nIn this article, I’ll describe the following technical practices that will greatly influence the agility of your project:
\nBut before we can understand how these practices impact your agility, we need to be clear about what we mean be “Agile”.
\nPersonally, I subscribe to the school of thought that says that “Agile” is an adjective, not a noun. This means that you cannot “do Agile”. Simply buying a certificate, or blindly implementing some popular process, does not mean that you “do Agile”. You can only choose to do your work in such ways that it either increases or decreases your agility.
\nIn software development projects, there are many methodologies, such as Scrum and Kanban, that are very good at providing structure and guidance for the work process. These methodologies help increase your agility.
\nHowever, in software development projects there are also certain technicalaspects to the work that can greatly improve your agility if you get them right, or completely derail your project if you get them wrong. And if you get these wrong, you can impose WIP limits all you want, shuffle sticky notes around until your arms fall of, and hold retrospective meetings until you see blue in the face, but that will probably not make much of a difference.
\nIn this article, we’ll look at some of these technical practices. If you are a software developer, mastering these topics will greatly improve your effectiveness and efficiency. If you are a Scrum Master, Agile Coach or involved in the work process in some other capacity, it helps to be aware of these technical practices. If not to coach your team directly, then at least to be aware of certain pitfalls that may be hiding in the technical side of things.
\nOne final note, before we dive in: this is certainly not an exhaustive list. I’ve taken these practices from Extreme Programming (XP), a software development methodology that prescribes both technical practices and practices for planning and organizing your work. But Extreme Programming prescribes more than these practices, and there are other practices and methodologies that will be just as valuable. Having said that, I think these practices are common to a lot of methodologies, and they provide a good introduction or starting point.
\nLet’s start with a practice that is easy to implement, and quite commonplace in most software teams today, but no less relevant: adhering to coding standards. You should agree upon a certain coding standard within your team and format all your code according to that standard.
\nIf all code looks and feels the same, it is much easier for new and veteran team members alike to find their way around the code base. Refactoring is much easier as well. And finally, a consistent code base greatly contributes to collective code ownership. See also the next sections on Collective code ownership and Refactoring. All these attributes make your code easy to reason about, easy to work with, and easy to change, so you can respond quickly to change. In other words: you are Agile.
\nFor some coding languages, coding style is largely a built-in part of the language (ELM comes to mind). For others, commonly used coding conventions can often be found online, so you don’t have to re-invent the wheel. When possible, use your code editor or some other linting or formatting tool to help you format your code according to the standards. That way, adhering to the standards can be automated for the most part.
\nThis practice states that everybody on the team can contribute to any part of the code. There is no part of the code that is ‘owned’ by certain individuals and can only be changed by them. Of course, when the team and the codebase is sufficiently large, some people will have better knowledge of certain parts of the system than others. But that should never preclude anyone from contributing code to any part of the system. This encourages everyone to apply fixes or refactorings wherever they feel it is necessary, which improves the quality of the code base over time. It also helps to avoid knowledge silos, which can be a real problem when a knowledgeable developer suddenly leaves the team.
\nIt helps to have a solid suite of automated unit tests and integration tests. You will be much more comfortable changing or refactoring a piece of code that you are not very familiar with if that code is covered by tests. That way, you can safely try out your changes and if they happen to break anything, the tests will tell you.
\nHow does this practice improve agility? Since every member of the team can work on any new feature, work will not be held up because a particular team member is not available. And no individual developer will ever become a bottleneck in the work process because the work can be distributed to all team members.
\nSimple code is easy to understand. Code that is easy to understand, is easy to change. When all code is easy to change, you can build new functionality quickly and easily. So, you should always make sure that the code is as simple as it can be. However, this is not easy! You should continuously refactor your code so that is remains simple. You should remove duplication and apply design patterns and architectural patterns to keep the code manageable. You need to decide within your team what “simple” means. And keep in mind that a solution that makes one project simple might very well complicate things in another.
\nA good guideline to follow are Kent Beck’s four rules of simple design. These are simple rules, but they will help you work towards a design that is as simple as it can be.
\nThis is a very broad topic, which has become a separate discipline in its own right (DevOps Engineer, anyone?). However, there are certain basic practices that everyone on the development team can follow. It all starts with checking in your code into a shared code repository, preferably multiple times per day. This is basic practice nowadays of course, but important, nonetheless. Next, you might want to run certain checks whenever the repository is updated. This can be as simple as checking that the code still compiles. But also as elaborate as spinning up an entire app ecosystem and running all kinds of automated integration tests. And everything in between. The goal of all this is to provide rapid feedback when something is wrong. The sooner you detect an issue in your code, the cheaper it is to fix. So having this kind of rapid feedback saves you time, money and potentially a lot of frustration.
\nApart from continuous integration, you might want to set up continuous deployment as well. In most Agile software projects, you’ll want to release early and release often. Maybe not to the final “production” environment, but then at least to some test or staging area. And doing anything over and over again means that you’ll want to automate it! So a basic strategy would be to have a deployment script that you can run against your code repository. One click to run the script, and it will automatically grab the code, build the software, and deploy it to the appropriate environment. More advanced strategies might involve running tests, deploying automatically whenever anything changes, or deploying to multiple environments based on certain criteria. Again, rapid feedback is key here: the sooner your stakeholders can evaluate new features, the better. The sooner customers can use it (and pay for it!), the better.
\nI love Test-driven development (TDD). In fact, I teach it, because I think it is one of the best practices you can adopt to improve your coding skills. There are two sides to this: making sure there are high-quality tests at all, and adopting the test-first method of writing these tests.
\nPeople sometimes think that the main benefit of an automated test suite is to prove that your software works. While that is a part of it, the main benefit is far more immediate and practical: it allows you to refactor safely (see the next section). The tests provide a safety net, so you are free to improve the code as much as you want, without risk of breaking anything. And as we saw earlier, doing so is crucial to keeping your software design simple and easy to work with.
\nThe tests also contribute greatly to your ability to do continuous integration and continuous deployment. If you run your test suite as part of your integration cycle, you will detect any potential issues quickly (again, rapid feedback!) and can address them before they become a problem.
\nAdopting the test-first approach to writing tests brings its own benefits. It forces you to really think ahead about what you want your code to do. You have to, because you have to write a test for it first! This alone will often lead to clearer, shorter, simpler, concise code. Writing the test first also ensures that your code is well testable. It has to be, almost by definition. And testable code is usually modular in nature. You may have heard that well-written code exhibits loose coupling and high cohesion? These qualities come naturally when adopting a test-first style of coding.
\nRefactoring means to change the structure of your code, without changing the behavior of your code. This practice is crucial to maintain a codebase that is simple and easy to work with. A project always starts out small and simple, and in the beginning, it takes little effort to understand everything. If you keep on adding features without any regard for the quality of the code, it quickly becomes a hard to maintain mess. You should continuously refactor to remove duplication and improve the structure of the code, so that it remains as simple as it can be.
\nAs we have seen before, this practice ties in closely with that of Test-Driven Development. Having a good test suite gives you the confidence to refactor safely, without risk of breaking existing functionality.
\nThis practice also closely relates to the practice of Simplicity. If you refactor complex code to make it simple, you make the code easier to understand, easier to change, so you improve your agility.
\nThis practice is not from Extreme Programming, but I think it deserves mentioning. The success and ease of your software development project depends heavily on choosing the right architecture for your application. And one style of architecture that has proven to be very effective is the so-called Clean Architecture. This is the name Uncle Bob uses, but it is also known as Hexagonal Architecture, Ports and Adapters, or Onion Architecture. There may be slight variations between these architectures, depending on who you ask, but the main principles are the same. This style of architecture enforces a strong separation between the ‘core’ of your application, its essence, its business rules if you will, and the ‘infrastructural’ concerns such as storage, networking, the user interface or API, etc. By adopting such an architecture, your application will be highly testable and modular. Maintaining and evolving such a system will be relatively easy.
\nA small word of warning: there is no such thing as The Ultimate Architecture™. While architectures such as Clean Architecture can be very powerful, there will be many scenarios where alternative approaches will be a better fit. But that doesn’t take anything away from the main point of this bonus tip: make sure you choose an architecture that fits the purpose of your application, because this will make all the difference for the ease with which you can develop and maintain it.
\nIf you are a software developer, I hope these practices resonate with you, and perhaps inspire you to study some of these topics more deeply. Are there any practices I have missed that you feel should definitely be on this list?
\nIf you are a Scrum Master or Agile Coach without a technical background, I hope this article gives you a better grasp on the technical side of Agile software development. I think it helps the entire team when techies have a good grasp of the basic of Agile methods, just as much as it helps when Scrum Masters or Agile Coaches understand the basic practices of software development.
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"How do you make your development project a success? Make it Agile, is the popular answer. What are technical aspects, and how do they impact your project?","meta_description_search":"How do you make your development project a success? Make it Agile, is the popular answer. What are technical aspects, and how do they impact your project?","slug":"https://werkenbij.vxcompany.com/blogs/technical-side-of-agile-software-development","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"The technical side of Agile software development"},{"header_data":{"excerpt":{"body":{"value":"Als je mij begin 2020 zou hebben gevraagd: “Maarten, wat heeft jouw voorkeur: een fysiek Kanban bord of een digitaal Kanban bord?”. Dan zou mijn antwoord zijn geweest: “Een fysiek bord wint het voor mij altijd van een digitaal bord. Een digitaal bord heeft voordelen op het gebied van statistiek en trendanalyse, maar dat is ook op te lossen met een Excel sheet.”. Ik zou een blogpost hebben geschreven over de voordelen van een fysiek bord."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Als je mij begin 2020 zou hebben gevraagd: “Maarten, wat heeft jouw voorkeur: een fysiek Kanban bord of een digitaal Kanban bord?”. Dan zou mijn antwoord zijn geweest: “Een fysiek bord wint het voor mij altijd van een digitaal bord. Een digitaal bord heeft voordelen op het gebied van statistiek en trendanalyse, maar dat is ook op te lossen met een Excel sheet.”. Ik zou een blogpost hebben geschreven over de voordelen van een fysiek bord.
"},{"afbeelding":{"alt":"Fysiek-Netjes-Marketing-Kanban-1024x768-1","height":768,"loading":"lazy","max_height":768,"max_width":1024,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Fysiek-Netjes-Marketing-Kanban-1024x768-1.jpg","width":1024},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Maar na ruim een jaar corona-maatregelen moet ik dit ongenuanceerde antwoord wel bijstellen. En dus gaat deze blogpost over de voordelen van een digitaal Kanban bord. Teams hebben de afgelopen maanden vrijwel niet fysiek kunnen samenwerken op de werkvloer en het is de verwachting dat dit ook de komende tijd niet het geval zal zijn.
\nDus werken met fysieke borden en team wanden is in de huidige omstandigheid eigenlijk niet mogelijk. Vrijwel alle kenniswerkers hebben in een korte termijn leren werken met virtuele omgevingen, digitale Kanban borden, videobijeenkomsten en een expliciete set aan werkafspraken. Dit alles om deze nieuwe vorm van interactie, efficiënt en effectief te laten verlopen.
\nDaarnaast hebben ontwikkelaars van deze virtuele toepassingen, mede door de enorme toename van gebruik, in de afgelopen periode veel feedback ontvangen. Hierdoor hebben ze veel verbeteringen doorgevoerd die beter zijn afgestemd op de gebruikerswensen. Door dit gedwongen en intensieve gebruik is mijn beeld van de mogelijkheden, de toepasbaarheid en daarmee de vertegenwoordigde waarde van deze tools veranderd.
\nEr zijn daadwerkelijk goede toepassingen ontstaan en ik moet zelfs toegeven dat in een aantal omstandigheden virtuele tools zelfs beter werken dan fysieke tools. Daarom een artikel over de voordelen van online Kanban borden.
\nOveral en altijd toegankelijk
In deze periode waar de meerderheid van onze teams verplicht thuis moet werken is één voordeel natuurlijk erg voor de hand liggend. En dat is het voordeel van toegankelijkheid. Een digitale werkomgeving is toegankelijk voor alle teamleden op afstand vanaf elke locatie als je maar een internetverbinding hebt.
Laagdrempelig en intuïtief
Daarnaast zijn veel online werkomgevingen erg laagdrempelig en intuïtief. Hiermee doel ik niet specifiek op digitale Kanban borden, maar juist ook op digitale whiteboards en online team wanden zoals:
In deze omgevingen zijn veel templates aanwezig om met weinig inspanningen jouw werkproces digitaal visueel te maken. Er zijn templates te vinden voor diverse raamwerken, zoals User Story Mapping, Kanban borden en Value Streams. Maar ook voor bijeenkomsten, zoals planning meetings, retrospectives en brainstorm sessies. Door gebruik te maken van deze omgevingen kun je vrij gemakkelijk jouw eigen Agile Team wanden en werkprocessen digitaal visualiseren.
\n(onderstaand een voorbeeld van templates in Miro)
\nCentrale opslag
Alle informatie wordt op een centrale plek opgeslagen en daardoor heb je altijd de huidige (real-time) status van de werkzaamheden beschikbaar. Dit is natuurlijk het geval voor je eigen team, maar ook de status van andere teams, managementinformatie met betrekking tot roadmaps en andere relevante strategische informatie kan beschikbaar worden gesteld.
Verhoogde veiligheid
Met digitale en centrale opslag creëer je ook meer mogelijkheden om data te beveiligen. De kans dat er informatie verloren gaat, bijvoorbeeld omdat de schoonmaker per ongeluk de wand met sticky-notes opruimt, is verleden tijd. Daarbij is het mogelijk om door middel van autorisatie en authenticatie functionaliteit bedrijfsinformatie te beschermen en wordt de kans dat onbevoegde personen bedrijf kritische informatie onder ogen krijgen beduidend kleiner. Ook wordt het mogelijk om privacy van medewerkers te waarborgen.
Naast dataveiligheid zien we ook regelmatig dat pandbeheerders en facilitaire afdelingen beperking opleggen voor het gebruik van sticky notes en papieren wanden in verband met brandveiligheid. Daarbij ziet het er ook nog eens een stuk opgeruimder uit.
\nNaast de voordelen van een online werkomgeving wil ik ook nog bewust ingaan op de voordelen van digitale Kanban borden.
\n1. Digitale Kanban borden zijn minder rommelig, zien er opgeruimder uit en stimuleren een gestructureerde overzichtelijke visualisatie en zijn daardoor eenvoudiger te onderhouden.
\n2. Met digitale Kanban borden kun je historische prestatiegegevens inzien en trendanalyses uitvoeren. Dit komt door de opslag en het nuttige gebruik van data.
\n3. Door gebruik te maken van deze data is het met digitale Kanban borden mogelijk om vrij eenvoudig een Flow analyse te doen. De meeste tools bieden een grote set aan statistische grafieken en diagrammen die specifiek bedoeld zijn voor Kanban implementaties om de Flow te managen. Onderstaand een aantal voorbeelden van Kanbanize.
","reverse":false},{"afbeelding":{"alt":"Kanbanize","height":157,"loading":"lazy","max_height":157,"max_width":631,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Kanbanize.png","width":631},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"4. De meeste digitale borden bieden specifieke maatwerk integraties met andere tools.
\n5. Door de configuratie van business rules kunnen specifieke stappen in het werkproces en werkafspraken worden geautomatiseerd.
\nOnline Kanban borden in combinatie met online werkomgevingen zijn uitermate effectief voor teams die noodgedwongen gescheiden van elkaar moeten werken. Daarnaast is er de laatste jaren erg veel energie gestoken in data opslag, statistieken en het zichtbaar maken van metrieken om de Flow van het werk meetbaar te maken en hier trendanalyse op uit te voeren. Op de vraag: “Als we weer teruggaan naar het ‘oude normaal’ neem je dan weer afscheid van de digital omgeving en Kanban borden?” Dan is mijn antwoord daarop: “Nee!” Met name de kwaliteit en het gemak van de beschikbare statistiek en de trendanalyse weegt ruim op tegen de voordelen van een fysiek bord. Maar ik denk wel dat ik een hybride vorm zou omarmen, want naast het gemak van digitaal is ook de euforie van een fysiek ticket op DONE hangen onbetaalbaar ?
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Als je Maarten begin 2020 zou hebben gevraagd: “Wat heeft jouw voorkeur: een fysiek of een digitaal Kanban bord?”. Dan zou zijn antwoord zijn: “Een fysiek bord wint het voor mij altijd van een digitaal bord.\"","meta_description_search":"Als je Maarten begin 2020 zou hebben gevraagd: “Wat heeft jouw voorkeur: een fysiek of een digitaal Kanban bord?”. Dan zou zijn antwoord zijn: “Een fysiek bord wint het voor mij altijd van een digitaal bord.\"","slug":"https://werkenbij.vxcompany.com/blogs/voordelen-van-digitaal-werken-met-kanban","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1661254761818,"deletedAt":0,"description":"","id":52177477878,"label":"Agile Coaching","language":"nl","name":"Agile Coaching","portalId":25062189,"slug":"agile-coaching","translatedFromId":50989449420,"translations":{},"updated":1661254761818}],"title":"De voordelen van digitaal werken met Kanban"},{"header_data":{"excerpt":{"body":{"value":"Wat maakt iemand een goede Scrum Master? Elke Scrum Master heeft een drive om zich te ontwikkelen. Maar hoe groei je in je rol? En hoe ben je een Agile leider?"},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Wat maakt iemand een goede Scrum Master? Elke Scrum Master heeft een drive om zich te ontwikkelen. Maar hoe groei je in je rol? En hoe ben je een Agile leider?
\nJe vult in jouw organisatie de rol van Scrum Master in. Misschien is dat je enige rol, misschien vul je hem naast een andere functie in. de rol is nog geen vanzelfsprekende functie binnen organisaties. Al komt daar vast op den duur verandering in, want de functie staat in de Top-10 van LinkedIn’s ’Most promising jobs’.
\nWat maakt iemand een goede Scrum Master? Heb jij daar zelf een goed beeld bij? Volgens de Scrum Guide is de Scrum Master voor twee dingen verantwoordelijk:
\nDat is pittig! Het betekent dat je een hele goede kennis van de theorie én het praktisch toepassen van Scrum moet hebben. Maar ook het leiderschap om mensen hierin te begeleiden.
\nZeker als jouw organisatie nog niet zo lang Scrum hanteert, of een deel van de organisatie nog flink traditioneel is ingericht, kunnen er flink wat misverstanden bestaan over Scrum. Ik geloof dan heel sterk in deze quote van Thomas Jefferson: “In matters of style, swim with the current; in matters of principle, stand like a rock.”
\nMisschien vind je dat niet zo Agile klinken, maar het tegendeel is waar. Want Agile betekent niet ‘waai maar met alle winden mee’, of ‘als deze Agile practice niet werkt, doen we het gewoon anders’. De inkleuring van het Scrum raamwerk is vrij en die pas je qua stijl aan wat bij jouw organisatie past. Maar qua principes ben je rotsvast. En dit is een kunst. Want hoe ben je duidelijk, zonder betweterig te zijn? Niet star, maar ook niet onbestendig? Daar komt leiderschap bij kijken.
","reverse":true},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Om dit te kunnen, is leiderschap nodig. Leiderschap in het Scrum Team én in de organisatie. Als leider dien, inspireer en motiveer je anderen. Je luistert, voelt goed aan en doet effectieve interventies. Je legt niets op, maar beïnvloedt mensen om op hun beurt eigen leiderschap te tonen.
","reverse":false},{"afbeelding":{"alt":"Saskia-coachend-1024x683-1","height":683,"loading":"lazy","max_height":683,"max_width":1024,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Saskia-coachend-1024x683-1.jpg","width":1024},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Dat betekent dat je in je Scrum Team de leraar, de mentor, de begeleider, de facilitator of de coach bent. Met als belangrijkste doel om te zorgen dat het team zelf managend en dus zo autonoom mogelijk kan zijn.
\nEn om het team in die actieve houding te krijgen, zorg jij dat je niet de superheld bent, of de probleemoplosser. Lyssa Adkins noemt dit in haar boek Coaching Agile Teams ‘Take it to the team’. Elke keer als je denkt dat jij iets op moet lossen, houd jezelf dan tegen. Benoem je observatie aan het team en laat hen de oorzaak onderzoeken en de oplossing vinden. Doe je dit niet, dan ondermijn je het probleemoplossend vermogen van het team.
\nDe rol van dienend leider vul je niet alleen in je Scrum Team in. Je hebt als Scrum Master ook een rol in het trainen, coachen en leiden van de hele organisatie in haar Scrum adoptie. Besef dan dat mensen vaak allergisch zijn voor een evangelist. Roepen dat Scrum geweldig is, of de Scrum guide citeren, werkt vaak juist averechts. Veel beter werkt het om de verbinding met mensen aan te gaan én om hen dingen zelf te laten ervaren. Gebruik participatieve werkvormen, zoals Liberating Structures en Agile simulaties. Maar vooral: wees oprecht nieuwsgierig naar de ander. Dat maakt jou uiteindelijk een change agent.
\nUiteraard heeft elke Scrum Master een drive om te willen verbeteren. Drie tips om dat te doen:
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Wat maakt iemand een goede Scrum Master? Elke Scrum Master heeft een drive om zich te ontwikkelen. Maar hoe groei je in je rol? En hoe ben je een Agile leider?","meta_description_search":"Wat maakt iemand een goede Scrum Master? Elke Scrum Master heeft een drive om zich te ontwikkelen. Maar hoe groei je in je rol? En hoe ben je een Agile leider?","slug":"https://werkenbij.vxcompany.com/blogs/kracht-van-de-scrum-master","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1661254761818,"deletedAt":0,"description":"","id":52177477878,"label":"Agile Coaching","language":"nl","name":"Agile Coaching","portalId":25062189,"slug":"agile-coaching","translatedFromId":50989449420,"translations":{},"updated":1661254761818}],"title":"De kracht van de Scrum Master"},{"header_data":{"excerpt":{"body":{"value":"Welke rol speelt een manager of leider in een Agile organisatie? Hoe ga je als manager om met een Scrum team? Hoe beoordeel je hen? En hoe stimuleer je zelfmanagement? Zeven adviezen voor de Agile leider."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Welke rol speelt een manager of leider in een Agile organisatie? Hoe ga je als manager om met een Scrum team? Hoe beoordeel je hen? En hoe stimuleer je zelfmanagement? Zeven adviezen voor de Agile leider.
\nStel, jouw organisatie heeft het Scrum raamwerk geïmplementeerd. De Scrum Guide zegt weinig over de context van de organisatie rondom een Scrum team. De Scrum Master wordt omschreven als een ‘true leader’ die het Scrum team en de grotere organisatie dient. De Product Owner pakt leiderschap via diens visie op het product.
\nOverigens, ook teams die niet scrummen maar een andere Agile werkwijze hanteren zijn uiteraard gebaat bij een Agile leider! Als jouw organisatie niet helemaal plat is dan zijn er één of meer managementlagen. Ik wil het in dit artikel níet hebben over de noodzaak voor die managementlagen, daar is al genoeg over geschreven. Laten we ervan uitgaan dat de leden van de Agile teams allemaal een manager of teamleider hebben. Hoe ben je een goede leider in een Agile organisatie?
\nScrum teams zijn zelfmanagend (ook wel zelforganiserend of zelfsturend genoemd). Dat betekent dat teamleden onderling bepalen wie wat doet, wanneer en hoe. Een belangrijke leiderschapstaak is het ondersteunen van dat zelfmanagement. Hoe doe je dat?
\nNatuurlijk willen we graag dat alle medewerkers gemotiveerd zijn. In zijn boek Drive legt Daniel Pink uit dat ‘wortel-en-stok-methodes’ (straffen en belonen) alleen maar zorgen voor extrinsieke motivatie.
","reverse":false},{"afbeelding":{"alt":"Afbeelding8-1","height":228,"loading":"lazy","max_height":228,"max_width":288,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Afbeelding8-1.jpg","width":288},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Om de motivatie die mensen van binnenuit voelen te bevorderen, zijn volgens Pink drie dingen noodzakelijk: Autonomie, Meesterschap en Zingeving.
\nEen Agile leider helpt mensen door een duidelijk doel (purpose) uit te dragen, hen te helpen groeien in meesterschap en autonomie te laten pakken.
","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"In 2014 legde Henrik Kniberg in een animatievideo uit hoe de manier van werken is bij Spotify. Zijn visualisatie van de managementcultuur is treffend:
","reverse":false},{"afbeelding":{"alt":"Afbeelding2-300x190","height":317,"loading":"lazy","max_height":190,"max_width":300,"size_type":"exact","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Afbeelding2-300x190.png","width":500},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"De situatie rechtsboven is de leiderschapsstijl waar Kniberg voor pleit: ‘Aligned autonomy’.
\nEen Agile leider geeft richting (alignment), maar borgt ook de autonomie van de mensen. Door hen vrij te laten in de manier waarop zij hun werk doen (het hoe).
","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Het slechtste wat je kunt doen is tegen een team zeggen ‘Jullie zijn voortaan zelforganiserend’ en het team vervolgens volledig loslaten. Als mensen dit tot nu toe niet gewend waren, vraagt het best wat van hen. Als manager kun je de mate van vrijheid of autonomie die een team heeft steeds meer opbouwen en hen helpen om steeds meer regie en vrijheid te pakken en de bijbehorende competenties te ontwikkelen. Onderstaand model van Peter Koning uit het boek ‘Toolkit voor Agile Leiders’ visualiseert dit erg duidelijk.
","reverse":false},{"afbeelding":{"alt":"OwnershipModel-xW350-1","height":440,"loading":"lazy","max_height":440,"max_width":350,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/OwnershipModel-xW350-1.png","width":350},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Een Agile leider laat mensen groeien in zelfstandigheid, waardoor zij vanzelf meer eigenaarschap voelen over hun werk.
","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Hoewel het model niet onomstreden is, vind ik de fasen van teamontwikkeling van Tuckman enorm verhelderend. Hieronder een visualisatie ervan door Floor Daver.
","reverse":false},{"afbeelding":{"alt":"Afbeelding-7-1024x579","height":579,"loading":"lazy","max_height":579,"max_width":1024,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Afbeelding-7-1024x579.png","width":1024},"choice_field":"tekst","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Een team start in de vluchtfase. Het kent elkaar nog niet goed, heeft nog geen duidelijk gezamenlijk doel en fysiek treden er vluchtreacties op (geen oogcontact maken, échte issues in gesprek uit de weg gaan). Als het team zich verder ontwikkelt treedt er een roerige fase op, de strijdfase. Kritiek en issues rondom verhoudingen zorgen voor conflict. Maar áls een team deze fase goed doorkomt komen zij in de samenfase. Hier zijn het doel en de onderlinge rollen helder geworden. Samenwerking loopt lekker. Maar het team is wel gesloten. Er is weinig openheid naar de buitenwereld of voor kritiek of nieuwe ideeën. Zodra het het team lukt hierop te reflecteren en verbeteren komt het in de werkfase. En hier is volgens Tuckman sprake van een ‘high performing team’.
\nVerdrietig genoeg blijven veel teams in fase 1 of 2 hangen. Er is te weinig veiligheid, vertrouwen of simpelweg tijd en aandacht om als team te groeien.
\nEen Agile leider neemt én geeft tijd voor teamontwikkeling. En biedt een helpende rol in dit proces.
","reverse":false},{"afbeelding":{"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Als ik je al helemaal aan boord heb gekregen bij punt 1 en 3 en je de waarde ziet van intrinsieke motivatie en eigenaarschap, dan ben je het misschien ook wel met me eens dat niemand gelukkig wordt van een traditioneel beoordelingsgesprek. Ik schreef hier al eerder dit artikel over.
\nOnderzoek heeft uitgewezen dat als mensen individuele bonusdoelstellingen krijgen, ze deze willen halen, zelfs als dat ten koste gaat van het team- of organisatiebelang. Het hele Scrum raamwerk is bovendien geënt op het realiseren van een teamprestatie. Daarom is het vreemd én contraproductief om leden uit een Scrum team individueel te beoordelen.
\nEen Agile leider helpt elk individu én team om te groeien vanuit potentie en talenten, op eigen initiatief en onder eigen regie. En koppelt dit bovendien los van (salariële) beloning.
","reverse":false},{"afbeelding":{"alt":"Afbeelding5-300x164","height":164,"loading":"lazy","max_height":164,"max_width":300,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Afbeelding5-300x164.png","width":300},"choice_field":"tekst","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Performance development bij Achmea
","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"De adviezen hierboven zijn vooral gericht op hoe een leider interacteert met individuen en teams. Maar zoals een Scrum Master helpt met het wegnemen van belemmeringen, is het ook een belangrijke leiderschapstaak om organisatiebelemmeringen weg te nemen.
\nHet Scrum team wil graag werken aan zaken die de meeste klantwaarde opleveren, maar wordt door ‘bedrijfsregels’ gedwongen om een jaar van tevoren budgetten per project aan te vragen, of eindeloos lange ‘project initiation documents’ op te stellen met daarin al een uitsplitsing van requirements. Dit conflicteert met het Agile gedachtengoed van incrementeel en empirisch werken.
\nOf teams blijven het maar eng vinden om ‘met de billen bloot te gaan’. Er wordt al een tijdje geroepen dat ‘fouten maken mag’, maar stiekem is er nog best een afrekencultuur.
\nEen Agile leider schept de randvoorwaarden voor individuen en teams om optimaal te kunnen werken in de organisatie.
\nEn tot slot is ook persoonlijk leiderschap van belang. Hoe Agile ben jij zelf? Doorleef je de Scrum waarden Lef, Focus, Betrokkenheid, Respect en Openheid? Durf je op jezelf te reflecteren, wil je je ontwikkelen en sta je open voor feedback?
\nBron: Scrum.org
\nEen Agile leider kent zichzelf en inspireert anderen door voorbeeldgedrag.
","reverse":false}],"module_id":52218371028,"richtext_field":"fdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Welke rol speelt een manager of leider in een Agile organisatie? Hoe ga je als manager om met een Scrum team? Zeven adviezen voor de Agile leider.","meta_description_search":"Welke rol speelt een manager of leider in een Agile organisatie? Hoe ga je als manager om met een Scrum team? Zeven adviezen voor de Agile leider.","slug":"https://werkenbij.vxcompany.com/blogs/zeven-adviezen-voor-agile-leiderschap","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1661254761818,"deletedAt":0,"description":"","id":52177477878,"label":"Agile Coaching","language":"nl","name":"Agile Coaching","portalId":25062189,"slug":"agile-coaching","translatedFromId":50989449420,"translations":{},"updated":1661254761818}],"title":"Zeven adviezen voor Agile leiderschap"},{"header_data":{"excerpt":{"body":{"value":"Eigenlijk is er helemaal geen relatie tussen de muziek van Metallica en het Kanban Maturity Model (KMM), maar ik ga jullie een anekdote vertellen waarmee ik de relatie tussen deze twee toch leg. Hierbij speelt de (Kanban) Coach overigens een belangrijke brugfunctie."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Eigenlijk is er helemaal geen relatie tussen de muziek van Metallica en het Kanban Maturity Model (KMM), maar ik ga jullie een anekdote vertellen waarmee ik de relatie tussen deze twee toch leg. Hierbij speelt de (Kanban) Coach overigens een belangrijke brugfunctie.
"},{"afbeelding":{"alt":"Master-of-Puppets-J-Curve","height":326,"loading":"lazy","max_height":326,"max_width":717,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Master-of-Puppets-J-Curve.png","width":717},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Mijn tienerdochter vroeg mij zo’n zes maanden geleden of ik haar kon leren gitaar spelen. Ze had lang geleden een akoestische gitaar gekregen van haar oom. Op die gitaar wilde ze haar favoriete muziek zelf kunnen spelen, maar het lukte haar niet om daar verder mee te komen. Hoewel ik eigenlijk meer een drummer ben dan een gitarist achtte ik mijn gitaarspel toch van voldoende niveau om haar wat te leren. Dus ik zei tegen haar: “Natuurlijk wil ik je daarbij helpen. Laat mij eerst eens zien wat je al kan”. Ze toonde mij haar zelf aangeleerde gitaarspel. Ze kon al een aantal open akkoorden spelen en was behoorlijk ritme vast. Als kampvuur gitarist was ze al een behoorlijk eind op weg. Mijn vervolg vraag aan haar was dan ook: “Welke muziek wil je dan graag kunnen spelen?”. Ze antwoorde met: “Nirvana en Green Day en Metallica enzo… weet je…”.
\nTrots dat onze muzikale opvoeding zijn vruchten had afgeworpen realiseerde ik mij tegelijkertijd dat nummers als “Smells like Teen Spirit” en “Master of Puppets” toch een aanmerkelijk hoger niveau van haar zouden verlangen. Ze moest barré grepen kunnen pakken om power akkoorden te spelen. Daarnaast zijn de gitaarriffs behoorlijk uitdagend, vanwege de timing en op de juiste manier van dempen van de snaren. Hierbij moeten de handen ook nog eens onafhankelijk van elkaar opereren.
\nIk stelde mijzelf de vraag hoe ik haar nu het beste zou kunnen helpen. Beginnen met het ritme van de riffs leek mij een stap te ver. Het moest weliswaar uitdagend zijn, maar niet zo uitdagend dat het demotiverend zou werken. Dus ik vroeg haar te beginnen met het oefenen van simpele barré grepen.
\nIk zag dat de gitaarhals te breed was voor haar handen en wist dat dit een uitdaging ging worden. Dus nog voor ze kon mopperen stelde ik voor om op mijn oude elektrische gitaar te gaan oefenen. Om haar te motiveren zei ik: “Volgens mij is dit ook de gitaar die Kurt Cobain gebruikte op Smells like Teen Spirit!”, en dat werkte. Nu geef ik haar nog elke zondagochtend gitaarles en is zij erg gemotiveerd om verder door te groeien. Ze maakt nu zelfs gebruik van mijn kleine draagbare versterker en soms lijkt het alsof Kurt Cobain bij ons op zolder aan het oefenen is op Metallica gitaar riffs. Ze heeft zoveel groei doorgemaakt dat ik haar niet meer kan laten zien hoe het moet. Wat ik nu nog wel kan doen is haar uitdagen en motiveren! En natuurlijk gewoon samen spelen en plezier hebben!
","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Mijn muzikale vaardigheden en ervaring als Coach stelde mij in staat om mijn dochter te helpen. Op een vergelijkbare manier biedt KMM een raamwerk die Kanban Coaches in staat stelt om organisaties te helpen bij de groei in organisatievolwassenheid en dit meetbaar te maken. KMM doet dit door inzicht te geven in het huidige volwassenheidsniveau van de organisatie en beschrijft welke groeipaden er zijn om een volgend niveau te bereiken.
\nNet als mijn dochter hebben ook organisaties te kampen met een stilstand in de groei. Met als resultaat een vastgelopen of totaal mislukte transformatie. Hierbij herkennen we twee veelvoorkomende oorzaken:
","reverse":false},{"afbeelding":{"alt":"organisatie-tolerantie-300x205","height":1708,"loading":"lazy","max_height":205,"max_width":300,"size_type":"exact","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/organisatie-tolerantie-300x205.png","width":2500},"choice_field":"tekst_afbeelding","content":"De organisatie, of vaker nog de Agile Consultant, wil een te grote stap nemen. Dit leidt tot een uitdaging die te moeilijk of zelfs onuitvoerbaar is. Hierdoor kost de stap naar het volgende niveau te veel tijd en te veel geld. De weerstand op alle niveaus van de organisatie neemt toe en de organisatie tolerantie wordt te veel op de proef gesteld. Met als uitkomst dat de transformatie vastloopt of zelfs wordt stopgezet. Waarna men op zoek gaat naar de volgende ‘Revolutionaire verandering’
","reverse":false},{"afbeelding":{"alt":"performance-time-300x205","height":1367,"loading":"lazy","max_height":205,"max_width":300,"size_type":"exact","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/performance-time-300x205.png","width":2000},"choice_field":"tekst_afbeelding","content":"De teams hebben ‘sticky-notes’ op een whiteboard geplakt en doen elke dag een standup meeting bij het bord en men is tevreden met de ‘Kanban implementatie’! De organisatie heeft onvoldoende kennis van wat mogelijk is en/of voelt onvoldoende urgentie om volgende stappen te zetten. In dit geval is het nodig om urgentie te ontwikkelen en de organisatie te verleiden om iets nieuws te proberen.
","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Het is de uitdaging van de Kanban Coach om organisaties, teams en individuen uit hun comfort-zone te halen. Dit doen we door mensen te verleiden nieuwe dingen te proberen, lichte stress te ontwikkelen en schijnbare barrières weg te nemen. Dit is ook het uitgangsprincipe van bijvoorbeeld sportcoaches en muziekleraren. Om jouw leerling of coachee zo effectief mogelijk in hun leergedrag te stimuleren gaan we op zoek naar de sweetspot van uitdaging.
\nDeze sweetspot wordt de ‘Leer zone’ genoemd en bevind zich tussen de ‘Comfort zone’ en de ‘Paniek zone’. De ‘Comfort zone’ is de plek waar men zich wel lekker bij voelt, maar weinig tot geen uitdaging heeft. De ‘Paniek zone’ is de plek waar de uitdaging te moeilijk of zelfs onuitvoerbaar is, men stress ervaart en in paniek raakt. We gaan dus op zoek naar de ‘Leer zone’ waar de uitdaging groot genoeg is om te groeien maar nog wel uitvoerbaar is.
","reverse":false},{"afbeelding":{"alt":"zones-300x300","height":300,"loading":"lazy","max_height":300,"max_width":300,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/zones-300x300.png","width":300},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Het Kanban Maturity Model is een Evolutionair Verander model en is opgebouwd uit Culture (Cultuur), Practices (Werkwijzen) en Outcomes (Resultaten).
","reverse":false},{"afbeelding":{"alt":"ui-model-268x300","height":1120,"loading":"lazy","max_height":300,"max_width":268,"size_type":"exact","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/ui-model-268x300.png","width":1000},"choice_field":"tekst_afbeelding","content":"Culture beschrijft de identiteit van de organisatie. Het beschrijft “hoe we met elkaar omgaan”, “wie we zijn” en “waar we voor staan”. Cultuur is opgebouwd uit een viertal lagen:
\nWaarden & Grondbeginselen, Rituelen, Helden en Symbolen. Hoe dichter een laag bij de kern ligt, hoe moeilijker deze te veranderen is. Als we de waarden en normen van een organisatie willen veranderen is dit de meest uitdagende laag van cultuur. Dit vergt een grote langdurige inzet van juist leiderschap in een organisatie.
\nPractices beschrijven de werkwijze van de organisatie. Ze beschrijven “hoe we de dingen hier doen”. Dit zijn alle reguliere activiteiten, communicatielijnen, waarneembare interacties tussen mensen, metingen en metrieken, kaders voor verantwoordelijkheden en prioriteitstelling. Oftewel de dagelijkse gang van zaken met gewoonten en rituelen en hoe medewerkers hun professie in praktijk brengen.
","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Outcomes zijn de waarneembare resultaten van een organisatie. Ze beschrijven “hoe ons bedrijf eruitziet” voor klanten, gebruikers en belanghebbenden. Resultaten laten zien of onze organisatie ‘Fit for Purpose’ is. De resultaten geven ook aan of ons bedrijf duurzaam en robuust is en of deze op lange termijn gaat overleven. Resultaten illustreren ook onze veerkracht en ons vermogen om te herstellen van tegenslagen.
","reverse":false},{"afbeelding":{"alt":"managed-evolution-300x300","height":1200,"loading":"lazy","max_height":300,"max_width":300,"size_type":"exact","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/managed-evolution-300x300.png","width":1200},"choice_field":"tekst_afbeelding","content":"Evolutionaire verandering
De adoptie van nieuwe werkwijzen vergt een verandering van de cultuur en heeft een verandering van de resultaten tot gevolg.
Nieuwe werkwijzen worden door alle deelnemers (medewerkers en managers) op basis van behoefte geadopteerd. De nieuwe werkwijze wordt hen niet opgedrongen (no push), maar wordt hen aangereikt (pull). Het belangrijkste doel is om de veranderingen te laten beklijven door middel van intrinsieke motivatie en oprechte behoefte. Een goede toepassing van evolutionaire verandering zorgt voor een duurzame en robuuste verbetering.
","reverse":false},{"afbeelding":{"alt":"evolutionaire-verandering-300x133","height":133,"loading":"lazy","max_height":133,"max_width":300,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/evolutionaire-verandering-300x133.png","width":300},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Een waardevol hulpmiddel voor de Kanban Coach binnen dit evolutionaire verandermodel is de Practices Map. Hierin staat gecodificeerd welke (Kanban) Practices en Cultural Values horen bij welk Organizational Maturity Level (volwassenheidsniveau).
\nDe Practices staan gegroepeerd in kolommen van de Kanban General Practices: Visualize, Limit WIP, Manage Flow, Make Policies Explicit, Feedback Loops, Improve & Evolve.
\nElk volwassenheidsniveau wordt gekarakteriseerd door een specifieke set van de Kanban General Practices. De Practices worden geavanceerder naarmate deze zich in een hoger volwassenheidsniveau bevinden.
","reverse":false},{"afbeelding":{"alt":"Kanban-Maturity-Model-1024x742","height":742,"loading":"lazy","max_height":742,"max_width":1024,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Kanban-Maturity-Model-1024x742.png","width":1024},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Op de niveaus ML1 tot ML6 bestaan de Practices uit Transition Practices (transitie werkwijzen) en Consolidation Practices (consolidatie werkwijzen).
\nDe Transition Practices zijn meestal simpeler en makkelijker in gebruik te nemen. Vaak bieden deze geen oplossing voor een probleem, maar maken ze problemen transparant en zichtbaar.
\nDe Consolidation Practices zijn over het algemeen moeilijker te implementeren en vergen veelal verandering. Hierbij kun je denken aan de overgang naar andere tools, een andere werkwijze van het management, het invoeren en afschaffen van specifieke bijeenkomsten, enzovoort.
","reverse":false},{"afbeelding":{"alt":"Consolidation-practices-1024x286","height":286,"loading":"lazy","max_height":286,"max_width":1024,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Consolidation-practices-1024x286.png","width":1024},"choice_field":"afbeelding","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"De Kanban Coach houdt de motor van evolutionaire verandering draaiende door continu op zoek te gaan naar de ‘Leer zone’ van de organisatie. De Coach observeert en inventariseert de aanwezigheid van Kanban practices en culturele waarden in de organisatie. Hierdoor krijgt de coach een goed begrip van het volwassenheidsniveau van de organisatie. Met dit begrip kan de Coach de geschikte Kanban practices aanreiken en introduceren en zo de organisatie helpen te groeien naar het volgende volwassenheidsniveau. Transition Practices veroorzaken lichte stress door zichtbaar te maken wat de problemen zijn. Consolidation Practices lossen problemen op of verleiden medewerkers tot een nieuwe werkwijze.
","reverse":false},{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"In deze blogpost hebben we in vogelvlucht gekeken naar het Kanban Maturity Model en hoe je verschillende hulpmiddelen, zoals de ‘Practices map’, kunt inzetten. Als je hier meer over te weten wilt komen is er een aantal mogelijkheden.
\nAls je wilt weten hoe je het KMM framework kunt inzetten om jouw eigen organisatie op een hoger niveau te tillen of om als Kanban Coach jouw klant hiermee te kunnen helpen adviseer ik de lezer om de trainingen ‘Kanban Maturity Model’ en ‘Kanban Coaching Professional’ te volgen of allebei tegelijk.
","reverse":false}],"module_id":52218371028,"richtext_field":"fdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Eigenlijk is er geen relatie tussen Metallica en het Kanban Maturity Model, maar ik ga de relatie toch leggen. Hier speelt de Kanban Coach een brugfunctie.","meta_description_search":"Eigenlijk is er geen relatie tussen Metallica en het Kanban Maturity Model, maar ik ga de relatie toch leggen. Hier speelt de Kanban Coach een brugfunctie.","slug":"https://werkenbij.vxcompany.com/blogs/kmm-en-metallica","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1661254761818,"deletedAt":0,"description":"","id":52177477878,"label":"Agile Coaching","language":"nl","name":"Agile Coaching","portalId":25062189,"slug":"agile-coaching","translatedFromId":50989449420,"translations":{},"updated":1661254761818}],"title":"De relatie tussen KMM en Metallica’s Master of Puppets"},{"header_data":{"excerpt":{"body":{"value":"Joost de Bos is een enthousiaste en leergierige Java ontwikkelaar met een afgeronde hbo Informatica opleiding, die alweer vijf jaar bij VX Company werkt. Naast zijn werk fietst hij graag en kijkt hij graag naar sportwedstrijden."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Joost de Bos is een enthousiaste en leergierige Java ontwikkelaar met een afgeronde hbo Informatica opleiding, die alweer vijf jaar bij VX Company werkt. Naast zijn werk fietst hij graag en kijkt hij graag naar sportwedstrijden.
\nHij is in dienst gekomen vanwege de informele sfeer en omdat VX Company een bedrijf is waar je (buiten corona-tijd om) in het bedrijfsrestaurant en de wandelgangen je collega’s bij hun voornaam begroet. Daarnaast word je niet van bovenaf gestuurd maar begeleid en dat is wat Joost bij VX Company aanspreekt. Wij zijn benieuwd hoe het met de carrière van Joost gaat, dus we hebben hem wat vragen gesteld. Natuurlijk op de fiets en met gepaste afstand.
\nJoost: “Mijn loopbaan is gestart bij een organisatie die opereert in het domein infrastructuur en mobiliteit. Daar heb ik een module verkeersinformatie toegevoegd aan een bestaande applicatie: Verkeer.nu. De organisatie heeft aangegeven tevreden te zijn, want ze kunnen nu een compleet verkeersmanagementplatform aanbieden. Na deze opdracht ben ik bij een zelfstandig bestuursorgaan (ZBO) van de Rijksoverheid gaan werken. Daar heb ik meegeholpen aan de doorontwikkeling van KOERS, de vernieuwing van het aktes systeem. Dit systeem wordt nog steeds gebruikt. Na verloop van tijd begon het opnieuw te borrelen…”
\nJoost: “Er kwam een nieuwe functie vrij bij een middelgroot productenbedrijf, met een hoog maatschappelijk nut, dat bezig is Nederland en Europa te veroveren. Hier werk ik sinds maart 2020. Voor mij was dit hét moment om te reageren op deze innovatieve functie. Samen met mijn People Manager en de Accountmanager heb ik mijn zakelijke wensen geuit. Ik vind het belangrijk om impact te maken met mijn werk. Daarnaast wil ik mijn kennis uitbreiden en de vrijheid hebben om werk te kiezen waar ik helemaal achter sta. Het was mijn wens om Scala eigen te maken én in de praktijk te gebruiken. Bij deze mogelijkheid kwam alles samen. Ook bij deze klant heerst er een informele sfeer, net zoals bij VX Company, dat spreekt mij erg aan.”
\nJoost: “Deze (eind)klant van VX Company is actief in de logistieke branche, er werd ter uitbreiding van het team gezocht naar een zelfstandig werkend Scala ontwikkelaar. De klant heeft een onafhankelijk Cloud platform voor transport en logistiek. Dit biedt een snelle en veilige samenwerking met en tussen transporteurs. Denk hierbij aan de bezorgdiensten van onder andere grote retailers.”
\nJoost: “Ik maak deel uit van een Agile team dat onder andere heeft gewerkt aan de digitale vrachtbrief. De methoden en technieken die mijn teamleden en ik gebruiken zijn: Scala, Kafka en Akka op een AWS platform. Het is erg prettig om onderdeel te zijn van één van de Agile teams. We werken samen met een Scrum ontwikkelteam in het buitenland. In totaal werken er ongeveer 30 ontwikkelaars bij dit bedrijf.”
\nJoost: “Het is belangrijk dat je flexibel bent bij deze opdracht omdat er Agile wordt gewerkt en soms plannen worden aangepast vanwege recente inzichten. Ik pas mij graag snel aan, dus dat scheelt. Maar ook samenwerken, kwaliteitsgericht, resultaatgericht, initiatief nemen en klantgericht, zijn competenties die ik tijdens deze uitdaging nodig heb.”
\nJoost: “Met de digitale vrachtbrief zijn de gegevens makkelijk inzichtelijk en hiermee wordt het administratieve proces per rit versneld. Ondertussen ben ik veranderd van team en focus ik mij nu op andere producten. Ik kijk met voldoening terug op deze werkzaamheden, want het heeft daadwerkelijk impact gehad, wat ik belangrijk vind. Daarnaast krijg ik energie van dit soort werk en dat vind ik leuk!”
\nWil je net als Joost werken bij organisaties waar jij het verschil kan maken?
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Joost de Bos is een enthousiaste Java ontwikkelaar, die alweer vijf jaar bij VX Company werkt. Naast zijn werk fietst hij graag.","meta_description_search":"Joost de Bos is een enthousiaste Java ontwikkelaar, die alweer vijf jaar bij VX Company werkt. Naast zijn werk fietst hij graag.","slug":"https://werkenbij.vxcompany.com/blogs/fiets-jij-een-eindje-mee-met-joost","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"Fiets jij een eindje mee met Joost?!"},{"header_data":{"excerpt":{"body":{"value":"In this series of posts I want to show you how Kotlin improved on the Java language, without going into too much of the added features. Just the features that enhance your (existing) Java code."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"In this series of posts I want to show you how Kotlin improved on the Java language, without going into too much of the added features. Just the features that enhance your (existing) Java code.
\nIt is intended for Java developers who want to make their code
\nTherefor making you (and the people working with your code after you!) more productive.
\nI introduced Kotlin at the start of my last project and began by modeling our domain classes in Kotlin. Later on we grew more confident in the use of Kotlin and found ways to put it to use in more functional classes like services, builders and test helpers.
\nWhen I left the project team after 2.5 years members agreed with me that Kotlin greatly improved the code and that they would take this to other projects as well. I will too of course, using the posts in this series as proof/inspiration.
\nIntroduce Kotlin to your team
This series is, I think, an easy introduction to Kotlin for the intermediate Java developer. Read the posts listed below, look at the examples and start using it at a scale you’re comfortable with.
If you want to introduce Kotlin to your team or project, don’t go overboard and go 100% Kotlin for your next project. Read these three posts and start using it right away!
\nAddress, Person, User etc.This is enough to use Kotlin in your (existing) project!
\nNext steps
These posts tell you about more advanced features of Kotlin, but still within the ‘boundaries’ of this series.
At that point I would suggest diving into the Kotlin language for real. Take a course, buy a book and of course follow my blog; I will post some examples how we used Kotlin for services, unit tests, builders in the future.
\nA lot of what you will see in the first post (Kotlin classes) can also be achieved by using Project Lombok. We’ve actually considered Lombok for our project and decided against it, because Lombok is mostly that: enhanced Java classes by annotation. From my experience, Kotlin is so much richer and let’s you write beautiful code, not just annotate it. No hard feelings if you decide to go with Lombok, but know that you’ll be missing out on the inline functions and streams.
\nfdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"In this series of posts I want to show you how Kotlin improved on the Java language. Just the features that enhance your (existing) Java code.","meta_description_search":"In this series of posts I want to show you how Kotlin improved on the Java language. Just the features that enhance your (existing) Java code.","slug":"https://werkenbij.vxcompany.com/blogs/kotlin","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1662038103052,"deletedAt":0,"description":"","id":52549532623,"label":"Software Development","language":"nl","name":"Software Development","portalId":25062189,"slug":"software-development","translatedFromId":50989449419,"translations":{},"updated":1662038103052}],"title":"Kotlin, the essence of Java"},{"header_data":{"excerpt":{"body":{"value":"Binnen Kanban is er geen goed of fout. Enkel een meer of minder volwassen implementatie. Die implementatie draait overigens niet om een snelle verandering. Of om een ommezwaai in rollen, processen en afspraken. Het gaat om inzicht in je bestaansrecht en handelen, om vanuit daar te ontwikkelen en verdiepen."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}}},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Binnen Kanban is er geen goed of fout. Enkel een meer of minder volwassen implementatie. Die implementatie draait overigens niet om een snelle verandering. Of om een ommezwaai in rollen, processen en afspraken. Het gaat om inzicht in je bestaansrecht en handelen, om vanuit daar te ontwikkelen en verdiepen.
\nAlles wat je tot nu toe hebt opgebouwd als team, afdeling of organisatie, heeft waarde. Van rollen, processen en afspraken, tot hiërarchie, taken, verantwoordelijkheden en bevoegdheden. De eerste stap binnen Kanban richt zich dan ook op visualisatie. Wie is je klant? Welke diensten bied je aan? Welke capaciteit heb je om de behoefte van jouw klant te vervullen? Hoe zien jouw organisatie en workflow eruit? Zodra je inziet hoe je op het punt gekomen bent waar je nu staat, kun je bepalen waar jij als team staat ten opzichte van het Kanban Maturity Model.
\nNaast inzicht biedt het Kanban Maturity Model handvaten om te groeien en het volgende level te bereiken. Daar zitten echter wel twee belangrijke kanttekeningen aan. Wellicht herken je de eerste als je terug denkt aan een mooie wandeling in de bergen. Met de top van de berg in het vizier, denk je er bijna te zijn. Totdat je écht goed omhoog kijkt en ziet dat er nog een hogere top bestaat. Bij Kanban geldt exact hetzelfde. In dat geval kunnen er twee dingen gebeuren. Je vindt goed wel goed genoeg en bent tevreden met waar je nu staat. Of je wilt niet blijven hangen op een bepaald plateau en blijft verbeteren.
\nKies je voor de laatste optie, dan heeft het geen zin om een flink sprong te maken naar boven. De eerstvolgende stap overslaan is op een berg immers ook levensgevaarlijk. Zodra jouw team op Kanban Maturity level 2 is aangekomen, is het daarom zaak je (nog) niet bezig te houden met handvaten uit level 4. Hoe graag je ook wil, het heeft simpelweg niet het gewenste effect. Het Kanban Maturity Model mag bovendien niet voelen als een checklist die je af moet werken.
\nHoe hoger het Kanban Maturity Level, hoe meer je focust op de organisatie, diensten en klantbehoeften. Hoe lager het Kanban Maturity Level, des te meer je kijkt naar teamprestaties, taken en producten. De meeste teams starten tussen Kanban level 0 en 1. Om te bepalen op welk niveau een team of organisatie zich bevindt, maken we sinds kort gebruik van een bèta versie schalingsmodel. Middels het beantwoorden van een aantal vragen toetst het model op welk Kanban level men nu zit. Dat kan resulteren in één level organisatie breed, maar het kan ook zo zijn dat een bepaalde lijn binnen een organisatie hoger ligt dan een ander. In dat geval is het de noodzaak en uitdaging om beiden lijnen naar elkaar toe te brengen. Enkel al omdat het één het ander nodig heeft om te kunnen ontwikkelen naar het volgende Kanban Maturity level.
\nOm die ontwikkeling te realiseren is het zaak van te voren gezamenlijk een doelstelling te formuleren. Een mooi voorbeeld daarvan is de Kanban implementatie binnen de IT backoffice afdeling van Dienst Justitiële Inrichtingen, kortweg DJI. Aan het begin van ieder jaar formuleren zij op teamniveau het Kanban level welke ze aan het einde van het jaar willen behalen. Ook dan blijft het zaak dit doel niet alsnog als een checklist te zien om een level hoger te komen. De ontwikkeling en groei moet een doel dienen. Je moet een level hoger willen komen, omdat je een probleem wil oplossen binnen de organisatie. Binnen DJI bevonden sommige teams zich op level 0, anderen op level 1. Middels teamcoaching, de basistraining Team Kanban Practitioner en inregeldagen ontstond een statusflow. Deze flow is de basis om taken en verantwoordelijkheden te kunnen blijven visualiseren.
\nDJI startte met Kanban door de wens naar kortere lead tijd, meer inzicht en overzicht. Ook wilden zij de werkdruk beter kunnen reguleren om capaciteitsproblemen te voorkomen. Met name in januari en september ontstond binnen DJI een flinke toename in projecten. Niets vreemds overigens. In januari start men met frisse energie, terwijl in september overgebleven budgetten gebruikt moeten worden voor het einde van het boekjaar. Door bijvoorbeeld het introduceren van een contracycles kunnen we ervoor zorgen dat er een constante stroom in capaciteit gerealiseerd wordt, waardoor ook interne projecten opgeleverd kunnen worden.
\nErgens tussen Kanban Maturity level 1 en 2 maak je de shift van team naar afdeling. Tussen level 2 en 3 schakel je vervolgens om van afdeling naar waardeketen. Oftewel: de diensten die je als totale afdeling of organisatie biedt. Het werkt het fijnste als er niet al te grote verschillen ontstaan tussen de Kanban Maturity Levels van onderlinge teams. In het geval van DJI bestaat de IT backoffice in totaal uit 180 medewerkers, verdeeld over 20 (sub)teams. Om grip en controle op de ontwikkeling en voortgang te behouden, werken zij met flowmasters. Ieder team bevat twee flowmasters, zodat er nooit een Single Point of Failure zal ontstaan. In een wekelijkse flowmaster stand up bespreken zij de overstijgende werkzaamheden en Kanban Maturity van de gehele IT backoffice.
\nDe rode draad in de ontwikkeling en groei binnen het Kanban Maturity Model is inzicht in eigen handelen. Waar het ene team zich binnen DJI op Kanban level 2 bevindt, groeit een ander al naar level 3. Om ieder team te stimuleren door te blijven ontwikkelen is het zaak geregeld een spiegel voor te houden. Wat betekent iemands handelen voor het geheel van de organisatie? Hoe kun je er in het geval van weerstand toch voor zorgen dat er verandering ontstaat?
\nWil jij graag meer weten over de verschillende levels binnen het Kanban Maturity Model of ben je benieuwd naar het uitgebreide verhaal rondom onze Kanban implementatie? Neem contact op met Maarten Hoppen
","reverse":false}],"module_id":52218371028,"richtext_field":"fdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"De implementatie van Kanban draait niet om een ommezwaai in afspraken. Het gaat om inzicht in bestaansrecht en handelen, om vanuit daar te ontwikkelen.","meta_description_search":"De implementatie van Kanban draait niet om een ommezwaai in afspraken. Het gaat om inzicht in bestaansrecht en handelen, om vanuit daar te ontwikkelen.","slug":"https://werkenbij.vxcompany.com/blogs/vergaderen-is-leuk-1","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1661254761818,"deletedAt":0,"description":"","id":52177477878,"label":"Agile Coaching","language":"nl","name":"Agile Coaching","portalId":25062189,"slug":"agile-coaching","translatedFromId":50989449420,"translations":{},"updated":1661254761818}],"title":"Hoe bereik je groei van Kanban binnen een organisatie?"},{"header_data":{"excerpt":{"body":{"value":"Een Agile team werkt het best als het zelforganiserend of zelfmanagend is. En een goed functionerend team levert eerder succesvolle producten en tevreden klanten op. Maar hoe pak je zelforganisatie aan?"},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Een Agile team werkt het best als het zelforganiserend of zelfmanagend is. En een goed functionerend team levert eerder succesvolle producten en tevreden klanten op. Maar hoe pak je zelforganisatie aan?
\nZelforganisatie betekent dat traditionele macht en hiërarchie zijn gedistribueerd door de organisatie heen. Teams werken autonoom en hebben alle bij hun rol behorende bevoegdheid. Uiteraard zijn er wel kaders én een gedeeld doel waar iedereen gezamenlijk naartoe werkt.
"},{"afbeelding":{"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Veel organisaties worstelen met de mate waarin managers managen. Én de mate waarin individuen autonoom handelen.
\nIk vergeet nooit een team dat ik ooit begeleidde. Dat bestond uit gedreven en serieuze professionals. Elk individu nam alle verantwoordelijkheid voor zijn eigen bijdrage aan het team, er was vertrouwen en verbondenheid. Hun manager was hier enorm van onder de indruk en probeerde hen zo goed mogelijk te ondersteunen. Maar helaas werd zij tegengehouden door haar manager en voorgeschreven procedures. Het team voelde deze pijn rechtstreeks en raakte oprecht terneergeslagen. Ze wilden zo graag, maar mochten niet.
\nOf een ander team: zij kregen van hun manager de opdracht om een halve dag in de week te gaan Scrummen. Dit met de bedoeling om een product sneller en succesvoller op de markt te brengen. De manager was ook de Product Owner. Elke ‘Scrumochtend’ zaten zij net lekker in hun ritme toen ze weer een week moesten wachten om het op te pakken. De manager wist niet goed waar zijn toegevoegde waarde nou zat, dus ging flink sturen op de ‘hoe’. Het team voelde veel te weinig autonomie. Dat zorgde voor een gefrustreerd team en het experiment om Agile te werken stierf een stille dood.
\nSoms ervaar ik het ook de andere kant op. Dan verzucht een manager: “Ik moet echt overal over meedenken. Ik wil zo graag dat ze zelf beslissen. Wat houdt hen tegen?” Mensen zijn in hun dagelijkse leven in staat om complexe beslissingen te nemen. Maar zodra we ons kantoor binnen wandelen, lijken we een leidinggevende nodig te hebben die ons vertelt wat we moeten doen. Hoe zou dit dan komen? Door de medewerkers? Door de leidinggevende? Hoogstwaarschijnlijk zijn de ‘passieve’ medewerkers niet de oorzaak, maar een symptoom. Wat heb je dan te doen?
\nIk geloof hartgrondig in de voordelen van zelforganisatie. Praktisch gezien maakt het organisaties flexibeler, wendbaarder en efficiënter. Een team kent de klant het beste, dus als het autonomer mag handelen is het veel beter in staat om klantwaarde te leveren. En bovendien levert autonomie meer betrokken en gemotiveerde medewerkers op.
\nHet slechtste wat je kunt doen is tegen een team zeggen ‘Jullie zijn voortaan zelforganiserend’ en hen in het diepe gooien. Allereerst moet je borgen dat de nieuwe werkwijze in te passen is in de bestaande organisatiestructuur en -cultuur. Werk je in een niet al te grote en moderne organisatie met een relaxte wijze van samenwerken? En zijn er niet teveel onderlinge afhankelijkheden? Dan is het wellicht slechts een kwestie van kaders vastleggen, afspraken maken en de rest van de organisatie informeren dat jouw afdeling of team wat anders gaat werken. Maar in een organisatie met flink wat hiërarchie en bureaucratie gaan teams direct tegen de grenzen van de organisatie oplopen en gefrustreerd raken.
\nEn dan is er nog een tweede aspect: de mensen moeten er zelf klaar voor zijn. Als manager kun je de mate van vrijheid of autonomie die een team heeft steeds meer opbouwen. En hen helpen om steeds meer regie en vrijheid te pakken en de bijbehorende competenties te ontwikkelen. Onderstaand model van Peter Koning uit het boek ‘Toolkit voor Agile Leiders’ visualiseert dit:
","reverse":false},{"afbeelding":{"alt":"OwnershipModel-xW350","height":440,"loading":"lazy","max_height":440,"max_width":350,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/OwnershipModel-xW350.png","width":350},"choice_field":"afbeelding","content":"","reverse":false},{"afbeelding":{"alt":"Afbeelding1-1","height":750,"loading":"lazy","max_height":301,"max_width":226,"size_type":"exact","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Afbeelding1-1.jpeg","width":563},"choice_field":"tekst","content":"(Bron afbeelding: https://re-lead.co/ownership-internal-engagement/)
\nKortom, als de balans tussen team volwassenheid en vrijheid in jouw organisatie goed is, dan is de weg vrij naar meer eigenaarschap. En dat op zijn beurt resulteert in beter functionerende teams, succesvollere producten en tevreden klanten.
\nWil je meer weten over de genoemde methodieken en werkvormen? Neem dan gerust contact op met onze Agile Coach Saskia Aalberts.
","reverse":false}],"module_id":52218371028,"richtext_field":"fdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Een Agile team werkt het best als het zelforganiserend of zelfmanagend is. En een goed functionerend team levert eerder succesvolle producten en tevreden klanten op. Maar hoe pak je zelforganisatie aan?","meta_description_search":"Een Agile team werkt het best als het zelforganiserend of zelfmanagend is. En een goed functionerend team levert eerder succesvolle producten en tevreden klanten op. Maar hoe pak je zelforganisatie aan?","slug":"https://werkenbij.vxcompany.com/blogs/waarom-zelforganisatie-hoort-bij-agile-werken","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1661254761818,"deletedAt":0,"description":"","id":52177477878,"label":"Agile Coaching","language":"nl","name":"Agile Coaching","portalId":25062189,"slug":"agile-coaching","translatedFromId":50989449420,"translations":{},"updated":1661254761818}],"title":"Waarom zelforganisatie hoort bij Agile werken"},{"header_data":{"excerpt":{"body":{"value":"Accepteer je gedachteloos alle uitnodigingen voor vergaderingen? Dan zijn helaas veel vergaderingen niet zo effectief."},"child_css":{},"css":{},"id":"excerpt","label":"Blog Preview Tekst","name":"excerpt","order":0,"smart_type":null,"styles":{},"type":"text"},"module_16587658161786":{"body":{"button_text":"Alle blogs","element_title":"Gerelateerde blogs","link_field":{"no_follow":false,"open_in_new_tab":false,"url":{"content_id":52168953593,"href":null,"type":"BLOG"}},"module_id":50621712059},"child_css":{},"css":{},"id":"module_16587658161786","label":"Recent Blogs - Page Section","module_id":50621712059,"name":"module_16587658161786","order":7,"smart_type":null,"styles":{},"type":"module"},"module_165882441930110":{"body":{"image_field":{"alt":"4E0A4842 (1)","height":1365,"loading":"eager","max_height":1365,"max_width":2048,"size_type":"auto","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/4E0A4842%20(1).jpg","width":2048},"media_selector":"image","module_id":51146532838},"child_css":{},"css":{},"deleted_at":1661335236575,"id":"module_165882441930110","label":"Media Row - Image Video - Post Section","module_id":51146532838,"name":"module_165882441930110","order":4,"smart_type":null,"styles":{},"type":"module"},"module_166019308564271":{"body":{"module_id":50667721960,"paragraph_text_field":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
"},"child_css":{},"css":{},"deleted_at":1661334246351,"id":"module_166019308564271","label":"Text - Post Section","module_id":50667721960,"name":"module_166019308564271","order":6,"smart_type":null,"styles":{},"type":"module"},"module_16613339051402":{"body":{"choice_field":["tekst","afbeelding"],"content":[{"afbeelding":{"alt":null,"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Het zou zomaar kunnen dat je lijdt aan een onbekende, maar wijdverspreide kantoor ziekte: MAS. David Grady introduceerde dit acroniem in een Ted Talk in 2014. Het staat voor ‘Mindless Acceptance Syndrome’. Het fenomeen waarbij je gedachteloos alle uitnodigingen voor vergaderingen accepteert die in je mailbox verschijnen. En dan zijn helaas flink veel vergaderingen ook niet zo effectief. Daardoor is het risico groot dat je een aanzienlijk deel van je werktijd verspilt aan ineffectieve vergaderingen. Gelukkig is daar wat aan te doen!
\nVoordat je een vergaderverzoek accepteert (of zelf plant!) stel jezelf dan de volgende vragen:
\nDoor dit van tevoren met elkaar vast te stellen, maak je de meeting al veel effectiever. Het kan zomaar zijn dat iemand alleen maar geïnformeerd wil worden. Die is dan blijer met een mailtje achteraf. En misschien denkt een manager dat het doel van een vergadering is om het team te informeren. Terwijl een teamlid verwacht mee te mogen besluiten. Het is in elk geval goed dat dit op tafel komt.
","reverse":false},{"afbeelding":{"alt":"Consent-decision-making","height":2000,"loading":"lazy","max_height":1013,"max_width":446,"size_type":"exact","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Consent-decision-making.png","width":881},"choice_field":"tekst_afbeelding","content":"De vorm van de vergadering laat je afhangen van het doel. Maar let op: de vorm waarin een groep mensen om een tafel zit en over een onderwerp praat is maar zelden effectief.
\nBrainstorm
\nWil je met elkaar iets bedenken? Kies dan een brainstormtechniek waarbij je eerst via divergeren veel ideeën bedenkt en vervolgens via convergeren tot een keuze komt.
\nLiberating structures
\nZoek mooie werkvormen die de creativiteit, maar vooral ook de betrokkenheid van alle deelnemers verhogen? Verdiep je dan eens in de Liberating Structures van Keith McCandless en Henri Lipmanowicz.
\nBesluitvorming
\nDuurt beslissen bij jullie eindeloos? Bedenk dan eens hóe je wilt besluiten. Moet iedereen het ermee eens zijn? Of kun je het besluit in bepaalde mate delegeren via de Management 3.0 methode delegation poker? Of volstaat het als mensen zeggen: ‘Ik kan ermee leven.’ Dan kun je je eens verdiepen in het Sociocracy 3.0 principe van consent based decision making.
","reverse":false},{"afbeelding":{"loading":"lazy","size_type":"auto","src":""},"choice_field":"tekst","content":"Scrum events
\nNiet voor niets noemen we de Scrum Events geen vergaderingen. Het doel van elk event is klip en klaar én er is een timebox, dus een maximale tijdsduur. Toch kan ook een Sprint Planning verzanden in een lange, monotone zit. Of een Sprint Retrospective stokken op het moment dat we uitvoerbare verbeteringen vast willen stellen. Zorg dus ook daar voor een duidelijk doel én een geschikte vorm.
","reverse":false},{"afbeelding":{"alt":"Afbeelding1-1","height":750,"loading":"lazy","max_height":301,"max_width":226,"size_type":"exact","src":"https://25062189.fs1.hubspotusercontent-eu1.net/hubfs/25062189/Afbeelding1-1.jpeg","width":563},"choice_field":"tekst_afbeelding","content":"Uiteindelijk is de effectiviteit van het vergaderen natuurlijk ook afhankelijk van het gedrag van de deelnemers. Wat zijn de meest gehoorde klachten?
\nDaar is gelukkig een geweldige oplossing voor: ELMO! ELMO is de afkorting van ‘Enough, let’s move on.’ Je kunt hem op je vergadertafel leggen. Wijs er subtiel naar, zwaai ermee of gooi hem in het zwaarste geval naar iemands hoofd. Lees hier hoe je Elmo slim inzet.
\nHopelijk ben je geïnspireerd om jouw vergaderingen effectiever én leuker te maken. En roep jij bij het volgende vergaderverzoek in je mailbox: “No MAS!”
\nWil je meer weten over de genoemde methodieken en werkvormen? Neem dan gerust contact op met onze Agile Coach Saskia Aalberts.
","reverse":false}],"module_id":52218371028,"richtext_field":"fdsfsfsdfsdfs
"},"child_css":{},"css":{},"id":"module_16613339051402","label":"Image and Text Switcher","module_id":52218371028,"name":"module_16613339051402","order":5,"smart_type":null,"styles":{},"type":"module"}},"meta_description":"Accepteer je gedachteloos alle uitnodigingen voor vergaderingen? Dan zijn helaas veel vergaderingen niet zo effectief.","meta_description_search":"Accepteer je gedachteloos alle uitnodigingen voor vergaderingen? Dan zijn helaas veel vergaderingen niet zo effectief.","slug":"https://werkenbij.vxcompany.com/blogs/vergaderen-is-leuk","tags":[{"categoryId":3,"cdnPurgeEmbargoTime":null,"contentIds":[],"cosObjectType":"TAG","created":1661254761818,"deletedAt":0,"description":"","id":52177477878,"label":"Agile Coaching","language":"nl","name":"Agile Coaching","portalId":25062189,"slug":"agile-coaching","translatedFromId":50989449420,"translations":{},"updated":1661254761818}],"title":"Vergaderen is leuk"}]; let blog_posts = blogs.map(blog=>{ let meta = blog.meta_description.substring(0, 130)+'...'; return {...blog.header_data, "slug" :blog.slug, "meta_description": meta, "meta_description_search": blog.meta_description_search, title: blog.title, tags: blog.tags[0].slug}; }); localStorage.setItem('blog_posts',JSON.stringify(blog_posts));