A lot of knowledge is lost when designing and building software — lost because of hand-overs in a telephone game, confusing communication by not having a shared language, discussing complexity without visualisation and by not leveraging the full potential and wisdom of the diversity of the people. That lost knowledge while creating software impacts the sustainability, quality and value of the software product. Kenny Baas-Schwegler is a socio-technical organisation designer and software architect. He blends IT approaches like Domain-Driven Design and Continuous Delivery and facilitates change through using visual collaboration practices, the Cynefin framework and Deep Democracy. Kenny empowers and collaboratively enables organisations, teams and groups of people in designing and building sustainable quality software products.
One of Kenny's core principles is sharing knowledge. He does that by writing a blog on his website baasie.com and helping curate the Leanpub book visual collaboration tool. Besides writing, he also shares experience in the Domain-Driven Design community as an organiser of Virtual Domain-Driven Design (virtualddd.com) and Domain Driven Design Nederland. He enjoys being a public speaker by giving talks and hands-on workshops at conferences and meetups.
Kenny Baas-Schwegler, Rebecca Wirfs-Brock
How can we get better as software designers?
By becoming more aware of our design heuristics and be intentional as we cultivate and refine them. Heuristics aid in the design and even determine our attitude and behaviour. For example, agile developers value frequent feedback and decomposing larger design problems into smaller, more manageable chunks that they design and test as they go. We each have our own (often implicit) heuristics that we have acquired through reading, practice, and experience. Let us share these heuristics during a modelling session!
You'll be presented with a modelling problem that you will try to design in groups. During designing, we will rotate observers that will capture and map heuristics they see happening. After the heuristics are captured, groups will exchange and try-out other groups heuristics, to switch thinking during design. Finally, we will wrap-up with the whole group explaining and sharing the key heuristics used in each group.
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.
Gien Verschatse, Kenny Baas-Schwegler, 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!