Bio
Evelyn van Kelle is a strategic software delivery consultant, with experience in coaching, advising and guiding organisations and teams in designing socio-technical systems. Her Master’s degree in social sciences brings new and valuable perspectives when it comes to optimizing both delivery- and team processes.
Being a firm believer of context shaping meaning, she is focused on understanding company- and team culture before anything else. Finding the actual problem to solve and adding business value are starting points in her work. Evelyn is convinced that we need a shared sense of reality including shared values, goals and language in order to perform best as a team. She is curious, driven and pragmatic. “Continuous improvement is better than delayed perfection” describes her line of reasoning.
Besides her daily work, she has a predilection for books and linguistics, and highly appreciates good food.
How cognitive biases and ranking can foster an ineffective architecture and design
(Lab)
by
Kenny Baas-Schwegler, Evelyn Van Kelle
The power of collaborative modelling comes from having a diverse group of people who, together, have a lot of wisdom and knowledge. You would expect that all this knowledge will be put to use, co-creating, and to design a model. In reality, we don’t actually listen to all the available input and perspectives due to cognitive biases and ranking. Because not everything that needs to be said has been said, we will end up with sub-optimal models and architecture. Even worse, people don’t feel part of the solution and don’t commit to it. Good architecture and design need all the insights and perception. If we are not aware, cognitive biases and ranking kills those insights and wisdom and kills the effectiveness of your models!
Join us in this session where we will interactively explore how we can improve our facilitation skills and focus on neuro-inclusiveness with Lewis Deep Democracy (LDD). By having a Deep Democratic discussions together on what biases are at play during liberating structures workshops, and how ranking will effect a visual collaborative modelling session like EventStorming and User Story Mapping, you will gain first-hand experience about LDD. With this experience, we will explain how we embedded LDD in our design processes. We will let you leave with the knowledge on how to observe sabotage behaviour, battle oppression, and to create safety in exploring alternative perceptions. We will show you how you can really let the group say what needs to be said and take a collective autocratic decision in designing your software models.
When To Move From Collaborative Modelling to Coding?
(Lab)
by
Kenny Baas-Schwegler, Gien Verschatse, Evelyn Van Kelle
Managing polarities in software design and engineering.
When can we actually start coding? How do you know when you have done enough collaborative modelling? How can we make our architecture and design really iterative?
Domain-driven design puts a huge focus on collaborative modelling to build a shared understanding of your domain and we use a lot of tools like EventStorming, Example Mapping, Whiteboard sessions and Responsibility mapping to get to that shared understanding. But when it comes to questions like “when do we start coding?’, and “How much collaborative modelling is needed?”, it is often difficult to find a good answer or the answer you receive is “it depends”.
The reason that it is so difficult to answer those questions is because we are looking at these questions in the wrong way. We look at them like a problem we need to solve, instead of what it actually is: a polarisation that needs to be managed. If we don't learn how to recognize and manage polarities, we will make compromises or stay on one side of the polarity and experience the downside of both. To identify and manage polarities, we need to discuss and start using polarity mapping.
In this session, we will interactively introduce you to polarity thinking. We will explore how to identify polarities and how to manage them with Barry Johnson Polarity Mapping. We will explore too much vs too little upfront design, by filling in the polarity map together, we show you the power of visualisation to manage the polarity. We will go from either-or thinking to both-and thinking, and this way include the entire team in managing that polarity. You will leave the session knowing when to go from collaborative modelling to coding and fill in the polarity map with your team the next day!