Kenny Baas-Schwegler is a strategic software delivery consultant, Socio-technical architect, facilitator, collaborate modeller, technical lead that builds quality into software delivery at Xebia. He mentors, coaches and consults management and teams by using practices, techniques and tools from domain-driven design, anthropology, deep democracy, behaviour-driven development, DevOps, and Continuous Delivery.
Through Aikido training, he learned the most efficient way to work together. To get the outcome that all parties want, energy should not be blocked but should be bent and influenced. The philosophy behind this line of reasoning is not only embedded in his personal life, but also in his work life.
By using and combining tools such as EventStorming, Example Mapping, Impact Mapping, and User Story mapping, he helps to bridge the communication gap between business and IT. With these approaches, he aims to create a transparent, safe, and collaborative space with constant and instant feedback for delivering quality software.
Besides his daily work, he also helps organise several meetups for Virtual Domain-Driven Design, Domain Driven Design Nederland and EventStorming Netherlands and is a public speaker giving talks and hands-on workshops at conferences and meetups.
(Talk, DDD Foundations 2020)
The way agile software teams gain knowledge about what to build is either by the product owner or business analyst serving as a proxy to domain knowledge. Domain knowledge usually ends up as second-hand news in either functional design documents or as user stories in some scrum tools like Jira. Second-hand knowledge is a significant risk when building software. Each time information is transferred just like doing the telephone game, the story is changed, and people make assumptions. Because as Alberto Brandolini said: ‘It is not the domain expert’s knowledge that goes into production; it is the developer’s assumption of that knowledge that goes into production’.
Even when these stories are shared first hand, they usually are discussed sitting around a table looking at a screen showing the user stories. Addressing complex problems without visualisation is impossible for most humans to solve. Doing so resolve in making a lot of assumptions again, which will stop us from building the right thing.
Join me in this session where I will explain how visual collaborative modelling can help you write better software. Through proper preparation and facilitation, we can co-create solutions. Co-creating solutions by visual collaborative modelling make sure we have buy-in from the entire team. You will end up knowing how to start your visual collaborative modelling journey with tools like EventStorming and Example Mapping.